Moving KMS servers

I was recently working with a client who was in the process of building a new AD forest and the slow and painful process of migrating all objects and collapsing old ones. That’s a pain for a different time.

When the new forest was first built out they weren’t sure how quickly they’d be migrating to the new domain or how quickly they’d be building out servers. The first part of the process was to build out a few DC’s and then go from there. Since KMS requires a minimum of 5 servers to activate any of them it seemed prudent to point them to the old KMS server in the old forest so that the Windows servers wouldn’t expire.

This was easily done by creating a SRV record in DNS in the new domain pointing to the old server. That’s not the point of this article, but as a down and dirty all you need to do is create a SRV record in the domain of a _VLMCS type as a _tcp record, pointing to port 1688. i.e. The data in the record is just the FQDN or IP of your KMS server.

All that being said, fast forward to the day that more than 5 servers existed in the new domain and they wanted to create a new KMS in the new domain and point the existing AD servers at it.

Creating the new KMS is easy. Just go to an elevated command prompt and type:

slmgr.vbs /ipk KEY 

where KEY is your purchased KMS key from Microsoft.

Then you’ll want to activate the KMS against Microsoft:

slmgr.vbs /ato 

You should get a nifty popup box that says Activation is successful.

And finally you’ll want to go into DNS and delete the manually created SRV record pointing back to your old KMS host. You should also see one in there for your new KMS.

Now that you have a brand new KMS host, you need to go back and re-point your new AD serves at it. Should be as simple as doing a /ato again, right? Wrong!

Since the old KMS server is still up and accessible over the network your AD servers will automatically use it to renew their license, and will continue to do so every 180 days that they renew. You need to teach them how to forget that it exists.

Type the following commands in sequence. Wait for a popup after each one telling you that it was successful:

slmgr.vbs /ckhc <== disables caching of the KMS host
slmgr.vbs /ckms <== clears the KMS host name cache
ipconfig /flushdns <== reloads the IP cache
net stop sppsvc && net start sppsvc <== restarts the Software Protection Service, which is necessary for any of these changes to take effect
slmgr.vbs /ato <== attempt to activate the KMS client

Note that until you've hit 5 servers you should get an activation error to that effect. Once you hit 5 it'll go away.

slmgr.vbs /skhc <== re-enable KMS host caching and take us back to default settings
slmgr.vbs /dlv <== give us a verbose list of all the KMS licensing settings. Should show that we're activated and who we're activating against

Annoyingly, you won’t get a successful activation until you’ve hit your 6th server, but all the activations you’ve attempted will automatically work once you get there. If you want to force it you can go back and do an slmgr.vbs /ato again.

All these commands are possibly overkill, but it was the only way I was consistently able to get all the servers to activate against the new KMS.


2 thoughts on “Moving KMS servers

  1. Good information. Lucky me I came across your blog by
    accident (stumbleupon). I have bookmarked it for later!

  2. Ken says:

    I want to say thanks for the great info. I was able to script the commands. Made moving to my new server a lot faster. Thanks.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s