When troubleshooting KMS configuration and activation issues, our customers are often surprised to find unexpected Windows or Office KMS hosts in their environment.

By default, Windows and Office clients discover KMS hosts via DNS and a related _vlmcs SRV record. To determine whether a KMS client can locate a KMS host and/or whether undesired KMS hosts exist on the network, run a command line similar to the following:

nslookup -type=srv _vlmcs._tcp >%temp%\kms.txt

Review the kms.txt file. It should contain one or more entries similar to the following:

Running this nslookup command frequently reveals _vlmcs SRV entries which are tied to unauthorized Windows or Office KMS hosts.

In many cases, Windows KMS hosts may have been unintentionally set up by users who mistakenly entered a KMS host product key, rather than a Windows client product key. To remedy this issue, perform the following steps on the machine(s) in question, to replace the KMS product group key and "convert" it to a KMS or MAK client:

1) Open an elevated command prompt.
2) Run a command similar to the following:

cscript slmgr.vbs /ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx   (where xxxxx-xxxxx-xxxxx-xxxxx-xxxxx is a 25 digit, Windows product key)

3) To prevent instability in the license service, the system should be restarted or the Software Protection Service should be restarted. The following command lines can be used to restart the Software Protection Service:

net stop sppsvc
net start sppsvc

4) Run a command line similar to the following to display the license information for the installed, active Windows edition:

cscript slmgr.vbs /dli

5) Using DNS Manager, in the appropriate forward lookup zone, delete the _vlmcs SRV records that exist for each machine which is not to serve as a Windows KMS host.
6) See the following articles for additional information:

Slmgr.vbs Options
http://technet.microsoft.com/en-us/library/ff793433.aspx

Windows 7 and Windows Server 2008 R2 Customer Hosted Volume Activation Guide / Deploying KMS Activation
http://technet.microsoft.com/en-us/library/ff793409.aspx

Unintentional creation of an Office KMS host is less common, because setting up an Office KMS requires a specific product key and the installation of the Microsoft Office 2010 KMS Host License Pack.

To determine whether a machine has the Office 2010 KMS Host License Pack installed and is an active Office KMS host, run a command line similar to the following:

cscript slmgr.vbs /dlv bfe7a195-4f8f-4f0b-a622-cf13c7d16864

The output of a machine which has the Office 2010 KMS Host License Pack installed will resemble the following. Key items are "Partial Product Key: GB7AH" and "License Status: Licensed", which indicate that the Office 2010 KMS host key is successfully installed and activated.

Perform the following steps to remove an Office KMS host in your environment:

1) Open an elevated command prompt.
2) Run a command similar to the following:

cscript slmgr.vbs /upk bfe7a195-4f8f-4f0b-a622-cf13c7d16864

 CAUTION: If the above command line is run without the Office activation ID ("bfe7a195-4f8f-4f0b-a622-cf13c7d16864"), all installed product keys are uninstalled, including those for Windows.

3) Run following command line again, to check the status of the Office KMS host:

cscript slmgr.vbs /dlv bfe7a195-4f8f-4f0b-a622-cf13c7d16864

4) If the Office KMS host product key has been removed, the output will be similar to that below. Key items are "This license is not in use" and "License Status: Unlicensed".

5) Using DNS Manager, in the appropriate forward lookup zone, delete the _vlmcs SRV records that exist for each machine which is not to serve as an Office KMS host.
6) See the following articles for additional information:

Deploy volume activation of Office 2010
http://technet.microsoft.com/en-us/library/ee624357.aspx

Troubleshoot volume activation for Office 2010
http://technet.microsoft.com/en-us/library/ee624355.aspx

In a previous Office Deployment Support Team Blog post, we explained how to automatically activate Office 2010 by using a customized config.xml file and setting element/property, AUTO_ACTIVATE.

This blog post will expand on that a bit and explain how to perform the same actions using an MSP file created with the Office Customization Tool (OCT).

NOTE: Adding the AUTO_ACTIVATE property to an install will trigger an attempt to activate only once. If that fails for whatever reason (i.e., proxy issues, user rights, Internet connectivity issues, etc.), another attempt will not be made and Office users will later be prompted to activate Office 2010.

The following is a simplified example of a custom config.xml file, which can be used with volume license source files for Office 2010 Professional Plus to automate the process of inputting an Office MAK product key and activating the product at install time. In addition, the installation operation will be silent, with a related verbose log file created in the %temp% directory.

These options are typical for many customers who deploy Office in an enterprise environment. For more information, see the Config.xml file in Office 2010 article at http://technet.microsoft.com/en-us/library/cc179195.aspx

1) In the above, "ABC12xxxxxxxxxxxxxxx34XYZ" is a placeholder for what should be your organization specific MAK product key for Office 2010.
2) Install Office 2010 as a user with local administrator rights by using a command line similar to the following: 

<path to Office 2010 source files>\setup.exe /config <path>\config.xml

3) Alternatively, this file can be added to the root of source files for Office 2010 (i.e., the same location of Setup.exe on a CD/DVD or network share), and running the setup executable will cause the config file to be automatically parsed at install time.

The following steps can be used to accomplish the same thing using the Office Customization Tool (OCT). In addition to providing for more advanced customization of an Office installation, adding a MAK product key to and OCT generated MSP file instead of a config.xml causes the key to be obfuscated, rather than appearing in plain text as it is in a config.xml file.

1) Run the OCT by typing setup.exe /admin at the command line from the root of the network installation point that contains the Office 2010 source files. For example, use \\server\share\Office14\setup.exe /admin.
2) In the OCT, select Licensing and user interface in the left pane, and in the right pane select Enter another product key, add your organization specific MAK Office product key in the Product key field, and other options as desired.

3) In the OCT, select Modify Setup properties in the left pane and then click the Add... button in the right pane.
4) In the Add/Modify Property Value dialog and type AUTO_ACTIVATE in the Name field. Note that property names are case sensitive.
5) In Value field, type 1, and then click OK.

6) Note that the AUTO_ACTIVATE property has been added to the MSP file and has a value of 1.

7) Click the File menu and then click Save as to save the Setup customization file. If the file is saved in the Updates folder that is part of the Office source file location/installation point, running the Office Setup.exe file will automatically detect the customization file in the Updates folder and apply the customizations.
8) As an alternative to placing the customization .msp file in the Updates folder, you can use the Setup command-line option /adminfile to specify the fully qualified path of the location of the MSP file. For example, type setup.exe /adminfile \\server\share\mychanges\custom.msp.