Problem: Periodic activation requests to the KMS are rejected and the operating system is seen as unlicensed.
Cause: Windows cannot locate the Key Management Server (KMS) after changing the time zone of the Cloud Server. Now your Cloud Server's system clock does not sync with the KMS.
Resolution: You will need to resynch your Cloud Server with the KMS server:
1. Log in to your Cloud Server as Administrator and run the following from the command prompt (Start, All Programs, Accessories, right-click Command Prompt and select Run as Administrator).
ping winactivate.ord1.servers.rackspacecloud.com
ping winactivate.dfw1.servers.rackspacecloud.com
**if there is a reply, move on to step 2. No reply means that there is an interface, hardware, or routing issue**
2. Set the KMS manually within the registry.
slmgr.vbs /skms winactivate.ord1.servers.rackspacecloud.com:1688
slmgr.vbs /skms winactivate.dfw1.servers.rackspacecloud.com:1688
3. Request activation from the KMS :
slmgr.vbs /ato
4. If step 3 returns an error reading EXACTLY “0xC004F074 The Key Management Server (KMS) is unavailable”, run the following:
w32tm /resync
5. If the time on the Cloud Server is drastically different than what is on the KMS the resync will fail. At this point you will need to either set the time manually or configure the server to use an NTP instance over the internet:
net stop w32time w32tm /config /manualpeerlist:time.windows.com /syncfromflags:MANUAL net start w32time
6. Once the time is synced up, attempt the following:
w32tm /resync slmgr.vbs /ato
7. You will also need to open UDP port 123 to allow the sync. Read this article to learn how to Create an Inbound Port Allow Rule.
8. Once the time is synced up, attempt the following:
w32tm /resync slmgr.vbs /ato
© 2011-2013 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License

6 Comments
I am unable to ping
Re: ping
You can see what datacenter your Cloud Server is in by checking the server list - the rightmost column lists the datacenter.
The activation servers need the private interface enabled
Similar to the posting from a few weeks ago, we could get an IP back when pinging winactivate.ord1.servers.rackspacecloud.com but did not get replies. We had disabled the private interface on the cloud server on the day of its spinup since we had no intention of using a load balancer or linking it to other internal cloud services. One less interface to think about for security concerns was the goal.
This appears to be why our server could not activate. Apparently in addition to it being usable for private system communication that isn't metered, the private interface is also used for KMS activation and Rackspace management. This was news to us and not clear in this article that it was necessary.
I guess we need to leave it on and then make sure the windows firewall allows nothing through on that interface to keep us protected from other cloud servers that get compromised. Rackspace - we'd definitely prefer not having the extra interface stay enabled, even though it'd send the minuscule activation traffic over the public IP (and we'd get billed for it).
Re: private interface
I can't speak for the folks in charge of the activation servers, but I suspect they don't want those activation servers accessible from the public network. Restricting them to the private network limits their exposure to attack.
Windows 2012
Deactivated PublicNet
Basically, without a PublicNet connection:
'slmgr.vbs /skms winactivate.ord1.servers.rackspacecloud.com:1688'
won't work, you will need to use:
slmgr.vbs /skms 10.179.63.253:1688
Add new comment