How to Configure Key Management Service for Windows Server 2003 SP1 and Later

How to Configure Key Management Service for Windows Server 2003 SP1 and LaterKey Management Service (KMS) is a Microsoft volume-activation technology that enables organizations to activate systems within their own network, without each client contacting Microsoft. This guide explains how to plan, install, configure, and troubleshoot KMS for Windows Server 2003 SP1 and later (note: KMS supports many Windows and Office versions beyond Server 2003). It focuses on configuring a KMS host and ensuring clients activate reliably.

Overview: What KMS does and when to use it

KMS provides internal activation for volume-licensed Windows and Office clients. Instead of each machine contacting Microsoft activation servers, a designated KMS host in the organization accepts activation requests and returns activation within the LAN. Use KMS when you have multiple machines to activate and prefer on-premises activation management. KMS requires a minimum number of clients (activation threshold) before it begins activating.

Key facts

• KMS requires a Volume License host key (CSVLK).
• KMS activation occurs over TCP port 1688 by default.
• Activation thresholds: 25 client Windows workstations or 5 server operating systems (numbers may vary by product).

Requirements and prerequisites

1. Licensing and keys

   • A valid Volume License Key for the KMS host (CSVLK) obtained from Microsoft Volume Licensing Service Center (VLSC).
   • Appropriate client product keys (GVLKs) are typically built into volume license media or available from Microsoft documentation.

2. Supported systems

   • KMS host can be installed on supported Windows Server or Windows client versions. For Windows Server 2003 SP1 clients and later, use a KMS host that supports the clients you need to activate.
   • Ensure the KMS host OS supports the CSVLK being installed (newer CSVLKs sometimes require newer host updates).

3. Network and DNS

   • KMS uses DNS Service (SRV) records for automatic discovery. The KMS host should register a _VLMCS._TCP service record in DNS.
   • Clients must be able to reach the KMS host over the network (default TCP port 1688). Firewalls and network segmentation should permit this traffic.

4. Administrative rights

   • You need local administrative rights on the KMS host to install the key and configure the service.

5. Updates and patches

   • Ensure required updates and service packs are applied to the KMS host. Some newer client or host key support requires specific Windows updates.

Planning your KMS deployment

• Choose the KMS host machine carefully: a stable server or VM with high availability and reliable network connectivity.
• Consider redundancy: while KMS itself doesn’t provide active-active clustering, you can deploy multiple KMS hosts across sites to improve reliability and lower latency. Each KMS host needs its own CSVLK and will publish SRV records; clients will use any discovered host.
• Ensure DNS is properly configured: automatic SRV registration is preferred. If DNS auto-registration isn’t available, clients can be directed to a specific host via manual configuration.
• Track activation counts and ensure you meet threshold numbers before expecting activation to succeed.

Step-by-step configuration

The details below assume you have a Windows machine prepared to act as the KMS host and a valid CSVLK.

1. Install the CSVLK on the KMS host

   • Open an elevated Command Prompt (Run as Administrator).
   • Use the slmgr.vbs tool to install the product key:

     
     slmgr.vbs /ipk <Your-KMS-Host-Key> 

     Replace with the CSVLK from VLSC.

   • Confirm the key installed:

     
     slmgr.vbs /dlv 

     This displays licensing information; check that the installed key and activation type show as KMS host.

2. Activate the KMS host with Microsoft

   • From the same elevated prompt, activate the host:

     
     slmgr.vbs /ato 

   • If the host cannot reach Microsoft activation servers directly (e.g., air-gapped environment), use telephone activation following Microsoft’s activation phone prompts.

3. Confirm KMS service is listening (port 1688)

   • Verify the KMS service is available and listening on TCP 1688:

     
     netstat -an | find "1688" 

   • Ensure local firewall rules allow incoming TCP 1688, and any network firewalls permit clients to reach the host.

4. Verify DNS SRV registration (automatic)

   • The KMS host should register a DNS SRV record: _VLMCS._TCP..
   • To check, query your DNS server for the SRV record (use nslookup or DNS management tools). Example with nslookup:

     
     nslookup -type=SRV _VLMCS._TCP 

   • If the SRV record is present, clients will auto-discover the KMS host.

5. Manually configure DNS SRV record (if needed)

   • If automatic registration fails or is undesirable, create a DNS SRV record manually:
     • Service: _VLMCS
     • Protocol: _TCP
     • Port number: 1688
     • Host offering this service: FQDN of your KMS host
   • Also ensure an A (or AAAA) record exists for the KMS host FQDN.

6. Configure Windows Firewall (if enabled)

   • On the KMS host allow inbound TCP 1688:
     • Using netsh:

       
       netsh advfirewall firewall add rule name="KMS" dir=in action=allow protocol=TCP localport=1688 

     • Or use Windows Firewall GUI to allow the port.

7. Configure clients (automatic)

   • Clients with Volume License GVLKs will automatically attempt to locate a KMS host via DNS and activate.
   • To force a client to attempt KMS activation immediately, run on the client as admin:

     
     slmgr.vbs /ato 

   • To see client activation status:

     
     slmgr.vbs /dli slmgr.vbs /dlv 

8. Manually point a client to a specific KMS host (if DNS isn’t used)

   • On the client, set the KMS host:

     
     slmgr.vbs /skms kms-host.example.com:1688 

   • Then force activation:

     
     slmgr.vbs /ato 

   • To clear a manual KMS host setting and return to DNS discovery:

     
     slmgr.vbs /ckms 

Activation thresholds and behavior

• KMS will only begin issuing activations after a minimum count of requests (the activation threshold). For Windows clients, the threshold is typically 25; for Windows Server operating systems, it’s typically 5. These thresholds ensure KMS hosts in small environments don’t inadvertently activate too few systems.
• KMS host maintains a sliding count of last-known clients; if the number of active clients falls below threshold the host will stop activating new systems until the threshold is met again.
• KMS activations are valid for 180 days by default; clients automatically attempt to renew (re-activate) every 7 days by default and will obtain refreshed 180-day activation when successful.

Troubleshooting common issues

1. Activation fails with “count not met” or insufficient number of requests

   • Verify you have at least the required number of unique client requests.
   • Check KMS host event logs for activation request details.

2. Clients cannot find KMS host

   • Verify the SRV record _VLMCS._TCP exists and points to the correct host.
   • Check network connectivity and firewall rules (TCP 1688).
   • Use slmgr.vbs /dlv on client to see detailed error codes.

3. KMS host not activated or key rejected

   • Confirm the CSVLK matches the product being activated and is correctly installed.
   • Make sure the KMS host can reach Microsoft activation servers for initial activation (or use telephone activation).
   • Check for required Windows updates that add support for newer CSVLKs.

4. DNS SRV registration issues

   • If the KMS host fails to register automatically, inspect the DNS client and DNS server settings. Manual SRV creation is a workaround.
   • On AD-integrated DNS, the KMS host will often register automatically when it starts; ensure dynamic updates are permitted.

5. Duplicate or multiple KMS hosts causing confusion

   • Multiple KMS hosts are supported but can complicate counting; check which hosts clients are using.
   • Ensure each host is using the appropriate CSVLK and is intended to serve clients in its location.

Best practices

• Deploy at least one KMS host per major network segment or site if latency or connectivity to a central host could be an issue.
• Monitor activation counts and event logs on KMS hosts to spot activation shortages or irregular activity.
• Secure the KMS host: limit administrative access, apply security updates, and restrict network access so only authorized clients can connect if possible.
• Keep an inventory of CSVLKs and which hosts they are installed on.
• If you have fewer systems than the KMS threshold, use Multiple Activation Keys (MAK) for direct activations or use hosted activation methods instead.

Example commands summary

(Commands to run as Administrator)

• Install KMS host key:

  
  slmgr.vbs /ipk <KMS-Host-CSVLK> 

• Activate KMS host:

  
  slmgr.vbs /ato 

• Check license/key info:

  
  slmgr.vbs /dlv 

• Open firewall for KMS:

  
  netsh advfirewall firewall add rule name="KMS" dir=in action=allow protocol=TCP localport=1688 

• Point client to KMS host:

  
  slmgr.vbs /skms kms-host.example.com:1688 slmgr.vbs /ato 

References and further reading

For the latest details on supported versions, thresholds, and KMS host updates, consult Microsoft’s Volume Activation resources and the Volume Licensing Service Center (VLSC). Also review Microsoft Knowledge Base articles specific to KMS and the product versions you intend to activate.