A Key Management Server (KMS) system is any server in your environment that you have installed using a KMS key. That’s right, any system—Windows Vista included. I have seen customers of varying sizes running multiple KMS instances, sometimes five, ten, or even more in a single environment. Yikes! As stated in Part One of this series, “Windows Activation: The Basics,” do not use a KMS key unless you fully understand its implications and how it works.
How the KMS Windows Activation Process Works
KMS servers are responsible for responding to activation requests from Windows Vista, Windows Server 2008 systems, and, eventually, Windows 7. Unlike older Windows versions, all Vista and 2008 systems require activation. For volume-licensed environments, these systems can be activated using an in-house KMS instead of the standard Microsoft activation servers.
Discovering a KMS Server
Volume licensed systems locate a KMS using DNS and SRV records, as described in Part One of this series. Properly configuring these records is essential to ensure that clients can find your KMS server when needed.
The KMS Activation Thresholds
Each KMS server maintains an internal counter of how many clients it has activated. This value is crucial:
- Windows Vista clients will only activate if the KMS counter is 25 or higher.
- Windows Server 2008 systems require a minimum of five.
Once the required threshold is reached, the KMS server will successfully activate clients. The maximum value for this counter is 50. After that, the KMS stops incrementing the counter, even if additional clients are activated.
KMS Servers Operate Independently
KMS servers operate as stand-alone entities, and they do not coordinate with each other. Having multiple KMS servers in an environment can lead to complications and prevent systems from being activated properly if not managed carefully.
KMS Client Behavior and Activation Period
When a client attempts to activate, it is assigned a unique ID that is tracked by both the client and the KMS. After the initial activation, clients will:
- Attempt to re-contact the KMS every seven days.
- Deactivate if they cannot reach the KMS within 180 days.
Similarly, the KMS server will remove a record of an activated system if it has not communicated with the server in 180 days. If this causes the activated count to drop below the minimum threshold (five or 25), other systems may also fail to activate when they next attempt to contact the KMS.
Product Key Requirements for KMS Activation
When a system contacts a KMS for activation, it also passes its product key. The KMS then validates the product key before generating a client ID and successfully adding the client to its list of systems.
Understanding KMS Client Keys vs. KMS Server Keys
It’s important to differentiate between KMS client keys and KMS server keys:
- KMS Client Keys: These are the generic keys automatically installed on volume-licensed products. They are not unique and are available for public use. KMS client keys are required for systems that need to activate against a KMS. If you have installed another type of key on a system that you want to activate using KMS, you must first remove the existing key and replace it with the appropriate KMS client key.
- KMS Server Keys: There are four distinct levels of KMS server keys—Client, A, B, and C. Each level determines which editions of Windows the KMS can activate. Regardless of the key group, any edition of Windows can host a KMS server.
Choosing the Right KMS Key for Your Environment
You should always install the KMS key for the highest product level that your organization is licensed for. This ensures compatibility and simplifies activation management. Below is a brief overview of the four KMS server key levels:
| KMS Server Key Level | Description |
|---|---|
| Client | Activates only client operating systems. |
| A | Activates standard client and server OS. |
| B | Activates mid-tier server and enterprise OS. |
| C | Activates all client and server OS versions. |
Best Practices for Designing a KMS Infrastructure
Having multiple KMS servers in an environment can complicate activation if they are not configured properly. Here are some key considerations to keep in mind when designing your KMS deployment:
Plan for Redundancy: If high availability is a concern, consider using a backup KMS server rather than deploying many independent ones.
Minimize the Number of KMS Servers: Avoid unnecessary duplication of KMS servers. The more servers you have, the higher the likelihood of inconsistent activation behavior.
Use DNS for KMS Server Discovery: Ensure that your KMS servers are correctly registered in DNS using SRV records. Clients rely on these records to discover and communicate with the KMS.
Monitor Activation Counters Regularly: Keep an eye on the activation counters to ensure that they meet the minimum threshold requirements.
| Volume Product Key Group | KMS Key Type | Windows Editions |
| Client | VOLUME_KMSCLIENT | Windows Vista Business Windows Vista Enterprise |
| A | VOLUME_KMS_A | Windows Web Server 2008 Editions listed in the Client Key Group |
| B | VOLUME_KMS_B | Windows Server 2008 Standard Windows Server 2008 Standard without Hyper-V Windows Server 2008 Enterprise Windows Server 2008 Enterprise without Hyper-V Editions listed in the A Key Group |
| C | VOLUME_KMS_C | Windows Server 2008 Datacenter Windows Server 2008 Datacenter without Hyper-V Windows Server 2008 for Itanium-Based Systems Editions listed in the B Key Group |
KMS is a very low overhead service that is hosted by the Software Licensing service. The general recommendation is to use a core services system such as a domain controller to also be your KMS system. Because systems do not immediately deactivate if they cannot contact a KMS, high-availability and redundancy are almost non-existant concerns. In the event of a failure of the KMS system, simply set up a new one.
That’s it; it really is that simple. There are always more details, but that covers most of it.
