KMS and MAK Licensing

Posted by Adam Fowler on Jul 31, 2014 in Deep Tech | Comments Off on KMS and MAK Licensing

Microsoft licensing is one of the things that puts fear into most people who have dipped their toes into it. Understanding how to be compliant with Microsoft – and how to make sure the company’s money is being spent properly – can be daunting. From an admin’s side, this is often not a concern as it’s not a part of their job – but at least understanding the implications of installing 10 different SQL servers in the environment is a necessity. One of the more fundamental models Microsoft now uses with Windows Server, Windows Client (e.g. Windows 7) and Office is using a key to register the products. So, how do you do it if you’re on a Volume Licensing Agreement?

What are KMS and MAKs?

With a Volume License Agreement with Microsoft, you are normally given two types of keys: Multiple Activation Key (MAK) and Key Management Services (KMS). The MAK will normally have an activation count, while the KMS does not. Simply put, MAK is a key that registers direct back to Microsoft with a certain amount of allowed activations. KMS on the other hand, lets all your clients use a generic key to talk back to a KMS Server on premise, and that centralised server talks back to Microsoft. The MAK side of things is pretty straight forward: you put a different key in per client, it will phone home and then either activate or fail. This works, but isn’t the way you should do things in a large environment. KMS gives you that automation.

KMS sounds great, how do I set that up?

I’ve written about this before on How To Enable Office 2013 KMS Host and How to add your KMS keys for Windows 8 and Server 2012, so I’ll just clarify how the process works. There are two types of KMS keys – client and server. The client key is normally the default key installed when using a volume license version of software, and the keys are publicly available. Here’s a list on Technet of keys. The KMS server needs to be configured as per my “How to” articles. Having a KMS Client key registered on your client will make it go through a different process of phoning home and check DNS records. The KMS server on premise gets the request, approves and activates the client. Technet as per usual has great documentation covering all of this, available here.

I’ve set it up and it’s not working – help!

OK, don’t get too worried here. First, you need to have enough clients trying to register on your KMS server before it will activate any of them. For Windows Client operating systems, you’ll need 25. Yes, that’s a lot. For Windows Servers and Microsoft Office, you’ll only need 5.

For an example, let’s say you’ve installed Microsoft Visio 2013 and it’s not registered (if you’re unsure if it’s registered or not, in Visio go to File > Account. On the right hand side it will tell you if the product is activated or not). Start by checking that you have a correct KMS key entered – you can re-enter it in the product.

You can force the activation of Office 2013 by going to the folder where it’s installed (by default it’s C:\Program Files (x86)\Microsoft Office\Office15) and running the command:

cscript OSPP.VBS /act

This will either tell you that you’ve successfully activated your product, or give an error. One of the most common errors is:

ERROR CODE: 0xC004F038
ERROR DESCRIPTION: The Software Licensing Service reported that the product could not be activated. The count reported by your Key Management Service (KMS) is insufficient. Please contact your system administrator.

Nice description. So, next up you’ll need to check your count reported on the KMS server. Forgot what server your KMS server is? You might be able to find out by using the command:

slmgr /dlv

which will give you an informative window telling you the KMS machine name from DNS. Or you can check your DNS for the entry from the DNS console under DNS Server > Forward Lookup Zones > internal domain name > _tcp > _VLMCS record.

On your KMS server, you can display the client count so far, to see if it’s hit the magic 5 with this command:

cscript slmgr.vbs /dlv 2E28138A-847F-42BC-9752-61B03FFF33CD

The string on the end is the Office 2013 Activation ID. For Office 2010 it’s “bfe7a195-4f8f-4f0b-a622-cf13c7d16864”. You’ll see a lot of information, but the important part is this:

Key Management Service is enabled on this machine
Current count: 5
Listening on Port: 1688
DNS publishing enabled
KMS priority: Normal

In this example, I’ve just hit the 5 so clients will now activate. If it was less than 5, I’d still be getting the previous error on the clients I had.

If you generally want to see what licenses you have on the KMS server, you can run the ‘Volume Activation Management Tool’ which is available as part of the Windows Assessment and Deployment Kit (ADK). Install instructions from Technet are available here. This tool will visually show you what products you have licensed, but won’t go into great detail. It’s good to have just as an overview.

There are other scenarios and issues that can happen with KMS activation. On the KMS server, you can check the KMS event logs in Event Viewer under Applications and Service Logs > Key Management Service. On the client, there are a huge amount of switches you can use with the slmgr.vbs script – you can run it without any switches to see them all.