for

 

Windows Vista® and Windows Server® 2008

Microsoft Corporation

Published: March, 2008

Abstract

Volume activation is designed to automate and manage the activation process for volume licensing customers. This document is intended for IT implementers whose organization is a Microsoft Volume Licensing customer and who need to plan a deployment of Volume Activation 2.0.

Table of Contents

Introduction
Steps to Planning Volume Activations
Review Available Activation Models
    Key Management Service (KMS)
        Minimum Computer Requirements
        How KMS Works
        Planning a KMS Deployment
    Multiple Activation Key (MAK)
        Volume Activation Management Tool (VAMT)
        MAK Architecture
Evaluate Client Connectivity
    Activation Scenarios
        Core Network
        Isolated Networks
        Individual Disconnected Computers
        Test/Development Labs
Map Systems to an Activation Method
Determine Product Key Needs
Determine Monitoring and Reporting Needs
    Windows Management Instrumentation (WMI)
    System Management Server (SMS) and System Center Configuration Manager (SCCM)
    Event Logs
    KMS Management Pack
    Volume Activation Management Tool (VAMT)
Appendix 1:  Information Sent to Microsoft During Activation
Appendix 2:  License Conditions
    Activated
    Grace
    Genuine
    Notification
    Unlicensed/Reduced Functionality Mode (RFM)

Introduction

Volume Activation 2.0 (VA 2.0) is a configurable solution that helps IT professionals automate and manage the product activation process of Windows Vista® and Windows Server® 2008 systems licensed under a Microsoft Volume Licensing program. This guide provides information to assist you in planning a deployment of VA 2.0. It contains steps for planning volume activations and VA 2.0 scenarios.

For an introduction to VA 2.0, see the Volume Activation 2.0 Overview Guide. All VA 2.0 guides are available online and for download at http://go.microsoft.com/fwlink/?LinkID=75674.

Steps to Planning Volume Activations

A VA 2.0 deployment can be broken down into five major steps. Each step listed is expanded in a corresponding section of this document. To plan a VA 2.0 deployment, you should complete the following steps:

1.      Review available activation models.

2.      Evaluate client connectivity.

3.      Map systems to an activation method.

4.      Determine product key needs.

5.      Determine monitoring and reporting needs.

Review Available Activation Models

Volume Activation provides two different models for implementing volume activations. The model you choose depends on the size, network infrastructure, connectivity, and security requirements of your organization. You can choose to use just one or both available models of volume activation.

Key Management Service (KMS)

KMS activates operating systems on your local network, eliminating the need for individual computers to connect to Microsoft®. To do this, KMS uses a client/server method of implementation. KMS clients connect to a KMS server, called the KMS host, for activation. The KMS host resides on your local network.

Minimum Computer Requirements

To plan for the KMS model of activation, you must ensure that your network meets or exceeds the minimum number of computers that KMS requires and you must understand how the KMS host tracks the number of computers on your network.

KMS Activation Thresholds

KMS can activate both physical and virtual computers, but to qualify for KMS activation a network must have a minimum number of physical computers, called the activation threshold. KMS clients activate only after this threshold is met. To ensure that the activation threshold is met, a KMS host counts the number of physical computers requesting activation on the network. The count of activation requests is a combination of both Windows Vista and Windows Server 2008 computers. However, each of these operating systems begins activating after a different threshold is met. The Windows Server 2008 KMS client threshold is five (5) physical computers. The Windows Vista KMS client threshold is twenty-five (25) physical computers. Virtual computers do not contribute to the activation count, but virtual computers are activated by KMS after the physical computer threshold is met.

A KMS host responds to each valid activation request from a KMS client with the count of how many physical computers have contacted the KMS host for activation. Clients that receive a count below the activation threshold do not activate. For example, if the first two computers that contact the KMS host have Windows Vista installed on a physical computer, the first receives an activation count of one and the second receives an activation count of two. If the next computer is a Windows Vista virtual computer, it receives an activation count of two, because only physical computer installations advance the activation count. None of these systems activate since Windows Vista computers must receive an activation count that is 25 or greater to activate. Clients that do not activate because the activation count is too low connect to the KMS host every two hours, by default, to receive a new count.

If the next computer that contacts the KMS host has Windows Server 2008 installed on a physical computer, it receives an activation count of three, because activation counts are a combination of Windows Server 2008 and Windows Vista computers. If a Windows Server 2008 computer, whether it is a physical computer or a virtual computer, receives an activation count that is five or greater, it activates. If a Windows Vista computer, whether it is a physical computer or a virtual computer, receives an activation count that is 25 or greater, it activates.

Activation Count Cache

To track the activation threshold, the KMS host keeps a track of the KMS clients that request activation. Each KMS client that connects to the KMS host is given a  unique client identification (CMID) that is saved to a table on the KMS host. Each activation request remains in the table for 30 days. When a client renews its activation, the cached CMID is removed from the table, a new record is created, and the 30-day period begins again. If a KMS client does not renew its activation within 30 days, the corresponding CMID is removed from the table and the activation count is reduced by one.

The KMS host caches twice the number of CMIDs that KMS clients require for activation. For example, on a network with Windows Vista clients, the KMS activation threshold is 25. This KMS host caches the CMIDs of the most recent 50 activations. The KMS activation threshold for Windows Server 2008 is 5. A KMS host that is only contacted by Windows Server 2008 KMS clients caches the 10 most recent CMIDs. If that KMS host is later contacted by Windows Vista, it increases the cache size to 50 to accommodate the higher activation count requirement.

How KMS Works

KMS activation requires TCP/IP connectivity. KMS hosts and clients are, by default, configured to use DNS to publish and use the KMS service. You can use these default settings, which require little to no administrative actions, or you can manually configure KMS hosts and clients, depending on your network configuration and security requirements.

KMS Activation Renewal

KMS activations are valid for 180 days. This is called the activation validity interval. KMS clients must renew their activation by connecting to the KMS host at least once every 180 days to stay activated. By default, KMS client computers attempt to renew their activation every 7 days. After a client’s activation is renewed, the activation validity interval begins again.

Publication of the KMS Service

The KMS service uses service (SRV) resource records (RR) in DNS to store and communicate the locations of KMS hosts. KMS hosts, by default, automatically publish the information KMS clients need to find and connect to them using Dynamic DNS (DDNS).

Client Discovery of the KMS Service

KMS clients, by default, query the DNS server for KMS service information. The first time a KMS client queries the DNS server for KMS service information, it randomly chooses a KMS host from the list of SRV resource records returned by DNS. If the selected KMS host does not respond, the KMS client computer removes that KMS host from its list of SRV resource records and randomly selects another KMS host from the list. After a KMS host responds, the KMS client computer caches the name of the KMS host and uses it for subsequent activation and renewal attempts. If the cached KMS host does not respond on a subsequent renewal, the KMS client computer discovers a new KMS host by contacting the DNS server for KMS SRV records.

Client computers connect to the KMS host for activation using anonymous Remote Procedure Calls (RPCs) over TCP, using TCP port 1688 by default. This connection is anonymous. After the client computer establishes a TCP session with the KMS host, the client then sends a single request packet. The KMS host responds with the activation count. If the count meets or exceeds the activation threshold for that operating system, the client activates and the session is closed. This same process is used for renewal requests.

Planning a KMS Deployment

The KMS service does not require a dedicated server and can be co-hosted with other services. You can run a KMS host on physical or virtual system running Windows Server 2008, Windows Vista, or Windows Server 2003, but a KMS host running on Windows Vista can only activate Windows Vista KMS clients. A single KMS host can support an unlimited number of KMS clients, but for failover, two KMS hosts is the recommended minimum. Most organizations can operate with as few as two KMS hosts for their entire infrastructure.

Note:   KMS is automatically included with Windows Server 2008 and Windows Vista, but not with Windows Server 2003. If you want to host KMS on Windows Server 2003, you 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.

Planning DNS Server Configuration

DDNS and SRV record support are needed for the default auto-publishing feature of KMS. Any DNS server that supports SRV records (per RFC 2782) and dynamic updates (per RFC 2136) can support KMS client default behavior and KMS SRV RR publishing. Berkeley Internet Domain Name (BIND) versions 8.x and 9.x support both SRV records and DDNS.

You need to configure the KMS host so that it has the credentials needed to create and update SRV, A, and AAAA resource records on your DDNS servers, or you need to manually create these records. The recommended solution for giving the KMS host the needed credentials is to create a security group in Active Directory® and add all KMS hosts to that group. In the Microsoft DNS server, ensure that this security group is given full control permission over the _VLMCS._TCP record on each DNS domain that will contain the KMS SRV records.

Activating the First KMS Host

KMS hosts on your network need to install a KMS key and then activate with Microsoft. Installation of a KMS Key enables the Key Management Service on the KMS host. After this installation, activation is completed either by telephone or online. The KMS keys used for KMS activations are only installed on KMS hosts and never on individual KMS clients. Beyond this initial activation, a KMS host does not communicate any information to Microsoft.

Activating Subsequent KMS Hosts

After the first KMS host is activated, that KMS key used on the first KMS host can then activate up to five more KMS hosts on your network. After a KMS host is activated, administrators can reactivate the same host up to nine more times with the same key.

If your organization needs more than six KMS hosts, you may request additional activations for your organization’s KMS key. An example of this would be if you had ten separate physical locations under one volume licensing agreement and you wanted each location to have a local KMS host. To request this exception, you should call your Activation Call Center. For more information about this, go to the Volume Licensing Web site at http://go.microsoft.com/fwlink/?LinkID=73076.

Planning KMS Clients

Computers running volume licensing editions of Windows Vista and Windows Server 2008 are, by default, KMS clients with no additional configuration needed. KMS clients can locate a KMS host automatically by querying DNS for SRV records that publish the KMS service. If your network environment does not use SRV records, an administrator can manually configure a KMS client to use a specific KMS host. The steps needed to manually configure KMS clients are in the Volume Activation 2.0 Deployment Guide.

Multiple Activation Key (MAK)

MAK is used for a one-time activation with Microsoft’s hosted activation services. Each MAK key has a predetermined number of allowed activations. This number is based on your volume licensing agreements, and does not match your organization’s exact license count. Each activation using a MAK with Microsoft’s hosted activation service counts towards the activation limit.

There are two ways to activate computers using MAK: MAK Independent and MAK Proxy activation. MAK Independent activation requires that each computer independently connect and activate with Microsoft, either over the Internet or by telephone. MAK Proxy activation enables a centralized activation request on behalf of multiple computers with one connection to Microsoft. MAK Proxy activation is configured using the Volume Activation Management Tool (VAMT).

MAK can be used for individual computers or with an image that can be bulk-duplicated or provided for download using Microsoft deployment solutions. MAK can also be used on a computer that was originally configured to use KMS activation, if that computer’s activation is about to or has reached the end of its grace period or activation validity interval.

MAK is recommended for computers that rarely or never connect to the corporate network and for environments where the number of physical computers needing activation does not meet the KMS activation threshold. MAK Independent activation is best suited for computers within an organization that do not maintain a connection to the corporate network. MAK Proxy activation is appropriate for environments where security concerns may restrict direct access to the Internet or the corporate network. It is also suited for development and test labs that lack this connectivity.

Volume Activation Management Tool (VAMT)

VAMT is a standalone application that collects activation requests from several systems then sends them, in bulk, to Microsoft. VAMT allows you to specify a group of computers to activate using Active Directory (AD), Workgroup names, IP addresses, or computer names. After receiving the activation confirmation codes, VAMT then distributes them back to the systems that requested activation. Because VAMT also stores these confirmation codes locally, it can reactivate a previously activated system after it is reimaged without contacting Microsoft. You can download VAMT along with prescriptive guidance at http://go.microsoft.com/fwlink/?LinkID=77533.

MAK Architecture

MAK Independent activation installs a MAK product key on a client computer and instructs that computer to activate against Microsoft servers over the Internet. In MAK Proxy activation, VAMT installs a MAK product key on a client computer, obtains the Installation ID (IID) from the target computer, sends the IID to Microsoft on behalf of the client, and obtains a Confirmation ID (CID). The tool then activates the client by installing the CID.

Evaluate Client Connectivity

Each method available in VA 2.0 is best suited to a particular network configuration. To select the best activation method or methods for your organization, you need to assess your network environment to identify how different groups of computers connect to the network. Connectivity to the corporate network, Internet access, and the number of computers that regularly connect to your corporate network are some of the important characteristics to identify. Most medium to large organizations use a combination of activation methods because of varied client connectivity needs.

KMS is the recommended activation method for computers that are well connected to the organization's core network or that have periodic connectivity, such as computers that are offsite. MAK activation is the recommended activation method for computers that are offsite with limited connectivity or that cannot connect to the core network because of security restrictions.

Table 1 lists common network configurations and the best practice recommendations for each type. Each solution factors in the number of physical computers and network connectivity of the activation clients.

Table 1: VA 2.0 Planning Considerations by Network Infrastructure

 

		Recommendations	Considerations
Network Infrastructure	Core network Well-connected LAN Most common scenario	If physical computers > KMS activation threshold: §  Small (<100 machines): KMS host = 1 §  Medium (>100 machines): KMS host ≥ 1 §  Enterprise: KMS host > 1 If physical computers ≤ KMS activation threshold: §  MAK (by telephone or Internet) §  MAK Proxy	·Minimize the number of KMS hosts ·Each KMS host must consistently maintain a count of physical machines > KMS activation threshold ·KMS hosts are autonomous ·KMS host is activated by telephone or Internet
	Isolated network Branch office, high security network segments, perimeter networks Well-connected zoned LAN	If ports on firewalls can be opened between KMS clients and hosts: § Use KMS host(s) in core network If policy prevents firewall modification: §  MAK (by telephone or Internet) §  MAK Proxy	·Firewall configuration ·RPC over TCP (TCP port 1688); initiated by the client ·Change management on firewall rule sets
	Test or development lab Isolated network	If physical computers > KMS activation threshold: ·KMS host = 1 (per isolated network) If physical computers ≤ KMS activation threshold: ·No activation (reset grace period) ·MAK (by telephone) ·MAK Proxy performed manually	·Variable configuration ·Limited number of systems ·Virtual computers ·KMS host and MAK activation through telephone; MAK Proxy performed manually
	Individual disconnected computer   No connectivity to the Internet or core network   Roaming computers that periodically connect to core network or connect through Virtual Private Network (VPN)	For clients that connect periodically to the core network: ·Use the KMS host(s) in core network For clients that never connect to core network or have no Internet access: ·MAK (by telephone) For networks that cannot connect to the core network: ·If physical computers > KMS activation threshold, - Small: KMS host = 1 - Medium: KMS host ≥ 1 - Enterprise: KMS host > 1 ·If physical computers ≤ KMS activation threshold, MAK Independent or MAK Proxy performed manually	·Restricted environments or networks that cannot connect to other networks ·KMS host can be activated, moved to disconnected network ·KMS host and MAK activation by telephone; MAK Proxy performed manually

 

Activation Scenarios

This section illustrates a few examples of VA 2.0 solutions in heterogeneous corporate environments that require more than one activation method. Each scenario has a recommended activation solution, but some environments may have infrastructure or policy requirements that are best suited to a different solution.

Core Network

A centralized KMS solution is the recommended activation method for computers on the core network. This solution is for networks that are characterized by well-connected computers on multiple network segments that also have a connection to the Internet. In Figure 1, the core network has a KMS host. KMS hosts publish the KMS service using DDNS. KMS clients query DNS for KMS SRV records and activate themselves after contacting one of the KMS hosts. The KMS hosts are activated directly through the Internet.

Figure 1: Core Network Scenario

Note:   You can install a KMS host on a virtual computer. You should select a virtual computer that is unlikely to be moved to a different physical computer. If the virtual computer KMS host is moved to a different physical computer, the operating system detects the change in the underlying hardware, and the KMS host must reactivate with Microsoft.

Isolated Networks

Many organizations have networks that are separated into multiple security zones. Some networks have a high security zone that is isolated because it has sensitive information, while other networks are separated from the core network because they are in a different physical location.

High Security Zone

High security zones are parts of a network that are separated by a firewall that limits communication to and from other networks. If the computers in a high security zone are allowed access to the core network, you can activate the high security zone computers by using KMS hosts located in the core network. This way, the number of client computers in the high security network does not have to meet any KMS activation threshold. If you use this configuration, firewalls must allow TCP port 1688 outbound from the high security zone and an RPC reply inbound. If these firewall exceptions are not authorized, and the number of physical computers in the high security zone is sufficient to meet KMS activation thresholds, you can add a local KMS host to the high security zone.

Figure 2 shows an environment that has a corporate security policy that does not allow any traffic between computers in the high security zone and the core network. Because the high security zone has enough computers to meet the KMS activation threshold, the high security zone has its own local KMS host. The KMS host itself is activated by telephone.

Figure 2: High Security Network Scenario

If KMS is not appropriate because there are only a few computers in the high security zone, MAK Independent activation is recommended. Each computer can activate independently with Microsoft, by telephone.

MAK Proxy activation using VAMT is also possible in this scenario. Since the computers in the high security zone do not have Internet access, VAMT can discover them using Active Directory, computer name, IP address, or membership in a workgroup. VAMT uses WMI to install MAK product keys and CIDs and to retrieve status on MAK clients. Since this traffic is not allowed through the firewall, you must have a local VAMT host in the high security zone.

Branch Office Locations

Figure 3 shows an enterprise network that supports client computers in three branch offices. Site A uses KMS with a local KMS host, because it has more than 25 client computers and it does not have a secure TCP/IP connectivity to the core network. Site B uses MAK activation, because KMS does not support sites with fewer than 25 Windows Vista KMS client computers and the site is not connected by a secure link to the core network. Site C uses KMS, because it is connected to the core network by a secure connection over a private WAN, and activation thresholds are met using core network KMS clients.

Figure 3: Branch Office Scenario

Individual Disconnected Computers

Some users in an organization may be in remote locations or may travel to many locations. This scenario is common for roaming clients, such as the computers of salespeople or other users that are offsite, but not at branch locations. This scenario can also apply to remote branch office locations that have no connection or an intermittent connection to the core network.

Disconnected computers can use KMS or MAK depending on how often the computers connect to the core network. Use KMS activation for computers that connect to the core network, either directly or through a VPN, at least once every 180 days, and where the core network is using KMS activation. Use MAK Independent activation, by telephone or the Internet, for computers that rarely or never connect to the core network. Figure 4 shows disconnected clients using MAK Independent activation through the Internet and also the telephone.

Figure 4: Disconnected Computers Scenario

Test/Development Labs

In a lab environment, computers are reconfigured often and usually have a large number of virtual computers. You should first determine whether the computers in test and development labs need activation. You can reset the initial 30-day grace period of a Windows Vista computer three times without activating it. If you have Windows Vista Enterprise edition, you can reset the grace period five times. The initial grace period of Windows Server 2008 computer is 60 days and can be reset three times. If you rebuild lab computers often enough, within 120 days for Windows Vista, within 180 days for Windows Vista Enterprise edition, and within 240 days for Windows Server2008, you do not need to activate lab computers.

If you do need activation, labs can use KMS or MAK activation. Use KMS activation if the computers have connectivity to a core network that is using KMS. If the number of physical computers in the lab meets the KMS activation threshold, you can deploy a local KMS host.

In labs that have a high turnover of computers and also have a small number of physical KMS clients, it is important to monitor the KMS activation count to maintain a sufficient number of cached CMIDs on the KMS host. A KMS host caches activation requests from physical computers for 30 days. See the Minimum Computer Requirements section of this document for more information about how CMIDs affect activations. If your lab environment needs activation, but does not meet the conditions for KMS activation, you can use MAK Independent activation, by telephone or Internet, if available.

MAK Proxy activation using VAMT can also be used in this scenario. If you install a local VAMT inside a lab that has no outside connectivity, you must manually update VAMT. You need to install VAMT in the isolated lab network and also in a network that has access to the Internet. VAMT, in the isolated lab, performs discovery, obtains status, installs a MAK product key, and obtains the IID of each computer in the lab. You can then export this information from VAMT, save it to removable media, and then import the file to a computer running VAMT that has access to the Internet. VAMT then sends the IIDs to Microsoft and obtains the corresponding CIDs needed to complete activation. After you export this data to removable media, you can then take it to the isolated lab to import the CIDs so VAMT can complete the activations.

Map Systems to an Activation Method

After evaluating the recommended activation scenarios, the next step is mapping computers using volume activation to activation methods. The goal is to ensure that all computers are associated with an activation option. Table 2 provides a simple job aid that ensures all computers are mapped to an activation method. When completing this job aid, ensure that all computers using KMS are on networks that meet KMS activation thresholds.

Table 2: Activation Method Worksheet

 

Criteria	Activation Method	Number of Computers
Total number of computers to be activated
Number of computers that will connect to the network at least once every 180 days (directly or VPN), and where the KMS activation threshold is met	KMS
Number of computers that do not connect to network at least once every 180 days	MAK
Number of computers in isolated networks where the KMS activation threshold is met	KMS
Number of computers in isolated networks where the KMS activation threshold is not met	MAK
Number of computers in test/development labs that will not be activated	None
Remaining computer count should be zero

 

Determine Product Key Needs

Windows Vista and Windows Server 2008 come in a variety of editions. To simplify volume activation and the number of product keys needed for an organization, Microsoft created product key groups for volume editions of these operating systems. Product keys for both KMS and MAK apply to product groups rather than individual operating system editions, but KMS and MAK each use product key groups in a different way.

MAK activation uses product key groups as individual groupings. Product keys for MAK activations are directly associated with a single product group and can only activate the Windows® editions within that specific product group. With KMS, product keys work hierarchically with the product groups. Figure 5 demonstrates how KMS treats product key groups hierarchically. The first and least inclusive group of the hierarchy is the Client Volume License product group, while Server Group C is the most inclusive group in the KMS hierarchy. A KMS key can activate Windows editions in its own product group and can also activate Windows editions that are higher in the pyramid of the product key group hierarchy.

Figure 5 Product Key Groupings

 

As an example, a volume licensing customer that needs to activate Windows Server 2008 Datacenter using KMS needs to use a KMS key for Server Group C. Server Group C is the most inclusive product group, so a KMS key for Server Group C can activate volume editions of Windows Server 2008 and Windows Vista that belong to all other product key groups. If a customer has a KMS key for Server Group B, that key can activate products that belong to Server Group B as well as products that belong to the Client Volume License group. This functionality is automatic and requires no further actions from end users or VA 2.0 administrators.

For an up-to-date list of the Windows editions that are in each of the four product key groups, go to http://go.microsoft.com/fwlink/?LinkID=75674.

Determine Monitoring and Reporting Needs

Organizations that use VA 2.0 need to track product key usage and the license conditions of activated computers. One tool available to volume licensing customers is the VLSC Web page at http://go.microsoft.com/fwlink/?LinkId=107544. Volume licensing customers can log on to this Web site at any time to view their KMS key information as well as the number of activations that remain on a MAK key.

There are several additional tools available to assist volume licensing customers with managing activations and product key usage. This section describes the available tools and how each assists volume licensing customers.

Windows Management Instrumentation (WMI)

Data that is gathered during activation is accessible using WMI. Several of the tools available use WMI to access volume activation data. See Appendix 1 of the Volume Activation 2.0 Operations Guide for a list all of WMI methods, properties, registry keys, and event IDs for product activation.

System Management Server (SMS) and System Center Configuration Manager (SCCM)

Both MAK and KMS can use Systems Management Server (SMS) 2003 with Service Pack 3 (SP3) or System Center Configuration Manager (SCCM) 2007 to monitor the license conditions of their organization’s computers. For a detailed description of the available license conditions, see Appendix 2:  License Conditions in this guide.

SMS 2003 SP3 and SCCM 2007 use built-in Asset Intelligence reporting and WMI to generate detailed activation reports for Windows Vista and Windows Server 2008 computers. This information can also serve as the starting point for your organization to track and report software asset management from a licensing perspective.

Event Logs

The KMS service records every action in the application logs of KMS clients and hosts. A KMS client records activation requests, renewals, and responses in the KMS client’s local application log using Microsoft Windows Security Licensing (SLC) event numbers 12288 and 12289. The KMS host logs a separate entry for each request it receives from a KMS client as SLC event number 12290. These entries are saved to the Key Management Service log in the Applications and Services Logs folder. Each KMS host keeps an individual log of activations. There is no replication of logs between KMS hosts.

KMS Management Pack

You can archive and review KMS’s event logs manually or, if you have System Center Operations Manager 2005, you can use the Microsoft Key Management Service (KMS) MOM 2005 Management Pack. The KMS Management Pack uses WMI to generate detailed activation reports for Windows Vista and Windows Server 2008 computers. To download this Management Pack and its Management Pack guide, go to the Systems Center Operations Manager Product Catalog at http://go.microsoft.com/fwlink/?LinkID=110332.

Volume Activation Management Tool (VAMT)

Each MAK key has a predetermined number of allowed activations, based on an organization’s volume licensing agreement. Each activation with Microsoft’s hosted activation services reduces the MAK activation pool by one. MAK implementations should include how your organization plans to monitor the number of MAK activations that are left.

Both MAK Independent and MAK Proxy activations can use VAMT to monitor this. VAMT is a standalone application that can run on Windows XP, Windows Server 2003, or Windows Vista. It reports on the license condition of all systems using MAK activation and tracks the MAK activation count.

Appendix 1:  Information Sent to Microsoft During Activation

Microsoft uses the information collected during activation to confirm that you have a licensed copy of the software. The information is then aggregated for statistical analysis. Microsoft does not use the information to identify you or contact you. For more information about the information captured during activation and the use of that data by Microsoft, see the Windows Vista Privacy Statement at http://go.microsoft.com/fwlink/?LinkID=52526http://go.microsoft.com/fwlink/?LinkId=52526.

During MAK activation and KMS host activation, the following information is sent to Microsoft:

·         Product key

·         Edition of the operating system and the channel from which it was obtained

·         Current date

·         License and activation condition

·         Hardware ID hash, a non-unique number that cannot be reverse engineered

·         Language settings

·         IP address, used only for verifying the location of the request

Appendix 2:  License Conditions

Windows Vista and Windows Server 2008 may be in one of five software licensing conditions: activated, grace, genuine, notification, and unlicensed. These conditions reflect the status of the system’s activation and genuine state, which dictates the end user experience.

The software licensing architecture governs the licensing condition of Windows systems. This architecture has a policy engine that is built from a number of core Windows security technologies. It is designed to protect the code and the associated licensing condition from tampering or other malicious behavior.

The policy engine gets data from a set of cryptographically signed XrML license files. XrML is an industry-standard rights expression language that is used by a number of Windows components. License files define the rights and conditions of the installed edition of Windows. All licensing files, or other data used by the policy engine, are digitally signed, or encrypted, using keys chained to secure Microsoft roots of trust.

Activated

When a system is activated, it can use the full functionality of the installed operating system. The functionality for a Windows edition is defined by a combination of licensing files and a set of policies, or rights, granted as a result of the activation process. Individual Windows components call software licensing APIs to determine what rights are granted and adjust their functionality according to the response.

Grace

After a Windows Vista or Windows Server 2008 operating systems is installed, but before it is activated, the computer has the full functionality of the operating system, but only for a limited amount of time, or grace period. The length of a grace period can vary from thirty days, for Windows Vista, to sixty days, for Windows Server 2008. During this initial grace period, there are periodic notifications that the system needs to be activated. The notifications are minimally intrusive and may not start at the beginning of the grace period, but do increase in frequency towards the end of the grace period.

Genuine

The Genuine condition is not associated with the activation process. Instead, it is a condition that is determined by the online Windows Genuine Advantage (WGA) service. When a user attempts to download or use a Genuine-Only feature, the WGA validation service checks the operating system of the requesting computer.

An operating system can have one of three different Genuine statuses:

·         Non-Genuine. The system has obtained a ticket from the online validation service indicating that it is not genuine.

·         Local Genuine. The system has not obtained a valid ticket.

·         Genuine. The system has a Microsoft signed ticket from the online validation service indicating that it is genuine.

The Genuine license condition applies only to Windows Vista. Initially, during the grace period, a Windows Vista system is always in a Local Genuine condition. A system is never marked Non-Genuine until after it fails validation through the online WGA service, and received a Non-Genuine ticket. Likewise, after a system has a Non-Genuine status, it must successfully validate through the WGA service to receive a Genuine ticket.

While it is necessary for a system to be activated to be considered Genuine, the process of activation does not reset or clear a previous Non-Genuine status. As a result, to return a system to a fully functional activated condition, it must be both activated and then validated against the WGA service.

Notification

The purpose of the notifications-based experience is to differentiate between a genuine and activated copy of Windows Vista and one that is not, and do so in a way that maintains system functionality such as logon, access to the familiar desktop etc. RFM has been removed from the product and replaced with a notifications-based experience. This new notification experience means that systems that are not activated during their grace periods (initial activations as well as those due to hardware changes) or that fail our validation may have this experience. The behavior of a system in the notification condition is similar to one that is in the activated condition, with the following exceptions:

·         Upon interactive logon, a dialog box appears indicating that the system is not activated. The dialog box also provides a list of actions that can be taken, such as activation with a product key or online validation. This dialog box can delay a logon for 15 seconds or up to two minutes. Non-interactive logon is unaffected.

·         The desktop background is set to black.

·         Every hour a notification appears, through a task bar balloon, reminding the user of the notification condition. If the background is changed, it is reset to black when the notification appears.

Three specific features are also disabled in the notification condition:

·         A KMS host cannot activate or renew KMS clients or other KMS hosts.

·         Windows Update installs only critical updates.

·         Optional downloads marked as Genuine Only are not available.

You must activate a system for it to leave the notification condition.

Unlicensed/Reduced Functionality Mode (RFM)

Systems running Windows Vista (prior to SP1) that are not activated within the grace period change to an unlicensed/RFM condition. RFM can affect computers running the initial release of Windows Vista. Windows Vista SP1 and Windows Server 2008 do not have an unlicensed/RFM condition. With RFM, users are still able to use most Windows features. Users can access files, run scripts, manage the computer using WMI, change product keys, activate remotely, and log on with default browser access. However, the user may need to restart the computer in Safe Mode to access or back up personal data and applications. The user logon is limited to one-hour sessions with no access to the Start Menu, Task Manager, remote desktop or printing services. Additionally, all Genuine Only features are disabled.