Volume Activation in Server 2008

If you plan to deploy business versions of Windows Vista or any version of Windows Server 2008—which you’ll do eventually—you need to understand Volume Activation. A VA infrastructure is necessary for companies with more than a few hundred Vista or Server 2008 systems. Without this infrastructure, every volume-licensed build of these systems will eventually fail. In this article I define VA, explain how it works, and offer straightforward recommendations for deploying it in common situations.

Volume Activation Overview
Volume Activation 2.0 (VA2) is a major rework of Microsoft’s original volume licensing technology. In volume licensing, one Volume License Key (VLK) was used to activate an unlimited number of systems. This method required strong security to ensure the VLK was never compromised; if a key was “leaked” and became available on the Internet, Microsoft had to deactivate the key, and all the systems that used the key had to be rekeyed. VA2 avoids this problem by requiring every Vista or Server 2008 build that’s configured for volume licensing to activate with Microsoft, either directly or by proxy.

In VA2, volume builds of the OS use one of two activation methods: Multiple Activation Key (MAK) or Key Management Service (KMS). A MAK is similar to a VLK, but it has some important differences. A MAK has a limited number of activations associated with it, whereas a VLK is unlimited. Every activation instance that uses a MAK must verify with Microsoft; no verification is necessary with the VLK method. KMS is a client/server system that activates multiple clients without requiring any action from the system’s users. Unlike in a MAK activation, a system that uses KMS doesn’t have to contact Microsoft individually. Rather, the KMS hosts themselves activate the license with Microsoft on the client’s behalf. Microsoft expects that medium and large organizations that use VA will use KMS to activate most of their systems.

Before we delve into KMS and MAK activation in detail, let’s look at the five possible license states for VA clients. (Note that only the first state requires no action.) The first and most common state is Licensed, in which the client is activated and functioning normally. Next is Initial Grace or Out-Of-Box Grace; this period occurs after the VA client is first installed. Out-of-Tolerance Grace occurs when hardware changes on an activated system push the system beyond a tolerance level. Non-Genuine Grace occurs when a system that has the Windows Genuine Advantage (WGA) ActiveX control installed fails Genuine Activation. All of these license states have a grace period of 30 days. Finally, Unlicensed occurs when any of the grace periods expire. In the Unlicensed state, a system runs in reduced functionality mode (RFM).

Note that the Unlicensed state behavior is different in Vista SP1. If you’re using a system that hasn’t been activated and gone through the 30-day activation grace period, when you log on to the system on the 31st day, you’ll see a dialog box on a plain black background. You’ll have two options: Activate Windows now, which will bring up all the options to do so; or activate Windows later, which will take you directly to the desktop. Your desktop will appear as before, except you’ll have a plain black background and a message in the lower right corner over the system tray telling you that your copy of Windows isn’t genuine.

Key Management Service Architecture
The KMS VA system consists of one or more KMS hosts (servers) that activate clients configured to use KMS. These clients locate a KMS host by one of several methods and request the host to activate them. The KMS host uses a special KMS key to activate with Microsoft, then acts as a proxy to activate its own clients; the clients don’t need to contact Microsoft to activate. A host can activate an unlimited number of clients. As a result, Microsoft generally provides only one KMS key for an organization. Microsoft designed the KMS system to be highly scalable so it requires a minimum of KMS hosts.

KMS-configured systems must renew with the KMS host on a regular basis, otherwise they’ll eventually fall into the Unlicensed state and essentially be unusable until they reactivate with a KMS host. The reason such a critical piece of Microsoft infrastructure requires so few servers is that the Software Licensing Service has very loose requirements compared with other services. When a KMS client is first built (either a Vista client or a Server 2008 server), it has 30 days to activate. This initial grace period can be reset three times. During this period, the client tries every two hours to activate. After the client successfully activates, it attempts to contact a KMS host once every seven days by default to renew its activation another six months. Each client has a six-month countdown timer that resets whenever the client renews with a KMS host; if the client can’t renew for some reason, the timer keeps counting down, attempting again every week, until the client either renews or falls into the Unlicensed state. So a client attempts to reach a KMS host approximately 25 times. Also, the 15-second Time to Live (TTL) value of each KMS request is extremely long by other services’ standards and the data exchange is quite small, so the network proximity of the KMS host to the clients isn’t especially important.

KMS Installation
KMS can be installed on Server 2008, Windows Vista, or Windows Server 2003 SP1. It’s available on both x86 and x64 architectures for all platforms. No extra software is necessary for Server 2008 or Vista, but to run KMS on Windows 2003, go to the Microsoft downloads Web site (www.microsoft.com/ downloads), search for “KMS on W2K3 SP1,” then download and install either KMSW2K3_ EN-US_x86.zip or KMSW2K3_EN-US_x64 .zip. Both the KMS host and KMS client are part of Microsoft’s Software Licensing Service (slsvc.exe)—but KMS on a Windows 2003 server is referred to as the Software Protection Platform service.

Although KMS is available on Vista, I don’t recommend this configuration. Instead, I suggest that you use a KMS host on a server OS. Such a critical infrastructure service should be installed on an existing server or added as a regular production server.

The main utility to control a KMS host is a straightforward script, slmgr.vbs, which is located in the system32 folder of volume license versions of Server 2008 and Vista. The most common switches you’ll use are

The first step in installing a KMS host is to install a volume license version of the OS. A volume license OS version won’t prompt you to provide a license key when you build it. When the installation is complete, use the following command to install the KMS key provided by Microsoft:

  SLMGR.VBS -ipk

Continue on Page 2

Note that the KMS key isn’t a MAK. Don’t give this key out indiscriminately; it’s good for only six activations, intended for six KMS instances or rebuilds, for your entire company. Each of these instances can be reactivated as many as nine times. After you install the KMS key, you must activate it with Microsoft. This action authorizes, by proxy, all the activations the KMS host will perform. The most common way to activate the KMS host is by directly contacting Microsoft via the Internet. This method is called online activation, and is executed simply by entering

  SLMGR.VBS -ato

If your KMS host doesn’t have Internet access, you can call Microsoft and follow a mostly automated activation process. To find the Microsoft number to call, enter

SLUI.EXE 4

and follow the on-screen instructions.

KMS Location and Discovery
After your KMS host is up and running, your clients must be able to find it. You can forcibly point the clients to the host (called a direct connection), or you can let clients find the host themselves (called auto-discovery). To set up direct connection on a KMS client, simply run

  SLMGR.VBS -skms [:]

on the client. KMS_FQDN is the Fully Qualified Domain Name (FQDN) of the KMS host (or you can enter its IP address). You can also specify what port the client should connect to, if it’s other than the default of 1688.

Auto-discovery is a more complicated matter. For auto-discovery, KMS uses the DNS SRV record to publish its service into a DNS zone. Following the _service._protocol format of the SRV record, a record for KMS would look like _vlmcs._tcp.mycompany.com.

When it performs auto-discovery, the KMS client queries DNS for a list of servers that have published the _VLMCS record for the zone it’s a member of. DNS returns the list of KMS hosts in random order, and the client picks one and attempts to establish a session with it. If this attempt works, the client caches the server and attempts to use it for the next renewal attempt. If the session setup fails, the client picks another server at random. The KMS locator process works a little like the domain controller (DC) locator process (which also looks for an SRV record), but it’s simpler. For example, the client can’t look up KMS hosts by site because doing so isn’t necessary for the simpler requirements of the KMS service. Nor does KMS use weight and priority, which are options available in the SRV record to sort the result list.

A KMS host configured for auto-discovery doesn’t automatically publish SRV records to DNS in any zone other than the one in which it resides. This means you must manually publish SRV records into all other DNS zones—for example, the other child domains in a domain tree. To do so, you must enter each zone KMS should publish to in the HKEY_LOCAL_MACHINE SOFT WAREMicrosoftWindows NTCurrent VersionSLDnsDomainPublishList subkey’s REG_MULTI_SZ value. Use a separate line to enter each zone in which you want KMS to publish itself. Remember that the KMS host itself must have rights in the target zone to create these records, and that the zone must be able to resolve the host name in the SRV record. If you have many domains—especially domains that don’t trust the domain your KMS host resides in—this configuration can become one more manual list that must be kept in sync with your active domain list.

KMS auto-discovery is integrated with DNS, not Active Directory (AD); it works just as well with non-Windows DNS as it does with AD-integrated DNS. Any DNS server that supports SRV records (per RFC 2782) and dynamic updates (per RFC 2136) will support KMS client auto-discovery and KMS SRV record publishing. BIND 8.x and 9.x support both SRV records and DDNS.

KMS Odds and Ends
A KMS host itself doesn’t provide much information about its operation. Instead, a Microsoft Operations Manager (MOM) management pack for KMS is available at the Microsoft downloads Web site (www.microsoft.com/downloads). The management pack generates alerts for the major conditions that can cause KMS-related activation problems, such as initialization failures and DNS SRV record publishing failures. It also provides a wide range of reports on client activations through KMS.

Once activated, a KMS host will activate an unlimited number of clients. However, the host won’t begin activating clients until it receives a certain number of activation requests from physical (i.e., not virtual) machines. This is called the activation threshold. Vista’s threshold is 25 systems, whereas Server 2008’s threshold is 5 systems.

Suppose you have an environment with 500 volume-licensed Vista systems and one KMS host on a shared production network. As these systems begin appearing on the network, they will attempt to activate with the host they’ve found, either through autodiscovery or direct connection. The host will record each attempt, but not activate the clients until 25 separate clients have contacted it. The original 25 clients, when not activated by the KMS host, will simply retry until the KMS host has reached its activation threshold, at which point they’ll be activated normally. These thresholds are exclusive for each type; if KMS has reached its 25-client Vista threshold but not its 5-client Server 2008 threshold, it won’t activate Server 2008 servers until that threshold is reached.

A KMS host doesn’t track all its licensed clients; it records only the last 50 activations to make sure the service is working correctly. It also doesn’t pay attention to other KMS hosts in the network or share activation information between them. No upper limit exists for how many activations a KMS host can perform after it reaches its activation threshold; volume licenses aren’t a limited resource on its network. As many as six KMS hosts can be activated with one VLK, and each KMS host can be reactivated as many as nine times (e.g., if a KMS host must be rebuilt).

Using KMS rather than a MAK solution to activate clients has several advantages. First, KMS clients don’t need Internet or telephone access to activate their systems; they just need to be able to communicate with a KMS host. Second, there’s nothing to back up or restore on a KMS host. You simply rebuild, reinstall the VLK, activate, and it’s ready to go. Third, the KMS infrastructure is very lightweight and scalable; one KMS host with a hot spare in case of failure can service many tens of thousands of clients. Ultimately, the deciding factor for how many KMS hosts you use isn’t a matter of scalability; it’s your network configuration and your political landscape. If a substantial number of your clients can’t contact a KMS host because of network segmentation, you’ll have to land another host. And because KMS is a critical part of your infrastructure, strongly independent business groups might want control over their own KMS host.

Continue on Page 3

Although Server 2008 and Vista require different VLKs, a KMS host can hold only one activation key. So how can one key activate both Server 2008 and Vista systems? Microsoft created key groups, which is a hierarchy of licensing keys based on the products you purchased for volume license. The groups range from Vista to server groups A through C, where each server group increases in complexity (and cost). Vista key groups can activate only Vista systems. Server group A can activate Windows Web Server 2008 and Vista; server group B can activate Server 2008 Standard and Enterprise editions, as well as Web Server 2008 and Vista. Server group C can activate everything—Windows Server 2008 Datacenter, Windows Server 2008 for Itanium-based Systems, Server 2008 Standard and Enterprise editions, Web Server 2008, and Vista. When you purchase volume licenses, you’re provided with a key group that matches the products you purchase. Installing that key on your KMS host then activates all the less-expensive products.

Multiple Activation Keys
MAKs don’t require a specific infrastructure. Your company requests and pays for one MAK with a certain number of activations. You can activate the target system with the MAK in any of several ways—with an unattend file, manually from the Windows interface, or via a script. Every MAK installation must validate with Microsoft’s activation servers to complete successfully. Typically you’d use direct activation, in which the client itself activates directly with Microsoft, either via the Web or by phone. The Web activation is simple and works in the same way as earlier activation methods do (e.g., Windows XP activation). Activating by phone requires that you call a phone number and read aloud or enter an alphanumeric sequence on your phone, after which an operator reads a sequence of numbers that you enter into the corresponding key field.

If your clients don’t have direct access to the Internet (e.g., in a secured lab), or they don’t have the administrative rights necessary for MAK activation, Microsoft offers a proxy activation method that uses the Volume Activation Management Tool. VAMT, which is available from the Microsoft downloads Web site (www.microsoft.com/downloads), is designed for installation on a notebook that can move between the closed network and a network with Internet access. When on the closed network, VAMT applies one or more MAKs installed on it to the Server 2008 and Vista clients it discovers. For more information about VAMT, see the stepby- step guide that’s bundled with the VAMT installation files.

If you have to rebuild a system, you can use the same MAK as before—but its “number of keys used” will increment by one. Similarly, you can’t reuse the same MAK as in the previous build. For example, if you receive a system from an OEM with Server 2008 or Vista already installed, the system has a preinstalled MAK that you paid for as part of the system cost. If you rebuild the system to your standard build, you can’t reuse the MAK; you must use one of your own, essentially throwing away the OEM’s MAK.

Design Principles
Although using KMS and MAKs can seem complicated and confusing, following a few design principles helps make sense of it all. The most important principle to remember when building a VA2 infrastructure is to keep it simple. A simple configuration is easier to create, configure, and maintain. In addition, you should try to minimize the number of KMS hosts you use. If technically and politically possible, have just one set of KMS hosts for the entire enterprise. Also, try to maximize the number clients that use KMS (and thereby limit the number of clients that use MAKs). Finally, minimize the number of VAMT proxy configurations. To follow these principles, it’s helpful to divide your Windows systems into the following categories: the production network, secure networks with firewall access to the production network, isolated networks with little or no access to external networks, and disconnected clients.

Production network. This is your primary company intranet. Inventory the Windows environment’s AD forests and domains on the production network, categorizing them as follows:

Secure networks. For secure networks with firewall access to the production network, assume no Internet access. Again, perform the Windows environment inventory; a secure network probably won’t have as many categories as a production network.

Isolated networks. For isolated networks with little or no access to external networks, categorize the network as having fewer than 25 clients, or more than 25 clients.

Disconnected clients. Disconnected clients have no email access or any applications that require regular corporate network connections (e.g., a sales team’s demo notebook computers).

Recommendations
I recommend that you use KMS with DNS auto-discovery for your corporate forest(s) and secondary trusted forests, because this configuration is the easiest to implement. Register KMS into all the other domains in your forest and trusted forests so that clients can use DNS to find the service. Assuming the majority of your clients are in these forests, this design lets clients immediately activate via KMS. This configuration also assumes your company has a centralized IT model with a limited number of untrusted forests, which is similar to Microsoft’s environment— Microsoft has very few if any untrusted forests on their production networks. If you do have untrusted forests (e.g., development or test) on your production network, those administrators must manually register the KMS host’s A records and SRV records for auto-discovery to work. The KMS host probably won’t have rights to update DNS in an untrusted forest. Although adding records manually is simple, you must then manually update the records with the domain and forest configuration.

Workgroup clients on the production network should use KMS through auto-discovery, but its simplicity is a matter of which DNS servers the workgroup clients are using. If they use the DNS service of the KMS host’s forest, they can easily locate KMS.

For secure networks with some access to the production network, use a layered approach. First, configure the firewall to allow TCP port 1688 so secure network clients can contact the KMS host. Then, if you use a name rather than an IP address (as recommended), the host must be able to resolve the name through DNS. Whether you use auto-discovery or direct connection for KMS depends on the network’s DNS configuration; if the network has its own DNS, the network administrator must manually register the KMS host’s A records and SRV records. Having a consistent DNS infrastructure throughout your company is important to avoid inconsistency errors and duplication of effort. Similarly, KMS port 1688 should never be exposed outside the company; access to a KMS host is the same as handing out free VLKs.

Secure networks without external access present a more difficult configuration. If the network has fewer than 25 clients, you must use MAKs and activate the clients via the VAMT utility. A problem with this approach is that you must, for example, allow notebook computers that have been on the external network onto the secure network. If you have more than 25 clients, you can use KMS and activate it over the phone. This approach has its own shortcomings, though, because handing out the KMS key to anyone other than a few trusted administrators isn’t a secure practice. A variation on the secure network configuration is a secure network in which systems are rebuilt constantly (e.g., a client test lab). In such a situation, you might consider simply never activating the systems if they’ll exist for fewer than 90 days, because you can use the slmgr.vbs script’s rearm option (i.e., SLMGR .VBS /REARM) to reset the product activation timer a maximum of three times.

If your company uses a standardized build, a simple solution is to create two DNS Canonical Name (CNAME) records with a host name such as kms.yourcompany .com. Have these CNAME records each refer to a different KMS host, to create a basic round-robin configuration in which either of the hosts is randomly chosen. Configure your client build for direct connection, with the KMS name as kms .yourcompany.com. All the clients will then use kms.yourcompany.com all the time. You can control which KMS hosts this CNAME represents, and you don’t have to deal with auto-discovery or with registration of the SRV record in multiple DNS zones.

Follow the Basics
VA can be confusing and complicated, but you’ll need to use it if you ever plan to deploy Server 2008 or Vista. Although VA2 is far more complex than I can discuss in one article, following my basic design recommendations will let you implement it with a minimum of trouble. To become a VA2 expert, go to Microsoft’s VA2 Product Activation page (www.microsoft.com/licensing/resources/vol/default.mspx) and download the VA2 planning guide.

Sean writes about cloud identity, Microsoft hybrid identity, and whatever else he finds interesting at his blog on Enterprise Identity and on Twitter at @shorinsean.