Common KMS Licensing Mistakes and Solutions

This is probably going to be a relatively short one.  Here we are, 4 years after the initial release of Server 2008.  4 years after the initial implementation of KMS licensing… and I’m still coming across all sorts of confusion about how it works and how to use it.  I’m tired of seeing unintentional rogue KMS servers pop up on client networks, and so I’m going to rehash what many other people have already covered: how KMS licensing differs from Volume License Keys.  They are not at all the same, and if you try to use a KMS license key the way you would have used a VLK, your environment is going to get messed up.

First, here’s some supposition about why the change happened.  When someone’s VLK leaked into the wild, it was basically a gravy train for every pirate who knew how to use google.  Since, by its very nature, a VLK was designed to allow many systems to activate, it meant that many pirate systems would be activated.  At best, Microsoft could kill that key (in theory) to prevent further activations, issuing that customer a new one… I don’t know if this ever actually happened, but it’s really not a good scenario for Microsoft as it involves a fair amount of work for them and they’ve already suffered a lot of piracy before they can remediate anything.  I think that KMS Licensing was, in part, a response to this undesirable scenario.

KMS licensing is different – it’s basically distributed activation.  You activate your KMS Licensing Server (or, perhaps Servers), and every other device in your environment talks to that system for its activation.  As I recall, once a system has activated with a KMS Server, it can go up to 180 days without talking to that server again (although I think that it tries to communicate every 24 hours, or something similar).  A given KMS Server License only needs to be installed once, on a single server, in a given environment, although it’s a fine idea to create multiple installations for redundancy or load distribution.  Every other device in the environment, be they desktops or servers, will use KMS Client Keys.  Better yet, if you don’t enter any key during the installation of one of these newer Operating Systems, they default to the appropriate KMS Client Key!  That means that you only need to configure licensing on your finite, engineered number of KMS Licensing Servers, and never need to worry about entering a license key again.  By default, a KMS Server will advertise itself by creating a Service Location record named “_vlmcs”, which the clients, by default, will look for when they need to license themselves.  It’s really that easy.

This model works great for Microsoft.  Since a given customer does not need to activate their KMS License for every server in their environment (remember, it only activates when the KMS Key is installed), Microsoft can make the very reasonable assumption that a given KMS License key must only activate a few times.  Microsoft has decided that a given KMS License key must only activate 6 times, actually.  After that, you’ve got a phone call with Microsoft Support, as you explain why you need more activations of your key.  That means that, if a KMS key leaks to the wild, the damage that can be inflicted is limited to only 6 sites (and that’s assuming that the key was never used by its legitimate owner and that each pirate only activates one KMS server).

There’s another important aspect to this model – the concept of Operating System Groups.  Each KMS Server can only have a single KMS License registered in it, but you don’t need a KMS Server for every type of Operating System in your environment.  Instead, you just need to register your most expensive KMS License key on the KMS Server, and your less expensive Operating Systems are good to go (examine that link about Operating System Groups to see the details regarding OS Hierarchy).  What that means is that, even though you have a Windows 7 KMS Server key, a Windows 2008 R2 Standard KMS Server key, a Windows 2008 R2 Enterprise KMS Server key and a Windows 2008 R2 Datacenter KMS Server key… you only need to install that Datacenter key.  Since Datacenter is a “Group C” Operating System (which is the highest order OS), that key can provide activation services for KMS_A and KMS_B Operating Systems (or even the lowly Windows 7 “KMS” group that isn’t even good enough to get a group letter).

So, what do you do if you’re reading this too late?  You’ve already got a handful of Windows 7 desktops that are providing KMS Services, and your latest DMZ Web Server and who knows what else were all installed with KMS Server keys on accident?  Well, that’s where slmgr.vbs comes into play.  Unlike older versions of their operating systems, it is very easy to replace your license key in Windows 2008+ OSes.  To turn one of those accidental KMS Servers back into a KMS Client, just use slmgr /ipk <appropriate KMS Client Key> from an elevated command prompt.  If you read the article on slmgr, you’ll see that you can even issue the command remotely.  If you’re unsure of what systems may be acting as rogue KMS servers, just look in DNS, under the “_tcp”  node of your domain’s Forward Lookup Zone.  Every Service Location record named “_vlmcs” is a computer with a KMS Server key installed.

If you’ve got a lot of accidental KMS Servers, you’ve probably noticed that your Clients aren’t working too well.  A KMS Server does not activate clients until it hits a certain client count (if memory serves, it’s 50 Desktop activations or 5 Server activations, whichever comes first).  If you’ve got a whole mess of accidental KMS Servers, none of them are likely to hit that count and so none of your clients are likely to activate (unless you’ve got a ton of KMS clients).  This fact can make it difficult to convert the accidental KMS Servers into KMS Clients, as there’ll be some activation issues until everything is sorted out.

Never fear, there’s an easy solution.  Find your DNS Record for a valid KMS Server, then double click on it to edit it.  You’ll see that there is “Priority”, “Weight” and “Port number”.  KMS clients contact the KMS Servers in order of their Priority, lowest numbers first.  If multiple servers have the same Priority, the clients get load balanced according to the Weight of the servers.  Here’s a gap in my knowledge – I know that Weight distributes client load between the various KMS Servers, with higher Weighted servers receiving more traffic.  What I have done, in that rogue KMS Server scenario, is set the Weight of my real KMS Server to 100.  This has resulted in my KMS Clients all hitting the real server and everything happening.  I don’t know if, in a 2 KMS Server environment, each should have a Weight of 50, or if they should both have 100 Weight.

Setting the Weight, at least for any long term, is not as simple as changing the DNS record; the server created that record and will set it back to 0 if you don’t make a change on the server itself.  Fortunately, it’s an easy registry change.  Just create a reg_multi_sz value named “DnsDomainPublishList” under the following key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform.  Give that value data in the following format: <Domain>, <Priority>, <Weight>.  So, to set this KMS Server to a Weight of 100, I would use the following: "customer.local, 0 ,100".  After that, restart your KMS Server service (or the server) and it should update its own DNS record with the configured Weight.

Ok, so maybe it wasn’t such a short post after all, and maybe I wrote a bit more than the basics about how KMS differs from VLK.  Oh well, it's good information, so I'm glad to have it recorded.