SolutionBase: Setting up a key management server for Vista

Microsoft has done away with volume license keys for Windows Vista. Instead, large organizations must rely on a key management server to distribute shared Vista license keys. Here's how to set one up.
This article is also available as a TechRepublic download.

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.

Author's note

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

Begin the installation process by installing Vista from the volume licensed media. Don't worry about entering a product key during installation.

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:

Slui.exe 4

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.


Hello, I have a situation where I inadvertanly used KMS keys rather than MAK keys on some Windows 2008 servers. When setting up my dedicated KMS server recently I discovered 15 additional _vlmcs SRV records related to these other 2008 servers, and I want to remove them. I did remove the KMS keys from these servers and entered MAK keys, but after deleting the SRV records they reappear. I've been reading up on what to do, and I've found several threads that suggest disabling the DNS publishing. Unfortunately when I attempt to run Cscript C:\windows\system32\slmgr.vbs -cdns I get an unrecogonized command error for -CDNS. For some reason my systems only recognize 12 of the 18 runtime options I have found for slmgr.vbs. Can you tell me how to stop these servers from being listed as KMS hosts? Ric T.

Jerry M. Gartner
Jerry M. Gartner

Vista actually "reactivates" periodically against the key server and MS servers on the internet. If, over time, a license becomes invalid, functionality of the system will be greatly reduced.


I would have to simply state that the Microsoft model for licensing is another piece to the non takeoff of the new Vista line of products. Understandably so, due to piracy. However the cumbersome over complicated processes they put an already overburdened IT shop/s is a headache a lot of shops just didn't want to have to deal with in these times. Not to mention the Vista product and its issues. There are a lot of small and medium size operations that blur the lines and make up a huge portion of Microsofts business model. And I truly believe they need to come up with a better soultion in regards to a licensing process, without having to have another expensive unit (In Time/Consulting Costs management, support etc...) to manage the licensing and reactivation process. Microsoft has done some amazing things for the technology world, and we have been big supporters for a long time. However its unfortunate that we are going out of our way to look at Linux and other products, knowing they will not really suffice. But we are always still having to look to avoid the cumbersome issues Microsoft has been forcing us to do.


. I realize that your post is just providing information and is not necessarily justifying Microsoft's stupid WGA... If you're not a pirate, Microsoft's WGA should [b][i]NEVER[/i][/b] de-activate your operating system and should [b][i]NEVER[/i][/b] put you in "reduced functionality mode". Yet, that is exactly what Microsoft's stupid WGA does to many legitimate customers every single day (1)(2)(3). There are excellent alternative operating systems available. I encourage everyone to take advantage of them as I have. For first-timers, I recommend Kubuntu (4). To my Microsoft stalwart friends: I'm really sorry your favorite vendor has lost its mind. But, sometimes most humane thing to do is shoot the horse. -------------------------------- (1) Vista falsely de-activates large numbers legitimate customers (2) Windows Vista Validation Issues Forum (3) Windows Genuine Advantage falsely accuses millions (..."under 1%"...) (4) Hot tip for Windows users: Try Kubuntu 7.04


And? Are you trying to say you should be able to have and use invalid licenses?

Jerry M. Gartner
Jerry M. Gartner

I'm not sure where you got the implication that one should be able to have invalid licenses. My point was that it is a different mechanism than in the past that will reduce the number of pirated versions of their software in use.

Editor's Picks