In Windows Vista, Microsoft has done away with volume license keys that can be freely distributed in an unlimited capacity with no activation required. Instead, there are now two different methods you can use to assign volume license keys to computers running Vista. The preferred method involves setting up a key management server and allowing it to perform key distribution and activation for computers on your network running Vista. In this article, I will show you how to setup and configure a key management server for your organization.
I want to quickly mention that, for right now, setting up a key management server does not involve an actual server at all (aside from adding records to your DNS server). Instead, you will have to install Vista onto a computer and configure it to act as a key management server. Eventually, you will be able to configure Longhorn Server to act as a key management server for Vista clients, but Longhorn is still in beta testing. Likewise, Microsoft is currently developing an add-on for Windows Server 2003 that will allow it to function as a key management server for Vista, but that add-on isn't expected to be released for several months.
Installing a key management server
the installation process by installing
When the installation process completes, log on to the computer, and open a Command Prompt window (with elevated privileges). Now, you must run a script to install your key management server key. It is very important that you do this from the Command Prompt window, and that you not attempt to use the GUI for this procedure. To install the key management server key, enter the following command (where <Volume License Key> is the actual key you want to enter):
Cscript C:\windows\system32\slmgr.vbs –ipk
<Volume License Key>
Once the script completes, you must activate the computer before it will be able to function as a key management server. Once again, you will have to perform the activation from the Command Prompt window, not through the GUI. The command you use will vary, depending on whether you are activating the machine over the Internet or the telephone.
If you are activating the computer using the Internet, use this command:
Cscript C:\windows\system32\slmgr.vbs –ato
If you are activating Windows over the telephone, enter the following command:
When you execute this command, you will be presented with a set of on-screen instructions that will walk you through the rest of the activation process.
Configuring the key management server
There isn't really any additional configuration you have to do; but, there are several things you have the option of configuring. The first of these optional configuration settings allows you to disable DNS publishing. I will talk more about DNS publishing later in this article; but, for now, I want to show you how to disable DNS publishing, should the need arise. In most cases, I recommend leaving DNS publishing enabled. You can disable DNS publishing by opening a Command Prompt window and entering the following command:
Cscript C:\windows\system32\slmgr.vbs -cdns
If you decide later that you need to re-enable DNS publishing, you can do so by entering the following command:
Cscript C:\windows\system32\slmgr.vbs –sdns
Another optional setting that you can configure is the scheduling priority for key management services. Normally, the key management services should not be disruptive, but if you find they are interfering with other processes running on the machine, then you can lower the priority. To do so, enter the following command:
Cscript C:\windows\system32\slmgr.vbs –cpri
If, at a later time, you want to return the key management services to their default priority, you can do so by entering this command:
Cscript C:\windows\system32\slmgr.vbs -spri
Another configuration option involves changing the TCP port number that the key management services use to communicate with clients. Before I show you this technique, I want to mention that you should not change the default TCP port unless you have a very compelling reason to do so. If you do want to change the port number, you can do so by entering the following command:
Cscript C:\windows\system32\slmgr.vbs –sprt
<new port number>
I don't recommend using the above command, because key management service clients that use direct registration will have to be reconfigured to recognize the new port number. On the other hand, clients that use auto-discovery will automatically be made aware of the new port when they select the key management server.
Your last two options are probably the most useful; they allow you to reconfigure the activation and renewal intervals that the key management server will use. By default, clients that have not been previously activated will attempt an activation every two hours until activated. You can change this activation by using the following command:
Cscript C:\windows\system32\slmgr.vbs –sai
<new activation interval in minutes>
When a key management server activates a client that's running Vista, the activation is only good for six months. By default, client computers contact the key management server once a week to renew their activation. This extends the activation period to six months from the latest renewal, rather than to six months from the original activation.
Normally, there is probably no reason to change the renewal interval, unless you wish to decrease the workload on the key management server. If you want to modify the renewal interval, you can do so by entering the following command:
Cscript C:\windows\system32\slmgr.vbs –sri
<new renewal interval in minutes>
Completing the configuration process
If you have reconfigured the server using any of the techniques discussed in the section above, then you will have to reboot the computer acting as the key management server. If rebooting is not an option, then you can restart the key management services. To do so, open a Command Prompt window (with elevated privileges) and enter the following commands:
Net stop slsvc
Net start slsvc
Key management services and DNS
Earlier, I showed you how to disable automatic DNS publishing. Having a DNS record for your key management server is a requirement. The only time you would want to disable automatic DNS publishing would be in situations in which you were using a non-Microsoft DNS that does not support automatic publishing. Automatic publishing requires the use of dynamic DNS. Likewise, in order for automatic DNS publishing to work, the key management server must have permission to create a DNS record, and to update that record periodically.
When the key management services are initially configured, automatic DNS publishing is enabled by default. Specifically, the key management server creates a SRV record. This SRV record contains a hostname record (an A record) that can be used to identify the name of that key management server. When a computer running Vista needs to retrieve a product key, it begins the process by contacting a DNS server and performing a DNS query for key management server related SRV records.
What happens next depends on whether there is only a single key management server in the organization, or if multiple key management servers have been deployed. If there is only a single key management server, then the Vista client is given the identity of that key management server. If multiple key management servers are in use, then the DNS server will choose one at random, and will provide the identity of that server to the client that requested it.
Once the client has received the identity of a key management server from the DNS server, it attempts to contact the key management server using the designated TCP port. By default, TCP port 1688 is used. You must, therefore, ensure that no firewalls are blocking communications between the client and the key management server.
The first time I read about how the key management services make use of DNS, I thought it seemed a little strange that Microsoft would use DNS — as opposed to the Active Directory — for storing key management server references. If you really stop and think about it, though, using DNS for this purpose makes sense. If the key management services relied on the Active Directory, then only workstations that were members of the Active Directory forest could be activated by the key management server.
Although the key management services are designed to publish DNS information by default, there are a couple of caveats that you need to be aware of. This is especially true in situations in which multiple key management servers are in use.
One issue is server priority. As I mentioned earlier, an SRV record also contains a host record for the key management server. This record also contains other attributes, such as TCP port, and weight. However, only the port attribute (which tells clients which TCP port to use for communications with the key management server) actually works. Windows completely ignores the priority and weights attributes.
Since things like site affinity and DNS priority are incompatible with the key management services, you might be wondering how you can control which key management server will be used by volume licensing clients. One way to accomplish this is to manually create a different SRV record in each DNS domain. By doing so, you could effectively specify a specific key management server for each domain.
The other caveat has to do with the DNS publishing process itself. Automatic DNS publishing works fine in environments with a single key management server, but you will have to modify some permissions if your organization uses multiple key management servers.
The reason for this has to do with how security works on DNS servers. When dynamic updates are in use, a server has permission to create an SRV record and make modifications to the record later on. However, it does not have permissions to modify an SRV record that it did not create. This means that the first key management server you bring online should have no trouble creating the necessary SRV record and adding a host record to it.
When you bring the second key management server online, though, it does not attempt to create a SRV record, because a key management service related host record already exists. Instead, it simply attempts to add a host record to the existing SRV record. The problem is that the server does not have permissions to modify a record it did not create. Therefore, you are going to have to change the permissions on your DNS server so it will support the use of multiple key management servers.
The easiest way to accomplish this is to create a global security group in the Active Directory and add each of your key management servers to the group. Next, bring the first key management server online so the SRV record will be created. Next, go to the DNS management console, right-click on the SRV record, and select the Properties command from the resulting shortcut menu. This will cause the server to reveal the record's properties sheet. Add the newly created security group to the access control list, and grant the group full permissions over the record.