Implementing Volume Activation 2.0 for Windows Vista and Windows Server 2008


Product activation is a new requirement for volume-licensed customers of Microsoft. Microsoft wanted to provide these customers with a tool that would enable them meet this requirement in a simple and automated manner.


Microsoft IT worked in concert with a product development team to test and enhance volume activation tools. The result of this work is Volume Activation 2.0.


  • Automated volume activations
  • Low overhead and resource usage
  • Ability of one activation model to meet most activation needs

Products & Technologies

  • Volume Activation 2.0
  • Windows Vista
  • Windows Server 2008
  • Windows Server 2003
  • Microsoft Operations Manager 2005
  • DNS Server service

Published: May 2008

Volume Activation version 2.0 (VA 2.0) automates and manages the activation process for volume-licensed editions of the Windows Vista® and Windows Server® 2008 operating systems. Using Volume Activation 2.0, Microsoft found a model for performing activations in most network environments.

Product activation is the process of validating software with the manufacturer. Previously, product activation for Windows® was required only for Microsoft software purchased from retail stores and original equipment manufacturers (OEMs). Software licenses purchased through Microsoft volume licensing programs did not require activation. However, the nature and use of product keys for volume licenses made controlling their use difficult. Because of this, product keys for volume-licensed editions of Windows XP and Windows Server 2003 became the primary source of pirated software. In fact, more than 80 percent of Windows XP piracy is due to the leaking of product keys issued to volume customers.

Many consumers who acquire a counterfeit copy of Microsoft software are unwitting victims of a crime, often unknowingly using product keys stolen from legitimate volume customers. Although the financial impact of counterfeit software is serious to software manufacturers and vendors, the impact goes beyond revenue loss to those organizations. Counterfeit software is increasingly becoming a vehicle for the distribution of viruses and malicious software that can target unsuspecting users, potentially exposing them to corruption or loss of personal or business data and identity theft.

To counteract this threat, the Microsoft activation policy requires customers to activate all editions of Windows Vista and Windows Server 2008 operating systems, including those obtained through a volume-licensing program. This requirement applies to Windows running on both physical computers and virtual machines. VA 2.0 is a new set of tools that help customers automate the process of activation on computers running volume editions of Windows Vista and Windows Server 2008. Volume activation is available as an activation option only if the software is licensed through a Microsoft Volume Licensing program. Customers who acquire Windows Vista and Windows Server 2008 products through a retail store or an OEM activate them by using other methods.

This case study describes how Microsoft Information Technology (Microsoft IT) implemented VA 2.0 from the early editions of Windows Vista to the market release of Windows Server 2008, and the lessons learned from the implementation. It includes explanations of issues encountered and the best practices that require the lowest administrative overhead. This paper is for chief information officers, IT directors, solution architects, and technical decision makers who want to learn how Microsoft integrated VA 2.0 into its own network.


Users that Microsoft IT supports include many early adopters of new operating systems. This support provided Microsoft IT with the opportunity to test volume activation tools when Windows Vista was in the beta , before the development cycle of the volume activation tools were complete. Microsoft IT's purpose when implementing volume activation was to work with the product development team for VA 2.0 to not only test a large-scale implementation, but also refine and enhance the activation solution that would go out to customers.

Implementation Goals

Microsoft IT worked with the product development team to accomplish the following goals during its implementation of volume activation:

  • Activate Windows Vista and Windows Server 2008 operating systems in a way that is transparent to users
  • Revise the configuration of VA 2.0 as needed to reduce administrative costs and minimize total cost of ownership (TCO)
  • Increase the usefulness of the Microsoft Windows Key Management Service (KMS) Management Pack for Microsoft Operations Manager 2005
  • Stress-test KMS host servers
  • Find the best methods to control automatic behavior of KMS clients
  • Measure how activations affect network traffic
  • Find the optimal number of KMS host servers

Activation Method

VA 2.0 provides two different models for implementing volume activations: KMS and Multiple Activation Key (MAK). KMS activates operating systems on the local network, so that individual computers never need to connect to Microsoft for activation. To do this, KMS uses a client/server model. KMS clients connect to a KMS server, called the KMS host, to request activation or to renew a current activation. MAK is used for a one-time activation with Microsoft’s hosted activation services. MAK either requires a direct activation with Microsoft or allows one computer to make a centralized activation request on behalf of multiple computers by using only one connection to Microsoft.

Microsoft IT chose to use KMS as the primary activation model for two main reasons. First, KMS was created to be the activation method of choice for computers connected to an organization's core network. Microsoft IT planned to activate computers that were early adopters of Windows Vista, all of which were connected to the organization's core network. Second, Microsoft IT designed this implementation to give the product team for VA 2.0 real-world input on how KMS handled a large-scale deployment. Microsoft IT could work closely with the product development team to identify issues as well as simplify and improve the KMS activation process. Microsoft IT could use MAK as a backup activation method for systems that had KMS activation failures.


Microsoft IT implemented VA 2.0 in five phases before turning it over to operations teams. The focus of this implementation was to use and enhance the automated features of VA 2.0.

Phase 1: Lab Testing

Phase 1 of the VA 2.0 implementation was designed to test the installation of KMS hosts and to test basic functionality of the KMS service only. This phase occurred in a lab environment that is in a separate forest from the rest of the production network. Microsoft IT's plan for Phase 1 was to install two KMS hosts: one on a stand-alone computer and one on a domain controller. Afterward, Microsoft IT would monitor the activations of approximately 100 KMS clients, also located in the test lab environment. Phase 1 lasted three weeks. During that time, Microsoft IT activated all clients with KMS; no MAK activations were needed.

DNS Configuration Requirements

The default behavior of a KMS client is to query Domain Name System (DNS) for the name of a KMS host. This name is contained in a service (SRV) record that publishes the KMS service. The version of KMS used for Phase 1 required Microsoft IT to manually create an SRV record on the DNS server. After the creation of this record, the KMS clients found the KMS hosts and activated them without additional administrative actions.

Activation Thresholds

By testing a small number of KMS clients, Microsoft IT found that it is possible to have too many KMS hosts. This is due to KMS activation thresholds. KMS is designed for medium to large network environments. For this reason, KMS requires a minimum number of physical computers in a network environment, called the activation threshold. An organization must have five or more physical computers to activate Windows Server 2008 and 25 or more physical computers to activate clients running Windows Vista by using KMS. A KMS host counts the number of physical computers requesting activation on the network, and KMS clients are activated only after this threshold is met.

Each KMS host keeps a separate activation threshold count. If not enough physical computers exist on a network, individual KMS hosts may stop activating clients because the activation threshold is not met. Microsoft IT found that networks with fewer than 100 KMS clients can avoid this by having only one KMS host.


Initially, performance metrics indicated that the activations were placing stress on the processor of the KMS hosts. CPU usage kept spiking at 100 percent, even though the number of KMS clients was small. Upon investigation, Microsoft IT found that the KMS clients were renewing their activations too often. It increased the activation renewal interval from once every minute to once every seven days. As the deployment progressed through subsequent phases, Microsoft IT found that reducing this interval was a simple way to stress test KMS hosts.

Network Traffic

Network traffic tests revealed that overhead for the KMS service is minimal. Fewer than 250 bytes are sent in each direction for a complete KMS activation exchange, plus TCP session setup and teardown. Additional network traffic occurs when a KMS client queries DNS for a KMS host, but this usually happens only once per KMS client. After a KMS client finds a KMS host, it sends all future requests for activation renewal to the same KMS host. A KMS client seeks a new KMS host only if the current KMS host does not respond. Additionally, no network traffic occurs between KMS hosts. Each KMS host maintains a separate list of KMS clients, with no replication or sharing of information with other KMS hosts.

Phase 2: Pilot Deployment

The plan for Phase 2 was a limited deployment of KMS clients from the production network with a setup that minimized the impact on the network. Microsoft IT selected a limited number of KMS clients from the production network. To lessen the possible impact of adding the KMS service to the network, Microsoft IT installed the KMS hosts for Phase 2 into a forest that is used only to test deployments and that is not part of the production network.

The operating systems used for VA 2.0 included pre-beta versions of Windows Vista and of Windows Server 2008. The client computers selected for Phase 2 included members of a deployment test domain as well as members of a small domain connected to the core network. Additionally, Microsoft IT selected a limited number of clients from the main domain in the core network. For computers that belonged to the main domain, Microsoft IT selected groups of users who were in close physical proximity to each other. The reason was to test how network traffic was affected on the physical subnet. Microsoft IT asked these users to upgrade their systems to an unreleased volume-licensed version of Windows Vista or Windows Server 2008. These three environments totaled about 3,000 systems selected for activation in Phase 2.

DNS Server Configuration

Because Microsoft IT's DNS servers supported dynamic DNS, Microsoft IT requested and was granted a change to KMS. The change was to have a KMS host to create and update the DNS records needed for KMS so that administrators did not need to create these records manually. With this change, the KMS host creates the DNS SRV record automatically when the KMS service is enabled. Each time the service starts and once daily, the KMS replaces its SRV record. This new record reflects any changes.

For Phase 2 and subsequent phases, Microsoft IT planned KMS clients from multiple DNS domains, but planned for the KMS hosts to belong to a single DNS domain. By default, KMS hosts automatically publish the KMS service by creating an SRV record in their own default DNS domain. Additionally, KMS clients only query their default DNS domain for the location of a KMS host. To avoid the need to create DNS records manually, Microsoft IT requested and received a new registry key for KMS hosts. The DNSDomainPublishList registry key enables administrators to list all DNS domains to which the KMS host should add an SRV record for the KMS service. This saved Microsoft IT the time and effort needed to create and manage KMS host SRV records across multiple DNS domains.

During Phase 2, the DNS server in the lab environment allowed the KMS host to self-publish, but in the production environments, as in many organizations, the ability to create and update DNS records is controlled. For the KMS host to publish the KMS service, it needs the rights to create and update SRV, A, and AAAA resource records in all DNS domains that contain KMS clients. Microsoft IT assigned the needed DNS server credentials to KMS hosts by creating a security group in the Active Directory® Domain Services AD DS and adding all KMS hosts to that group. Microsoft IT gave this security group Full Control permission over the _VLMCS._TCP record for each DNS domain that contains KMS clients.

Phase 3: Installation of KMS Hosts on the Core Network

The main goal in Phase 3 was to install KMS hosts on the core network. The KMS hosts that Microsoft IT used in Phase 2 were not used in Phase 3. Instead, Microsoft IT installed two KMS hosts in the root forest domain of the core network. It installed one KMS host on a production domain controller and one on a stand-alone server. Because KMS hosts do not share information, the activation process started over for all KMS clients when the new KMS hosts were brought online. So, Phase 3 included the 3,000 KMS clients from Phase 2, plus an additional 4,000 clients, for a total of 7,000 KMS clients.

One of Microsoft IT's goals was to measure the impact of adding the KMS service to a domain controller. It collected metrics from the domain controller acting as a KMS host and from other domain controllers in the same domain. When Microsoft IT compared the metrics of the KMS host that was installed on a domain controller with the metrics of other domain controllers in the same domain, it found no measurable performance decrease on the domain controller that was also a KMS host. Microsoft IT concluded that adding the KMS service to a domain controller did not hinder its performance.

Phase 4: Windows Vista Beta 2 Deployment

With no measurable stress on the servers or traffic in the core network, Microsoft IT's plan for Phase 4 was a large increase in KMS clients. Phase 4 coincided with the release of Windows Vista Beta 2, and the widespread adoption of the Windows Vista operating system in the core network. Users upgraded 23,000 more systems to a volume-licensed version of Windows Vista or Windows Server 2008, resulting in a total of approximately 30,000 KMS clients for Phase 4. Some of these KMS clients were laptop computers that connected through an internal wireless network. Users did not report any performance issues from these clients.

To accommodate the large increase in KMS clients, Microsoft IT installed two additional KMS hosts on domain controllers in the core network's root forest domain, bringing the total number of KMS hosts to four. One of these KMS hosts was a server running Windows Server 2003.This server supported 25 percent of the KMS clients with no issues. Additionally, one of these KMS hosts was dedicated solely to IP version 6 (IPv6) KMS clients and proviced no support for IP version 4 (IPv4). Microsoft IT found no difference in the operation or performance of this KMS host, and it found no problems with the activation of KMS clients that were running IPv6.

Note:* *KMS is automatically included with Windows Server 2008 and Windows Vista, but not with Windows Server 2003. Organizations that want to host KMS on Windows Server 2003 must download and install KMS for Windows Server 2003, which is available for download at in several languages. The 64-bit version is available at

Phase 5: Windows Vista RC Deployment

Phase 5 coincided with the release of Windows Vista Release Candidate (RC). An additional 60,000 more KMS clients were added, bringing the total to approximately 90,000. Microsoft IT added another KMS host to the forest root domain of the core network, increasing the number of KMS hosts to four domain controllers and one stand-alone server.

Though all of the KMS hosts were in the root forest domain of the core network, some of the clients added during Phase 5 had computer accounts in a different forest that did not have a trust with the forest of the core network. Initially, activation of these clients failed. Upon investigation, Microsoft IT found that IP security (IPsec) settings caused this problem. After Microsoft IT gave permissions for IPSec to allow connectivity from these domains to the KMS hosts, the activations were successful.

An additional separate and small deployment also occurred during Phase 5. Some KMS clients were at a remote location that connected to the core network through a virtual private network (VPN). Microsoft IT gave these clients a separate KMS host. Looking at the captured performance metrics, Microsoft IT found that KMS does not require a KMS host to be connected to KMS clients through a high-bandwidth connection. Microsoft IT found the latency to be in terms of seconds, whereas the requirements of activation are in terms of weeks. Even if a connection to a KMS host timed out and was retried later, the user did not notice.

Current Configuration

After Phase 5 was complete, the administration of VA 2.0 transitioned from deployment and testing to operations and maintenance. VA 2.0 is still in use for all volume-licensed editions of Windows Vista and Windows Server 2008. The configuration of some of the servers that support VA 2.0 on the core network has changed.

DNS Server Configuration

When initially implementing VA 2.0, Microsoft IT used the DNS Server service on Windows Server 2003. Later, Microsoft IT upgraded these servers to their current configuration of the DNS Server service on Windows Server 2008. Both versions of DNS servers support SRV records, in accordance with Request for Comments (RFC) 2782, and dynamic updates, in accordance with RFC 2136. Any DNS server that supports these RFCs, in addition to Berkeley Internet Domain Name (BIND) versions 8.x and 9.x, can allow the KMS host to publish the KMS service records automatically.

Current KMS Host Configuration

One of Microsoft IT's main goals was to stress test KMS hosts to determine how many KMS clients a KMS host can support and whether KMS hosts can be co-hosted with other services. A KMS host can run on a computer running Windows Server 2008, Windows Server 2003, or even Windows Vista, although Windows Vista–based KMS hosts can activate only Windows Vista–based systems. Additionally, a KMS host can be a physical computer or virtual system.

Microsoft IT continues to test new configurations for KMS hosts. Currently, two KMS hosts support all KMS clients in the network. These servers are not domain controllers, but instead are considered licensing servers. They support not only KMS clients, but also licenses for Terminal Services. Table 1 lists the specifications of these servers.

Table 1. Hardware Specifications for KMS Hosts


Microsoft IT configuration


Two AMD64, 2,205 megahertz (MHz) each


2,046 megabytes (MB)


1-gigabyte (GB) Ethernet


One physical 70-GB disk

KMS is compute-cycle intensive. CPU usage can momentarily reach 100 percent on a single-processor computer when processing multiple activation requests. However, KMS client activation requests are often staggered. When attempting to activate itself during the initial grace period, a KMS client make an activation request every two hours, by default, and a renewal request once every seven days after activation.

Best Practices

Microsoft IT found that the KMS model of activation worked for most network environments with a negligible impact on the network and on the computer that hosts the KMS service. It did not find a need for MAK activation except for disconnected networks, such as high-security networks that do not meet the number of physical computers required for KMS activation thresholds. Best practices determined by Microsoft IT during the case study are as follows:

  • KMS suits most network environments. An organization should use KMS whenever practical.
  • Network environments with the latest DNS servers have few setup steps for KMS activations.
  • Servers that perform other functions can add KMS hosting duties with negligible effects on server performance.
  • Small network environments should have only one KMS host.
  • After it is configured, KMS requires few administrative resources.

KMS Client Activation Monitoring

When the KMS host or hosts first go online, administrators should monitor the success of client activations in addition to the number of activations that each KMS host performs. A KMS client records activation requests, renewals, and responses in the KMS client’s local application log. The KMS host logs separate entries for each request that it receives from a KMS client. These entries are saved to the Key Management Service log in the Applications and Services Logs folder.

An administrator can archive and review KMS event logs manually. Or, if the organization uses Microsoft Operations Manager 2005, the administrator can use the Microsoft Windows Key Management Service (KMS) MOM 2005 Management Pack. The KMS Management Pack contains detailed activation reports for computers running Windows Vista and Windows Server 2008. The KMS Activity Summary provides the number of new KMS activations and can provide these numbers for each KMS host.

After the initial activations are complete, an administrator can set alerts in the KMS Management Pack that provide notifications when a computer's grace periods or current activation are expiring. An administrator can also use the Licensing Status Summary report to see the number of days left for KMS clients to renew their activations.

Load Balancing KMS Hosts

In a network environment that has two KMS hosts, if both KMS hosts go online simultaneously, the DNS server alternates KMS clients between the two KMS hosts, and the KMS clients are split between the KMS hosts. However, if another KMS host goes online sometime after the first KMS host, the new KMS host will not have any KMS clients. This is due to default KMS client behavior.

After a KMS client is successfully activated, it sends all future requests for activation renewal to the original KMS host that activated it. As long as the original KMS host responds to the KMS client, the client will not seek another KMS host. In this case, Microsoft IT found two ways to balance the load between a current KMS host and a new KMS host. First, an administrator can reboot the original KMS host and bring both hosts back online simultaneously. This clears the cache of activations on the original host and starts the activation threshold count again.

If a restart is not an option, an administrator can block the port that the KMS service uses—TCP port 1688—on the original KMS host. Client renewal attempts will go unanswered, causing them to seek a new KMS host from DNS. The administrator needs to monitor the number of clients that have switched to the new KMS host to determine when to unblock the port. The number of days that the port is blocked must be less than the client renewal interval. If the administrator blocks the port for the entire client renewal interval (by default, seven days), all of the KMS clients will have switched to the new KMS host.


Product activation is required for all editions of Windows Vista and Windows Server 2008. VA 2.0 enables volume-licensing customers to automate the activation process so that there is little or no impact on end users. Although VA 2.0 provides volume-licensing customers with two models for activating Windows Vista and Windows Server 2008, Microsoft IT found that the KMS model met most activation needs. The low resource usage and low network traffic overhead makes KMS useful in a variety of network environments.

The goal of Microsoft IT's implementation of volume activation was not just to test how the activations worked on a large scale, but also to improve the customer experience of the product. The result is improvements made to VA 2.0 that simplify and automate the process of volume activations.

For More Information

This case study is an example of how VA 2.0 was implemented in a large organization. Numerous resources and tools are available to assist organizations in planning and implementing VA 2.0. For more information about terminology used or procedures that perform tasks discussed in this case study, refer to the following documentation:

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information via the World Wide Web, go to:


© 2008 Microsoft Corporation. All rights reserved.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft, Active Directory, Windows, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.