How to actually get KMS working in the real world.

If you don’t know what KMS is, it’s the nightmare that Microsoft has unleashed upon the Windows Admins of the world since the release of Windows 2008 R1.  In the good old days you stuck the Windows license key on the server and it connected to Microsoft to validate the license.  Apparently that wasn’t good enough for Microsoft so you now have to have a Key Management Service (KMS) running on a server on your network.

In theory getting KMS working is a piece of cake. You just install windows on a server, put the KMS key in the machine as the license key and move on.

In the real world there is a little more to it.

For each different OS that you have to need to add the license key to the KMS server.  Now you’d think that there would be a nice interface that shows you your licenses, how many you’ve used etc right?  Yeah, not so much.  Key management is done completely via a VB script which sits in the Windowssystem32 folder.

So to install the new license key you have to run slmgr.vbs with the -ipk switch.  Then run it again with the -ato switch so that you can activate the license.

cscript slmgr.vbs -ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

cscript slmgr.vbs -ato

Now if the license activates you are good to go, however if it doesn’t you have a problem you now need to get the info from the system so that you can call Microsoft.  This requires using the -dlv parameter so that you can get the Activation Id from the application.

cscript slmgr.vbs -dlv

Then use the -dti parameter and the Activation Id that you just got to get the Installation Id.  This is the number that the phone system will want from you to get the license activated.  Check the phone.inf file to get your local phone number.

cscript slmgr.vbs -dti xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

notepad %systemroot%system32sluiphone.inf

Now the Microsoft phone system will give you back a bunch of numbers.  Note them without dashes in a notepad doc.  Then use slmgr.vbs with the -atp parameter passing it the value you get back from Microsoft and the Activation Id that you got before.

cscript slmgr.vbs -atp 000000000000000000000000000000000000000000000000 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

At this point, unless you’ve fubar’ed any of these parameters your license will be activated.

Now if you’ve been using VMware to deploy templates of Windows you’ve probably got Customization Specifications setup.  And you’ve probably got either your MAK or KMS keys entered in there.  Both of those would be the wrong keys to use.  You should be using the keys listed on this web page as these are the keys that tell Windows that it is a KMS client and that it should connect to your local KMS server.

Now if you’ve put your KMS key into all of your virtual machines as the key, you need to clean up your DNS as well.  Within your internal DNS servers under your domain then _tcp subdomain you’ll see a bunch of domains under _VLMCS.  You’ll want to make sure that you only have SRV records with this name pointing to your actual license server or servers.

On the machines which you have already deployed using your KMS keys, you’ll need to reset the keys on those machines.  This can be done with the following commands, just put in the correct key from the page listed above.

cscript c:windowssystem32slmgr.vbs -upk
cscript c:windowssystem32slmgr.vbs -ipk PutYourKeyHere
cscript c:windowssystem32slmgr.vbs -ato

This will remove the current license key, add the KMS client key, then register the computer with the local KMS server.

Now isn’t that easy?

Good Luck.


UPDATE 2010.07.27: Corrected the scripts from csharp to cscript.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trust DCAC with your data

Your data systems may be treading water today, but are they prepared for the next phase of your business growth?