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 WARE\Microsoft\Windows NT\Current Version\SL\DnsDomainPublishList 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:

• Primary corporate forest(s)
• Secondary forests that trust one or more of your primary forests
• Untrusted forests (e.g., development, manufacturing)
• Workgroups

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.