Implementing KMS Activation

Article
02/19/2008

KMS activation relies primarily on the proper setup and operation of one or more computers with the KMS enabled. KMS hosts, running either Windows Vista or Windows Server “Longhorn,” must be enabled by installing the customer-specific volume license key. Properly configured Windows Vista volume clients, by default, seek a KMS host by using DNS queries unless they are preconfigured with the address of one or more KMS hosts. Systems activated by a KMS host renew their activation keys at seven-day intervals under normal operation, operating up to 180 days (or 210 days when the 30 day grace period is taken into account) without renewal when they are unable to contact a KMS host. This approach allows traveling systems to remain in full operation for up to seven months without requiring contact with a KMS host.

Enabling a KMS host

All the tools required for KMS host operation are already included in Windows Vista and Windows Server “Longhorn.” Installation of an enterprise volume license key may enable the KMS host to activate its service with Microsoft one time, and then start servicing activation requests inside the customer environment. By default, the KMS host attempts to register its SRV resource information with the primary DNS of the system’s primary DNS domain.

To activate KMS on a computer that will run the KMS

Install an enterprise volume license key by running the following command in an elevated Command Prompt window, where Key is the enterprise volume license key:
```
cscript C:\Windows\System32\Slmgr.vbs -ipk Key
```
Note The key provided for KMS host activation can be used on only two systems up to 10 times for each system. If team members are using this key in a BDD test lab, they should be sure to request an extension to support activation of the production KMS hosts.
Activate the KMS host using the Internet by running this script:
```
cscript C:\Windows\System32\Slmgr.vbs -ato
```
To activate the KMS using a telephone, start the Windows Activation Wizard by running this executable:
```
Slui.exe 4
```
Ensure that the KMS port (default is 1688/TCP) is allowed through all firewalls between the KMS host and KMS client computers.

Important Do not provide unsecured access to KMS hosts over an uncontrolled network such as the Internet. Doing so may lead to exposure to penetration attempts and unauthorized activation by computers outside the organization.
Make any configuration changes required for the environment. See “Appendix C: KMS Activation Configuration” for details on KMS configuration settings.

By using the Slmgr.vbs script and editing the KMS host’s registry, team members can change the configuration of KMS. Configure KMS to register SRV resource records on multiple DNS domains, not to register with DNS at all, to use nonstandard ports, and even to control client renewal intervals. For these changes to take effect, restart the Software Licensing Service. Details on these settings and how to configure them are included in “Appendix C: KMS Activation Configuration.”

Required Resources

KMS hosts require no additional resources beyond those required by volume-licensed editions of Windows Vista or Windows Server “Longhorn.” For co-hosted scenarios, configure the KMS to run as a low priority, sparing processor cycles for other applications. KMS can be co-hosted with other services, such as Active Directory domain controller roles or file and print services, and is supported in VM configurations.

Note Computers running Vista RTM require an RTM KMS to activate; beta versions of KMS do not support activation of Vista RTM clients.

KMS Infrastructure

KMS uses the Software Licensing Service built into Windows Vista and Windows Server “Longhorn.” Activating with an enterprise volume license key converts the Software Licensing Service to the KMS host role, allowing KMS clients to use the KMS host in their activation process.

Figure 3 shows an enterprise network supporting clients in three branch offices. Site A, which has more than 25 client computers (but no secure TCP connectivity to Headquarters), can support its own KMS. Site B must use MAK activation, because KMS does not support sites with fewer than 25 client computers, and the site is not connected by a private WAN. Site C can use KMS, because it is connected to Headquarters using a private WAN.

Figure 3. Enterprise activation infrastructure example

Clients making KMS activation requests must be able to communicate with the KMS host. For this reason, at least one KMS host should be installed for any network site separated from other sites by a public network.

Note KMS requires activation requests from 25 or more client computers before it begins activating computers. For this reason, KMS is not effective for small, remote offices (fewer than 25 client computers). These offices can activate across a WAN or can be activated using MAKs if KMS performance across the WAN is inadequate.

KMS requests and responses use about 250 bytes of network bandwidth each. This load should not adversely affect the resources of most local area networks (LANs) and can even support KMS activation across uncongested WANs.

Warning Team members are responsible for both the use of keys assigned to them and the activation of products using their KMS hosts. Do not disclose keys to third parties, and do not provide unsecured access to KMS hosts over an uncontrolled network such as the Internet.

DNS Registration (KMS Autodiscovery)

For KMS autodiscovery to work properly, DNS servers must support both Dynamic DNS registrations and SRV resource records. Versions of Microsoft DNS included with Microsoft Windows 2000 Server, Windows Server 2003, and Windows Server “Longhorn” and BIND DNS versions 8 through 9.4.0 support this functionality.

KMS automatically attempts to register SRV resource records with the DNS server for the system’s primary DNS suffix. KMS can contact additional DNS servers as well. A registry entry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL\DnsDomainPublishList) can be created. This key contains a list of DNS domains to which KMS will attempt to register resource records. The system running KMS requires permission to register resource records in each domain. Each DNS server administrator might need to modify DNS permissions to make this possible.

Note If Dynamic DNS registration does not work for any reason, the DNS server administrator must enter SRV records manually. The records should be named _VLMCS._TCP.DNSDomainName, where DNSDomainName is the name of a DNS domain. Time to Live (TTL) for these records should be 60 minutes. The KMS host address and port (default 1688/TCP) should also be included in each record. KMS clients do not use the priority or weight fields when selecting a KMS host. Instead, they randomly select a KMS host from the complete list of KMS hosts that DNS returns for their domain.

Installing KMS Client Computers

Team members must do very little to client systems to enable KMS activation. Systems installed using volume-licensed media automatically seek out KMS hosts by default. If a KMS host is found, no further action is necessary. A client first checks the DNS domain specified by its primary DNS suffix for a KMS SRV record. If an SRV record is not found, domain-joined computers check the DNS domain corresponding to their Active Directory DNS domain. Workgroup client computers check the DNS domain that the Dynamic Host Configuration Protocol (DHCP) specifies (option 15 per Request for Comments [RFC] 2132).

Computer Imaging

Systems being prepared for imaging can be prepared normally. The reference computer should be imaged before activation. If the system was activated during preparation, use the System Preparation Tool (Sysprep) to reset the activation timers.

To reset a volume-licensed system to allow KMS activation

Execute Slmgr.vbs with the -ipk option, installing the generic product setup key as shown in the following example, where <product key> is the generic setup key for that version of Windows Vista:
```
cscript C:\Windows\System32\Slmgr.vbs -ipk <product key>
```

Note The generic setup key can be found in sources\pid.txt on the installation media.

Run Sysprep /generalize to reset activation timers and prepare the image for capture.

Note See the Computer Imaging System Feature Team Guide for details regarding system image preparation.

KMS Client Activation

While KMS clients retry activation every two hours by default, team members can force KMS client activation manually for systems that will be disconnected for travel.

To manually activate a KMS client system

Click Start, right-click My Computer, and then click Properties.
In the System Properties property sheet, click Click here to activate Windows now to launch Windows Activation.
If necessary, click Continue to enable Windows Activation.

Windows Vista then contacts a KMS host and attempts to activate.

Enabling Standard User Activation

By default, activation requires administrative privileges. However, in scenarios where users do not have local administrator access and autoactivation cannot be completed during the initial 30-day grace period, customers may elect to make these operations available to standard users. A registry entry, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL\UserOperations (REG_DWORD), can be set to 1 to enable standard users to install product keys, activate, and rearm computers. With this registry setting enabled, all product key installation, activation, and rearm requests must be done using the built-in Slmgr.vbs script.

KMS Integration with the Deployment Workbench

The Deployment Workbench runs the Windows Deployment Wizard to configure KMS client settings during desktop computer image preparation. This option does not insert an activation key. Instead, the KMS client seeks a computer running KMS after computer imaging. For more information on automating volume activation using BDD 2007, see “Appendix E: BDD Automation.”

KMS Reporting

Teams can collect and report on KMS statistics in several ways. Team members can use the Slmgr.vbs script to display a limited amount of information about KMS, such as the status of the current volume license. More detailed information is available in the KMS application event logs, which can be collected and tabulated by a MOM Pack designed for MOM 2005. Likewise, outside vendor tools that can monitor or tabulate event logs can be used to create KMS-related reports and alerts.

KMS Event Log Entries

The licensing service logs events to the Application Event Log. The KMS host logs 12290 events to a separate log. Both the KMS client and the KMS host log each activation request. The KMS response to these events can be tabulated to approximate the number of activated systems supported by the KMS host. Totaling the results for all clients running KMS yields a global activation picture for the organization. Problems are also recorded in the event logs and can be traced by date and time to help discover the cause of activation issues. An explanation of KMS event log entries appears in “Appendix D: Activation-Related Event Log Entries.”

MOM Pack for KMS Activation

For organizations that have standardized on MOM, a MOM pack is available to allow event monitoring and activation reporting. This pack alerts administrators to problems and provides input into SAM systems to let organizations track activated software.

The MOM pack is available on Microsoft Connect at https://go.microsoft.com/fwlink/?LinkId=76333.

Share via