Implementing Volume Activation for Windows and Microsoft Office
Technical Case Study
Published: September 2010
Technical White Paper, 204 KB, Microsoft Word file
Products & Technologies
Product activation is a requirement for volume-licensed customers who are deploying Windows Vista, Windows 7, Windows Server 2008, and Microsoft Office 2010. A goal of Microsoft is to provide a tool that enables customers to meet product licensing requirements in a simple and automated manner.
Volume Activation (VA) 2.0 automates and manages the activation process for volume-licensed editions of the Windows Vista®, Windows® 7, Windows Server® 2008, and Windows Server 2008 R2 operating systems, and Microsoft® Office 2010. By using VA, Microsoft found a model for performing activations in most network environments.
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, Windows 7, and Windows Server 2008 operating systems, including those obtained through a volume-licensing program. This requirement applies to Windows running on both physical machines and virtual machines.
VA is a set of tools that help customers automate the process of activation on computers running volume editions of Windows Vista, Windows 7, and Windows Server 2008. It is available as an activation option only if the software is licensed through a Microsoft volume-licensing program. Customers who acquire Windows Vista, Windows 7, and Windows Server 2008 products through a retail store or an original equipment manufacturer (OEM) activate them by using other methods.
This case study describes how Microsoft Information Technology (Microsoft IT) used VA 2.0 to internally deploy Windows Vista, Windows 7, Windows Server 2008, and Microsoft Office 2010. 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 managed the integration of VA 2.0 into its own production network environment.
Before Windows Vista and Windows Server 2008, product activation for Windows was required only for Microsoft software purchased from retail stores and 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. It is estimated that more than 80 percent of Windows XP piracy was due to the leaking of product keys issued to volume customers.
Users whom Microsoft IT supports include many early adopters of new operating systems. This support gave Microsoft IT the opportunity to refine product activation tools during the deployment of the Windows client and Windows Server operating systems. Microsoft IT's purpose when implementing VA was to work with the product development team for VA to not only test a large-scale implementation, but also enhance the activation solution that would be made available customers.
- Microsoft IT worked with the product development team to accomplish the following goals during its implementation of VA:
- Activate Windows Vista, Windows 7, Windows Server 2008, Windows Server 2008 R2, and Microsoft Office 2010 in a way that is transparent to users.
- Optimize the configuration of VA 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 System Center Operations Manager 2007 R2.
- Stress-test KMS host servers and improve performance while reducing the memory footprint.
- Measure how activation affects network traffic.
- Validate the appropriate number of KMS host servers for the Microsoft environment.
Two integrated services provide Windows Vista, Windows 7, Windows Server 2008, Windows Server 2008 R2, and Microsoft Office 2010 product activation: KMS and Multiple Activation Key (MAK).
KMS is an activation service that is hosted locally in the customer environment. This method of license activation is generally the most effective because it activates all the software on a system automatically, rather than having each individual computer connect to a hosted service.
A KMS key is installed on a KMS host server (or servers) set up within an organization. Systems then connect to the KMS host, which activates them transparently. After the organization sets up its KMS activation, both physical and virtual machines will—by default—attempt to activate instances of Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2 by connecting to the KMS host. This means that no individual computers need to connect to the Microsoft-hosted activation service for either initial activation or renewal of a current activation.
MAK is an alternative to KMS for activating software through the Microsoft-hosted activation service. A MAK that Microsoft provides will have a predetermined number of allowed activations that match the number of eligible systems in the organization.
Microsoft IT chose to use KMS as the primary activation model for two main reasons:
- KMS was created to be the activation method of choice for computers connected to an organization's core network.
- Microsoft IT can use MAK as a backup activation method.
Microsoft IT implemented VA in five phases. The focus of the implementation was to use and enhance the automated features of VA.
Phase 1: Lab Testing
Phase 1 of the VA implementation was designed to test the installation of KMS hosts and to test basic functionality of the KMS service. 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.
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 machines in a network environment, called the activation threshold. An organization must have five or more physical machines to activate Windows Server 2008 or Windows Server 2008 R2, and 25 or more physical machines to activate clients running Windows Vista or Windows 7 by using KMS. A KMS host counts the number of physical machines that are 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 machines exist on a network, individual KMS hosts may stop activating clients because the activation threshold is not met. Microsoft IT found that networks that have fewer than 100 KMS clients can avoid this issue 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 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 Transmission Control Protocol (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.
The client computers selected for Phase 2 included members of a deployment test domain and 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. These test 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 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. Microsoft IT installed two KMS hosts in the root forest domain of the core network.
One of Microsoft IT's goals was to measure the impact of adding the KMS service to a domain controller. Microsoft IT collected metrics from the domain controller acting as a KMS host and from other domain controllers in the same domain. Microsoft IT then 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. There was 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: Initial Windows 7 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. Users upgraded an additional 23,000 systems to a volume-licensed version of Windows 7, resulting in a population of 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 configured and dedicated solely to IP version 6 (IPv6) KMS clients and provided 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.
After evaluating performance on the KMS servers, Microsoft IT found that it required only two servers to support the ongoing load for volume activation. It kept two of the four KMS servers as a test environment that could be switched back into production in case of emergency.
Note: KMS is automatically included with Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2, 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 at http://go.microsoft.com/fwlink/?LinkID=82964 in several languages. The 64-bit version is available at http://go.microsoft.com/fwlink/?LinkId=83041.
Phase 5: Windows 7 Deployment
The current population of Windows 7 clients that the VA infrastructure has activated is 150,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.
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. By reviewing 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.
DNS Server Configuration
When initially implementing VA, 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 2003, Windows Server 2008, Windows Server 2008 R2, or even Windows Vista or Windows 7, although KMS hosts that are based on Windows client operating systems can activate only systems that are based on Windows client operating systems. Additionally, a KMS host can be a physical machine 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
|Component||Microsoft IT configuration|
|Processor||Two AMD64, 2,205 megahertz (MHz) each|
|Memory||2,046 megabytes (MB)|
|Network||1-gigabyte (GB) Ethernet|
|Disk||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.
Activation of Microsoft Office 2010
Support for the deployment of Microsoft Office 2010 was simply a matter of adding the appropriate key to the Windows activation server. No additional resources on the Windows activation servers were needed to manage the 100,000 instances of Microsoft Office 2010 that have been loaded to date as part of the beta testing program.
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 machines required for KMS activation thresholds. Best practices that Microsoft IT determined during the implementation include the following:
- KMS suits most network environments. An organization should use KMS whenever practical.
- Network environments that have the latest DNS servers have fewer 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.
Additional best practices pertain to monitoring and load balancing.
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 System Center Operations Manager 2007 R2, the administrator can use the KMS Management Pack. 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 balanced the load between a current KMS host and a new KMS host. First, an administrator can restart 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.
Volume activation is required for all editions of Windows Vista, Windows 7, Windows Server 2008, Windows Server 2008 R2, and Microsoft Office 2010. VA enables volume-licensing customers to automate the activation process so that there is little or no impact on end users. Although VA provides volume-licensing customers with two models for activating Windows Vista, Windows 7, Windows Server 2008, Windows Server 2008 R2, and Microsoft Office 2010, Microsoft IT found that the KMS model met most activation needs. The low resource usage and low network traffic overhead make KMS useful in a variety of network environments.
Microsoft IT also discovered that the server infrastructure that was built for Windows Vista and Windows Server 2008 volume-license activation was robust and performed well enough to also include all volume-license activations of Windows 7, Windows Server 2008 R2, and Microsoft Office 2010.
For More Information
This case study is an example of how VA was implemented in a large organization. Numerous resources and tools are available to assist organizations in planning and implementing VA. For more information about terminology or tasks discussed in this case study, refer to the following documentation:
- To download the VA 2.0 core documentation set, go to http://go.microsoft.com/fwlink/?LinkID=75674.
- For information about product activation and volume license keys, go to http://go.microsoft.com/fwlink/?LinkID=110471.
- For a list of Microsoft activation call centers and contact information, go to http://go.microsoft.com/fwlink/?LinkID=107418.
- To download the KMS Management Pack for System Center Operations Manager 2007 R2, go to the Microsoft System Center Management Pack Catalog at http://pinpoint.microsoft.com/en-US/systemcenter/managementpackcatalog.
For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada Order Centre at (800) 933-4750. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information via the World Wide Web, go to:
© 2010 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.