Volume Activation in Server 2008

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.

End of Article

   Previous  1  2  [3]  Next