Situation
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.
Solution
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.
Benefits
- 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.
Situation
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.
Solution
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.
Performance
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 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 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
|
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.
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.
Conclusion
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:
http://www.microsoft.com
http://www.microsoft.com/technet/itshowcase
© 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.