Updated on : 11/08/2016 (Windows 10 KMS patch compatibility)
Relevant to: KMS – all versions
KMS seems to be one of those things that is sometimes quite poorly understood – and many existing blog articles or pieces of documentation seem to gloss over important details (IMO). So, below is my attempt.
MAK – Multiple Activation Key
This type of key is intended to be used on multiple computers, but must be entered manually, via VAMT or in an SCCM task sequence. The activation process occurs once per machine either directly over the internet, via a MAK proxy or via telephone.
The MAK activation method is best suited for
- Small organisations with 25 or less computers
- Organisations who have certain machines which are not domain joined and/or do not connect to the business network regularly
KMS – Key Management Server(s)
A Key management server is a service which provides activation on behalf of clients. The KMS server is activated once, and in turn, clients will auto-locate and activate against the KMS service. (more about the details a bit later)
KMS Key – Key Management Server Key
This type of key is intended to be used on a Key Management Server to provide activation for clients and has a couple of important factors:
- KMS requires what is called an “activation threshold”, which basically means that until you have more than 25 Windows 7/8/8.1 activations or more than 5 Windows Server 2008 R2/2012/2012 R2 activations, the KMS server is not active
- To remain active, KMS clients must contact the KMS server once every 180 days. If it does not, the client will start showing activation messages.
I would imagine that if you are reading this blog you are familiar with what volume licensing is. KMS and MAK are both used for volume licensing customers, you cannot activate retail or OEM operating system installs using these methods.
Decisions to be made prior to install
KMS or MAK
Many organisations we deal with use both.
If a machine is off the network for long periods of time or is not domain joined, use a MAK. (Please note that non-domain joined machines can still use a KMS, but usually there is a reason they are not domain joined, which may also mean they cannot access the KMS!)
For all the domain-joined, generally on the network machines, use KMS.
Choosing a KMS key
In my opinion, the Microsoft doco @ http://technet.microsoft.com/en-us/library/ff793412.aspx and http://technet.microsoft.com/en-us/library/ee939271.aspx makes it sound complex.
In short, go with the “highest” version of server you have available and it can then activate everything “below” it.
If you utilise the Server 2012 R2 standard key (KMS B), it can act as an activation server for 2008R2/2012/2012R2 standard and Win7/8/8.1, but it cannot activate datacentre editions.
If you utilise the Server 2012 R2 datacentre key (KMS C), it can activate other datacentre editions as well as all 2008R2/2012/2012R2 standard/datacentre and Win7/8/8.1.
“But I only want to license Windows 7 machines!” the response frequently comes back.
A KMS key will also license all products that are “lower” in the tree, so using a server 2012 R2 standard KMS key will allow you to license all windows 7 machines (as well as windows 8/8.1 and server 2008R2/2012/2012 R2)
“So why do I have a Windows 7 KMS key then?” is the next question
This is because it is an option to install a KMS on Windows 7, simple as that. This is something we would generally advise against, as most organisations that use a KMS would use it for their servers and workstations.
Choosing a KMS server – OS Version
Using the newest operating system in your environment generally means that you will not need to download additional updates or patches, so simply for that reason, we would recommend using the newest OS version you have available.
Choosing a KMS server – Server load & placement
The KMS role is a very low-load role and we have never had any issues co-locating it with other roles. One common pairing is placing the KMS role on the SCCM primary site server (for organisations of up to 5000 PC’s)
For larger organisations, we see various approaches. Some have dedicated KMS servers, some co-locate on other services.
This section is here because often people ask what the load is like and can be co-located with other roles. The short answer is, very low load service and it be co-located with anything that doesn’t need TCP 1688.
KMS publishing and load balancing
KMS, by default listens on port TCP 1688 and will (by default) publish a DNS SRV record to allow domain-joined clients to locate the KMS service. The record created is called _vlmcs
Windows 7/2008 R2 and above volume license operating systems automatically look for this DNS record.
SRV records have a weight and priority associated with them, and this, by its nature, allows multiple KMS’ to be published and administrators to use them in a round-robin scenario (same priority) or in a fault-tolerance scenario (different priorities)
It is possible to disable publishing for a KMS service, but this is not something we have ever done – and we are not quite sure of a scenario where this would be helpful (but this doesn’t meant there isn’t one!)
Patching KMS to support Windows 10
In order to support Windows 10, you will need to patch your 2008R2, 2012 or 2012R2 KMS server as per
Office 2010 and 2013 have KMS add-on packs, that can be installed on an existing KMS server, these are available at:
Office 2010 KMS Host – http://www.microsoft.com/en-au/download/details.aspx?id=25095
Office 2013 KMS Host – http://www.microsoft.com/en-us/download/details.aspx?id=35584
Office 2016 KMS Host – https://www.microsoft.com/en-us/download/details.aspx?id=49164
Installing KMS + Office KMS step by step
These steps remain the same whether you are installing on Windows 2008 R2, 2012 or 2012 R2.
- Decide which server will host your KMS. We recommend utilising the latest server version you have access to and the highest “edition” (at the time of writing, this is Server 2012 R2 Datacentre)
- Logon to the server and open an elevated command prompt (this process will fail if you do not elevate the command prompt!)
- Cd windows\system32
- Cscript slmgr.vbs /ipk <your product key, with the dashes>
- Cscript slmgr.vbs /ato
- You now have a KMS server
- To verify the install and look at the number of currently activated machines
- Cscript slmgr.vbs /dlv
- To install the Office KMS host (we will use 2013 in this example, however it is very similar to the 2010 process)
- Download the KMS host update from the links above
- Run the install
- Enter your product key when prompted
- To verify the install and look at the number of currently activated machines
- Cscript slmgr.vbs /dlv all
- Look for the appropriate office 15 (or 14) section
Question: I want to move my KMS server, how do I move the activation database etc.?
Answer: There is no activation database or anything that needs to be moved. Simply create a new KMS, install the KMS key and activate. Then decommission the “old” KMS by running slmgr.vbs –upk (uninstall product key) and then either delete the “old” _vlmcs record from DNS, or use slmgr.vbs -cdns
Question: If my KMS client is off the network for more than 180 days, what do I do ?
Answer: Simply re-attach it to the network, it will find the KMS server and renew its activation. If the client will regularly be off the network for more than 180 days, it would be wise to consider using a MAK for this client.
Question: The SRV record has not registered in DNS.
Answer: Sometimes a restart of the KMS service is required. Net Stop sppsvc then net start sppsvc
Sometimes, if an existing record already exists from a previous KMS, you may need to grant permissions over the DNS record, but frankly, its easier just to delete it and restart the KMS service (command above)
Mistake: Using a KMS key on a number of client machines, either because the difference between MAK and KMS wasn’t clear, or my licensing person gave me the wrong key.
This can be quite easily fixed by changing the key on the affected clients :
- Part 1 – identifying affected clients
- Open DNS admin, and navigate to <your domain>\_tcp
- Take note of all the _vlmcs records – these are all the KMS hosts on your network
- Part 2 – fixing up those clients
- Install the default KMS on these machines. The default KMS keys can be found at http://technet.microsoft.com/en-us/library/jj612867.aspx
- This can be done manually (if there is a small number) or using the VAMT if there is a larger number – http://www.microsoft.com/en-AU/download/details.aspx?id=11936&Search=true
- Part 3 – cleaning up
- Delete the additional _vlmcs records from your DNS
Mistake: Deploying MAK keys in a task sequence, when you actually want to use a KMS.
If you want to use KMS, simply leave the product key section in your task sequence blank.
To “fix” existing clients, you will need to identify the machines with a MAK and install the default KMS key. The VAMT can be used to help identify and update these machines.
Mistake: Using the windows 10 KMS key on a server results in Error 0xC004F015
You need to use the server KMS keys on a server OS (as discussed above), please read the above article or visit https://support.microsoft.com/en-us/kb/3086418
Official doco references
Understanding MAK activation – http://technet.microsoft.com/en-us/library/ff793435.aspx
Understanding KMS activation – http://technet.microsoft.com/en-us/library/ff793434.aspx
Default KMS keys – http://technet.microsoft.com/en-us/library/jj612867.aspx
Deploying KMS – http://technet.microsoft.com/en-us/library/ff793409.aspx