Skip to content

Microsoft KMS / VAMT v2.x and v3.x – Error 0x80070054 – Storage to process this request is not available

Just recently I came upon an Microsoft KMS error stating Error 0x80070054 - Storage to process this request is not available.

tmos_01

This error was quite annoying as at first I didn't had a clue what this was all about. The error message itself could be quite misleading and left me poking in the dark... Eventually I found a possbile solution.

This blog article as been updated. Pls consult the updated section at the bottom of my post.

My setup looks like this:

  • KMS host is up and running on a Windows Server 2008 R2 VM
  • KMS host has been configured and activated successfully
  • KMS host DNS service record has been successfully published and all clients are able to see and connect to my KMS host
  • VAMT v3.1 has been installed and configured successfully on my KMS host
  • corresponding product keys, i.e. Windows 7 Professional as well as Office 2010 Professional, have been added
  • everything ran smoothly for quite some time and caused no issues at all

All of a sudden users started complaining that their machines are victims of software counterfeiting. They started sending me emails with Microsoft's famous error message "You may be a victim of software counterfeiting. This copy of windows is not genuine." I started to investigate...

First of all I tried to Update the License Status with VAMT MMC by right-clicking the affected machine and hitting the corresponding option. The error started popping up:

tmos_08

The Event Log on the affected machine showed the exact same error:

kms_error_01

First thing I did was to Google the error message. The results were quite discouraging as a lot of results pointed to IRPStackSize issues, i.e. its value being to small, et al. I was able to eliminate that particular issue very quickly, as all of my clients already have the maximum IRPStackSize of 50 (decimal) set via GPO, and being the fact that this has been a known issue back in the days of Windows XP.

Then, more or less accidentally, I came across an Spicework's forums thread stating issues with KMS activating Microsoft Office 2013. Not exactly what I've been looking for, but had a look at it nontheless. The article stated something about TrendMicro OfficeScan, and that got me hooked as we're using that particular product as well.

To make a long story short, TrendMicro OfficeScan caused issues while KMS activating Windows 7 Professional (as well as Microsoft Office 2013) due to its realtime scanning and blocking behaviour. Assumingly certain processes are too suspicious to simply let them run wild and do their thing, including Microsoft processes required to KMS activate said products. These processes are:

  • cscript.exe
  • wscript.exe
  • osppsvc.exe
  • sppsvc.exe

The corresponding TrendMicro article showed my how to Whitelist said processes, the KMS host's IP address and subnet mask in order to stop interfering with my KMS activation process:

tmos_05

After adjusting my configuration and pushing it to my clients I was able to Update the License Status and Install the Product Keys.

tmos_06

Maybe this helps keeping in mind that, maybe, some kind of AV or realtime monitoring application can potentially interfere with KMS activation and cause misleading issues.

2016-12-05 Update - KMS Host Server Migration

Well, I came across another cause for this issue, thus proofing how misleading this error message can be. During a KMS migration, i.e. moving KMS from a soon-to-be-decommissioned server to a new server, and upgrading from VAMT 2.0 to VAMT 3.0 in the process, I saw this error while trying to KMS activate existing Microsoft Office 2010 installations. Thing is, my new KMS was able to successfully serve and KMS active my Windows 7 Professional computers, but always failed so with the corresponding Microsoft Office 2010 installations. I received the aforementioned error as soon as I tried to manually active those instances within the VAMT 3.0 MMC.

So I had to take a deeper look at what actually happens while those clients try to KMS active their Microsoft Office installation. With VAMT 3.0 MMC I was able to look at a specific client, thus realizing that it still wants to KMS active with my old KMS server, though the corresponding DNS service record already pointed to the new KMS server.

Check whether your KMS host server has been successfully published in DNS (where domain.com equals your internal Active Directory Domain Name FQDN):

nslookup -type=SRV _vlmcs._tcp.domain.com

05-12-_2016_14-19-49

Display detailed license information with the /dlv parameter:

slmgr.vbs /dlv

05-12-_2016_15-09-01

By default, /dlv displays the license information for the installed operating system. Specifying the <Activation ID> parameter displays the license information for the specified edition associated with that Activation ID. Specifying the All parameter displays all applicable installed products’ license information:

slmgr.vbs /dlv All

05-12-_2016_15-09-28

slmgr.vbs /dlv <Activation ID>

05-12-_2016_15-09-48

Microsoft Volume License Product Keys intended for KMS activation have to be installed and activated on the corresponding KMS host server's command line using slmgr.vbs. In my case I forgot to uninstall the Microsoft Office 2010 KMS Product Key and clear it from its registry by running the following commands:

slmgr.vbs -upk <Activation ID>

slmgr.vbs -cpky

All good, but still no luck. Upon checking the status of one of my affected clients more closely by navigating to the Volume Licensing Reports | Volume Activations by Type node in the VAMT 3.0 MMC's left pane, I discovered that this client in particular still tried to connect and KMS activate its Microsoft Office 2010 instance with my old KMS host server (which of course was already decommissioned):

05-12-_2016_14-17-18

Though my new KMS host server was published in DNS, actually, the client still tried to communicate with the old KMS host server. The reason for this being the client's local KMS Host Cache. So you have to start looking for an Event ID 12288 in your affected client computer's Application Event Log, without a subsequent Event ID 12289, as the Event ID 12288 alone will indicate a non-reachable KMS Host Server. As per Microsoft:

What this means is that the KMS client will cache the KMS host that it was able to activate with and will communicate directly with this host when it is time to reactivate (instead of querying DNS). If the client cannot contact the cached KMS host, discovery with DNS will be used.

ic368863

This meant cleaning up the client's KMS Host Cache in order to somehow trigger a corresponding DNS service lookup. Again, as per Microsoft:

By default, KMS clients automatically attempt to discover KMS hosts. Auto-discovery can be disabled by manually assigning a KMS host to a KMS client. This action also clears the KMS host name from the KMS client’s cache. If auto-discovery is disabled, it can be re-enable by running slmgr.vbs /ckms at a command prompt.

After cleaning up the KMS Host Cache the client was able to successfully connect with my new KMS Host Server and trigger an KMS activation process for Microsoft Office 2010.

Further reading:

Leave a Reply