Troubleshooting KMS Activation: Why Your Windows Client Count Isn't Increasing

Table of Contents

This article addresses a common issue encountered by system administrators managing Windows licensing using Key Management Service (KMS). Specifically, it focuses on situations where the expected increase in client counts on the KMS server fails to materialize after adding new Windows-based client machines to the network. This problem can be perplexing, as it directly impacts the ability to activate newly deployed systems, leading to potential licensing compliance issues and operational disruptions.

Symptoms¶

The primary symptom of this problem is that the client count displayed by the KMS server remains stagnant despite the addition of new Windows client computers to the network infrastructure. To verify this, administrators typically utilize the Slmgr.vbs script, a command-line tool designed for software licensing management in Windows. Executing Slmgr.vbs with the -dli argument provides detailed licensing information, including the current client count maintained by the KMS server.

When this issue occurs, running cscript c:\\windows\\system32\\slmgr.vbs -dli on the KMS server will show no increment in the “Current count” value after new clients are deployed and attempt activation. Furthermore, the Key Management Service event log on the KMS server may record events related to these new client machines. These events often highlight activation attempts from the new clients but fail to contribute to the overall client count.

In essence, while new Windows machines are being added to the network and attempting to activate against the KMS server, their activation requests are not being properly registered and counted by the KMS service. This discrepancy between the deployed clients and the KMS server’s recorded count is the core symptom of this troubleshooting scenario.

Cause¶

The root cause of this issue often lies in duplicate KMS Client Machine IDs (CMIDs) among the Windows client computers. The KMS server is designed to increment its client count only when it encounters clients with unique CMIDs. If multiple client machines present the same CMID during their activation attempts, the KMS server recognizes them as the same machine and does not increase the count for each subsequent request from a client with a pre-existing CMID.

This duplication of CMIDs typically arises from specific image deployment practices. Two primary scenarios contribute to this problem:

1. Improper Image Preparation without Sysprep /generalize: When a custom Windows image is created and deployed across multiple machines without properly running the System Preparation tool (Sysprep.exe) with the /generalize option, the resulting deployments often inherit the same CMID. Sysprep with /generalize is crucial because it resets the system’s unique security identifiers and prepares the image for duplication. Skipping this step leads to cloned systems with identical CMIDs.

2. Incorrect Use of <SkipRearm> in Unattended.xml: Even when Sysprep is used with the /generalize option, the problem can still occur if the Unattended.xml file used during deployment includes the <SkipRearm> setting. Setting <SkipRearm> to 1 prevents the Windows Rearm process from running during deployment. The Rearm process is essential for resetting the activation timers and, more importantly, generating a new, unique CMID for each deployed system. By skipping Rearm, the deployed machines retain the CMID from the base image, leading to duplicates across the environment.

To confirm if duplicate CMIDs are indeed the cause, administrators can manually check the CMID of affected client machines. The following procedure outlines how to verify CMIDs:

1. Open Command Prompt as Administrator: On a suspected client machine, access the Command Prompt with administrative privileges. This ensures that the necessary licensing scripts can be executed. Navigate to the Start menu, then Windows System, right-click on Command Prompt, and select “Run as administrator”.

2. Execute slmgr.vbs -dli command: In the elevated Command Prompt window, type the command cscript c:\\windows\\system32\\slmgr.vbs -dli and press Enter. This command executes the Software Licensing Manager script and displays detailed licensing information.

3. Examine the CMID: In the output of the command, locate the line labeled “Client Machine ID”. Note down the alphanumeric value presented as the CMID. This is the unique identifier for software licensing purposes on that specific machine.

4. Repeat on another client: Perform steps 1-3 on another Windows client machine that is experiencing the KMS count issue. Compare the CMID obtained from this second machine with the CMID from the first machine.

If the CMIDs from both machines are identical, it confirms that duplicate CMIDs are the likely cause of the KMS client count not increasing. This diagnostic step is crucial to differentiate this specific issue from other potential KMS activation problems.

Resolution¶

The recommended resolution to address the issue of duplicate CMIDs and the resulting KMS client count problem is to rebuild the base image used for deploying the affected computers. This ensures that all future deployments are based on a correctly prepared image that generates unique CMIDs for each client.

Rebuilding the base image involves recreating the master image used for deployment, ensuring that the correct Sysprep procedures are followed. Specifically, when creating the base image, it is imperative to run Sysprep with the /generalize option. This step is non-negotiable for environments utilizing image-based deployment and KMS activation. The /generalize command instructs Sysprep to remove system-specific information from the Windows installation, including the CMID, and prepare it for imaging.

Furthermore, if an Unattended.xml file is used to automate the Windows installation process during deployment, it is crucial to verify that the <SkipRearm> setting is not included or is explicitly set to 0. The absence of <SkipRearm> or setting it to 0 ensures that the Rearm process is executed during the deployment of each client machine. This Rearm process is responsible for generating a new, unique CMID for each deployed instance, resolving the duplicate CMID problem and enabling proper KMS client counting.

By rebuilding the base image with these considerations – Sysprep /generalize and correct <SkipRearm> setting (or absence thereof) – administrators can prevent the recurrence of duplicate CMIDs and ensure that the KMS server accurately counts new client machines as they are deployed and activated. This proactive approach is crucial for maintaining a healthy and compliant KMS environment.

Workaround¶

While rebuilding the base image is the recommended long-term solution, a workaround can be applied to address already deployed machines that are experiencing the KMS client count issue due to duplicate CMIDs. This workaround is applicable only if the original base image was created using Sysprep with the /generalize option, even if the <SkipRearm> setting was incorrectly used.

To determine if the /generalize option was used in the creation of the base image, administrators can examine the setupact.log file on an affected client machine. This log file records the actions performed during the Sysprep process. The steps to verify the use of /generalize are:

1. Access setupact.log: On one of the affected client computers, navigate to the following path in File Explorer: C:\\Windows\\System32\\sysprep\\Panther\\setupact.log. Open the setupact.log file using a text editor such as Notepad.

2. Search for “SYSPRP ParseCommands: Found”: Within the setupact.log file, search for lines containing the text "SYSPRP ParseCommands: Found". These lines indicate the command-line options that were parsed and executed by Sysprep during the image creation process.

3. Verify /generalize option: Examine the lines found in step 2. Look for a line that specifically includes "SYSPRP ParseCommands: Found supported command line option 'GENERALIZE'". The presence of this line confirms that the /generalize option was indeed used when creating the base image.

If the /generalize option is confirmed to be present in the setupact.log, the workaround involves manually rearming the affected client machines. The Rearm process, when executed on a client, resets the activation timers and generates a new, unique CMID. To rearm the affected computers, follow these steps:

1. Open Command Prompt as Administrator: On a Windows client computer with the duplicate CMID issue, open the Command Prompt with administrative privileges, similar to the process for checking the CMID.

2. Execute slmgr.vbs -rearm command: In the elevated Command Prompt window, type the command cscript c:\\windows\\system32\\slmgr.vbs -rearm and press Enter. This command initiates the Rearm process.

3. Restart the computer: After executing the slmgr.vbs -rearm command, restart the client computer. The restart is essential for the Rearm process to complete and for the new CMID to be properly applied.

By rearming the affected client machines, each computer will generate a new and unique CMID. Upon their next activation attempt against the KMS server, they will be recognized as distinct clients, and the KMS server client count should increment accordingly.

Important Note: This workaround is a temporary fix. It addresses the immediate issue on already deployed machines. However, to prevent future occurrences, rebuilding the base image with the correct Sysprep and <SkipRearm> configurations remains the essential long-term solution. Relying solely on the workaround for new deployments will perpetuate the duplicate CMID problem.

More Information¶

Understanding the Rearm process is crucial for grasping why duplicate CMIDs occur and how to prevent them. The Rearm process in Windows is designed to reset the activation timer and, critically, to establish a unique Client Machine ID (CMID). This process is fundamental to ensuring that each Windows installation is treated as a distinct entity for licensing purposes, especially within a KMS environment.

The Rearm process can be triggered in two primary ways:

1. Sysprep with /generalize: As previously discussed, running Sysprep with the /generalize option on the machine used to create a custom Windows image automatically initiates the Rearm process as part of the image preparation. This method is the recommended and most efficient way to ensure unique CMIDs for image-based deployments.

2. Manual slmgr.vbs -rearm command: The Rearm process can also be triggered manually on a running Windows system by executing the command cscript c:\\windows\\system32\\slmgr.vbs -rearm in an elevated Command Prompt. This is the method used in the workaround to rectify duplicate CMIDs on already deployed machines.

When the Rearm process is not executed – either because Sysprep /generalize was skipped during image creation or because <SkipRearm> was incorrectly used in an Unattended.xml file – client computers deployed from such images are highly likely to have identical CMIDs. This directly leads to the KMS server not incrementing the client count as expected, as it perceives these machines as duplicates.

The /generalize option in Sysprep is specifically designed for preparing a Windows installation for imaging and deployment. It is an indispensable step in scenarios where multiple identical systems are to be deployed from a single base image. Similarly, the <SkipRearm> setting in Unattended.xml should be used with extreme caution, if at all, in production environments. Its primary intended use case is in testing or non-production scenarios where frequent re-imaging and activation resets are required, but unique CMIDs are not a concern. In production deployments relying on KMS activation, <SkipRearm> should generally be avoided to ensure proper KMS client counting and licensing compliance.

In summary, the core principle to remember is that for every unique Windows client that needs to be counted and activated by a KMS server, a unique CMID is essential. The Rearm process, ideally triggered by Sysprep /generalize during image creation, is the mechanism that guarantees the generation of these unique CMIDs. Failing to properly utilize Rearm is the primary cause behind duplicate CMIDs and the resulting KMS client count issues.

If you continue to experience issues or have further questions about KMS activation and client counts, consider consulting the official Microsoft documentation on Volume Activation and Key Management Services for more in-depth information and advanced troubleshooting steps.

---

We hope this article has provided a clear understanding of why your KMS client count might not be increasing and how to resolve the issue. Do you have any experiences with KMS activation troubleshooting, or perhaps additional tips to share? Feel free to leave a comment below!