Installing the Key Management Server

By Lauren Malhoit

April 23, 2012, 4:50 AM PDT

Takeaway: Lauren Malhoit helps those implementing KMS to be aware of some caveats.

Since we started out as a small company, we didn’t see much need to make use of KMS keys and servers.  However, as we continue to grow, it’s become much easier to create images and use KMS keys to make computer deployment more efficient.  When I first started reading blogs and KB articles to implement KMS, it seemed like you could just spin up a KMS server using Server 2008 r2, input the KMS key and wipe your hands of it.  I quickly found out that was not the case.  With any luck, this blog post will help others with the various caveats I came across.

The initial installation is as easy as I described in the paragraph above.  You can either build a new Windows 2008 r2 server (this can be done in 2003 and 2008, but it is a bit more difficult) or use an existing server.  It can be a virtual machine!  Then obtain your KMS key from www.microsoft.com/licensing.  Use that key to activate the server.  Now if you go to the command line, type “slmgr /dlv” or “slmgr /dli” to see the current status of your KMS licenses.  Check this link to see other commands.  Don’t be surprised if it doesn’t just start working, though.

I have read that it will automatically populate the DNS with the proper information, but in my environment I had to do it manually.  Not only do you need a Host (A) record, but you also need a SRV record.  To configure this:

1. Open the DNS configuration manager.
2. Expand Forward Lookup Zones
3. Click on your domain (ex: acme.org)
4. Right click on your domain and select Other New Records.
5. Select the SRV (Service Location) option.
6. Here is the information you’ll need to input:

Domain: YourDomain.org (ex: acme.org)
Service: _VLMCS
Protocol: _tcp
Priority: 0
Weight: 0
Port Number: 1688
Host Offering This Service: fqdn of you kms server (ex: kmsserver.acme.org).
You should now be able to check if you have it configured correctly by typing this in the command line:  nslookup -type=srv _vlmcs._tcp and this should return your KMS server information.

It seemed like everything was working well for me at that point.  I ran the slmgr /dlv command on the KMS server and the count had gone up.  I forced the activation on another client using the slmgr /ato command and the count went up again.  At that point I deployed a new laptop using our imaging software; checked the count again, but to my chagrin the count did not go up.  I realized that we don’t use sysprep to create our images.  This is something to not be taken lightly when it comes to KMS.  So, I needed to create a new image.  This time I ran sysprep and made sure to put a check next to the generalize option.  The problem when you don’t click the generalize option is that the same Client Machine ID (CMID) is given to all your computers and the KMS server isn’t able to differentiate the client machines.  Therefore, it thinks the same computer is checking in the whole time and will not increase the count.  Keep in mind that if you can’t increase the count, you’ll never reach the magic number.  In order for KMS to activate client machines successfully, you need to have at least 25 Windows 7 machines or five Windows Servers checking into the KMS server.  These are separate, meaning if you get five servers checked in your Windows 7 clients still won’t activate successfully until you hit 25.  You will see an error after trying to force the activation that says there is an insufficient count.  After you meet 25 (or 5 servers) all of the previous clients will then activate.  By default you get 180 days to meet this number and you can rearm the 180 days a few times if you’re afraid you won’t meet that number in 180 days.

In case you were thinking of “hacking the system” and just deploying the same machine several times until you hit that number (not that any of you would do that), Microsoft has figured out a way to prevent that.  Basically, KMS checks every seven days to make sure computers are still checking in.  If after 30 days a KMS client is not checking in, it no longer count it and your KMS count will go down.  This is a nice feature after you’ve reached the 25 count, though, because it will let you keep track of how many computers are actually still deployed keeping your license count fairly accurate.

It’s also possible to use KMS to license your Office 2010 deployments.  In order to force activation on the Office deployments, you can use the following command lines depending on your platform:

32-bit:

Cscript "C:\Program Files\Microsoft Office\Office14\OSPP.VBS" /act

64-bit:

Cscript "C:\Program Files(x86\Microsoft Office\Office14\OSPP.VBS" /act

It’s not such a horrible configuration, now that I know how to do it.  Though, with licensing, nothing is ever easy.  There are GUI tools such as the Volume Activation Management Tool (VAMT) to manage this as well; however, I’ve had more luck just using the command line.