A GUIDE TO TROUBLESHOOTING KEY MANAGEMENT SERVICE (KMS)

I had a project to work on that involved Key Management Service. Here is a write up on different troubleshooting tips and techniques to make your life easier. Below are excerpts and some data taken from a pretty good technet article.

If you are a windows user then you must be aware of the license activation methods in Windows. However many enterprise customers set up the Key Management Service (KMS) to enable activation of Windows in their environment. It is a simple process to set up the KMS host and the servers activating and the KMS clients discover and attempt to activate on their own.

KMS Overview

KMS client-server model is conceptually similar to DHCP. Instead of handing out IP addresses to clients on their request, KMS enables product activation. KMS is also a renewal model, with the clients attempting to reactivate on a regular interval. There are two roles: the KMS host and the KMS client.

  • The KMS host runs the activation service and enables activation in the environment. The KMS host is the system where you will need to install a key (the KMS key from the Volume License Service Center (VLSC)) and then activate the service. The service is supported on Windows Server 2003, Windows Vista, Windows 7, Windows Server 2008, or Windows Server 2008 R2 and also the newer Windows Server 2012.
  • The KMS client is the Windows operating system that is deployed in the environment and needs to activate – basically your servers that you deploy in your environment. KMS clients can be running any edition of Windows that uses Volume Activation which include Windows 7, Windows Vista, Windows Server 2008 R2, and Windows Server 2008 and the recently released Windows 2012 Servers as well. The KMS clients come with a key pre-installed, called the Generic Volume License Key (GVLK) or  also called as KMS Client Setup Key. The presence of the GVLK is what makes a system a KMS client. Think of the GVLK as a way how that client knows it needs to look for a KMS host. For the whole thing to work – you have to have the DNS SRV record setup. The KMS clients find the KMS host via a DNS SRV record (_vlmcs._tcp) which allows them to discover and use the service to activate themselves. When in the 30 day Out of Box grace period, they will try to activate every 2 hours. Once activated, the KMS clients will attempt a renewal every 7days.

There are two areas of check on the KMS host. To check the status of the software license service on the host. From an elevated command prompt, type SLMGR.vbs /dlv. This will give you verbose output of the Software Licensing service. 

kms1

Below is a list of the information

  • Version Information
    • At the top of the SLMGR.vbs /dlv output is the Software Licensing Service Version. This may be useful to determine if the current version of the service is installed. For example, updates to the KMS service on Windows Server 2003 support different KMS host keys. This data can be used to evaluate whether or not the version is current and supports the KMS host key that you are attempting to install. See KB968195 for more information on these updates.
  • Name
    • This will tell you the edition of Windows that is installed on the KMS host system. This can be important when troubleshooting if you are having trouble adding or changing the KMS host key (e.g. to confirm the key is supported on that OS edition).
  • Description
    • This is where you will see the key that is installed. Use this field to confirm which key was used to activate the service and whether or not it is the right one for the KMS clients that you have deployed.
  • License Status
    • This is the status of the KMS host system. This should be Licensed. Anything but that means something is wrong and the host may need to be reactivated.
  • Current Count
    • The count displayed will be between 0 and 50. The count is cumulative (between operating systems) and contains the number of valid systems that have attempted to activate within a 30 day period.
    • If the count is 0, it is a newly activated service or no valid clients have connected to the KMS host.
    • The count will not increase above 50, no matter how many valid systems exist in the environment. This is because they count is set to cache only 2 times the maximum license policy returned by a KMS client. The maximum policy today is set by the Windows client OS, which requires a count of 25 or higher from the KMS host to activate itself. Therefore, the highest count on the KMS host is 2 x 25, or 50. Note that in environments with only Windows Server KMS clients, the maximum count on the KMS host will be 10, as the threshold for server is 5 (2 x 5, or 10).
    • A common issue related to count is where the environment has an activated KMS host and a sufficient number of clients, but the count does not increase beyond 1. The core problem is that the deployed client image was not configured correctly (sysprep /generalize) and the systems do not have unique Clint Machine IDs (CMIDs). See the KMS Client section (below) and KB929829 for more info.  This has also been blogged by one of our Support Escalation Engineers.
    • Another reason why the count may not be increasing is that there are too many KMS hosts in the environment and the count is distributed over all of them.
  • Listening on Port
    • Communication with KMS is via anonymous RPC. 1688 is the default TCP port used by the clients to connect to the KMS host. Make sure this port is open between your KMS clients and the KMS host. The port can be changed and can be configured on the KMS host. The KMS clients receive this port designation from the KMS host during their communication. If you change the port on a KMS client, it will be overwritten when that client contacts the host.

To troubleshoot any issues check out the event log. The event, 12290, shows that a KMS client contacted the host in order to attempt activation. There will be a 12290 entry in the Key Management Service log on the KMS host system for each client that attempts to activate. If you don’t see this event for a client that you are troubleshooting, that client is not connecting to the KMS host. There are two corresponding events on the KMS clients, 12288 and 12289, which will be covered in the KMS Client section. Some of the reasons why a 12290 event may not exist:

  • Network outage
  • Host not resolving/registered in DNS
  • Firewall blocking TCP 1688
    • This can happen in many places within the environment, including on the KMS host system itself. By default, the exception for KMS exists in the firewall configuration dialog. However, it is not enabled automatically. You will need to turn on the exception.
  • Log full

The 12290 event entry gives a significant amount of information that can be used to figure out what kind client contacted the host…and why a failure may occur.

KMS Client

On the clients you will also use the same process (SLMGR and Event Viewer) to troubleshoot activation. From an elevated command prompt, type SLMGR.vbs /dlv. This will give you verbose output of the Software Licensing service. The screenshot below is from my machine, a KMS client within Microsoft.

kms2

Below is a little more about each field.

  • Name
    • This will tell you the edition of Windows that is installed on the KMS client system. Use this to confirm that the version of Windows you are attempting to activate can use KMS. For example, our help desk has seen incidents where customers are attempting to install the KMS Client Setup Key on an edition of Windows that does not use volume activation, such as Windows Vista Ultimate.
  • Description
    • This is where you will see the key that is installed. VOLUME_KMSCLIENT indicates that the KMS Client Setup Key (or GVLK) is installed (default for volume license media) and that this system will automatically attempt to activate using a KMS host. If you see something else here, such as MAK, then you’ll need to reinstall the GVLK for this system to be a KMS client. You can do that manually (slmgr.vbs /ipk <GVLK>) or use the Volume Activation Management Tool (VAMT). VAMT is part of the Windows AIK.
  • Partial Product Key
    • As with the Name field above, you can use this information to determine that the correct KMS Client Setup Key is installed on this machine (e.g. matches the operating system that is installed on the KMS client). By default, the correct key will be present on systems built using media from the Volume License Service Center (VLSC) portal. In some cases, customers may use Multiple Activation Key (MAK) activation until there are a sufficient number of systems in the environment to support KMS activation. The KMS Client Setup key will need to be installed on these systems to transition them from MAK to KMS. VAMT can be used to install this key and ensure the correct one is applied.
  • License Status
    • This is the status of the KMS client system. This should be Licensed for a system that has been activated with KMS. Anything but that may indicate there is a problem. For example, if the KMS host is good and the KMS client will not activate (e.g. in a Grace state) then there may be something preventing the client from reaching the host system (such as firewall issues, network outage, etc.).
  • Client Machine ID (CMID)
    • The CMID should be a unique value per KMS client. As I mentioned in the KMS host section, a common issue related to count is where the environment has an activated KMS host and a sufficient number of clients, but the count does not increase beyond 1. See KB929829 for more info.
  • KMS Machine Name from DNS:
    • Here is where you will find the FQDN of the KMS host that the client successfully activated with and the TCP port used for the communication.
  • KMS Host Caching
    • The final entry is to show whether or not caching is enabled. It is by default. What this means is that the KMS client will cache the KMS host that it was able to activate with and will communicate directly with this host when it is time to reactivate (instead of querying DNS). If the client cannot contact the cached KMS host, discovery with DNS will be used.

A successful activation/reactivation on the client will have two events, 12288 and 12289. If you only see the 12288 event (without a corresponding 12289) it means that the KMS client was not able to reach the KMS host or it did not respond/response was lost. In this case, confirm that the KMS host is discoverable and reachable by the KMS client systems.

Hope this was helpful, most of the article was taken from here. This article helped me greatly so I removed the unimportant parts in my post.

Let me know what you think 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

Post Navigation