Tracking Your Licenses with the Key Management Service (part 2) - Configuring DNS to Let KMS Clients Find the KMS Server

5. Configuring DNS to Let KMS Clients Find the KMS Server

If your network environment has Dynamic Domain Name System (DDNS) and allows computers to publish services automatically, deploying a KMS will automatically create the needed service resource records in DNS. If the organization has more than one KMS host or the network does not support DDNS, additional configuration tasks may be necessary.

You can verify whether the automatic creation succeeded by performing the following query targeting your DNS server:

NSLOOKUP -type=SRV _VLMCS._TCP

Your output should look similar to this:

Server: dnsOl.domain.local
Address: 192.168.0.1
_v1mcs._tcp.domain.1oca1  SRV service location:
          priority     = 0

weight = 0
          port = 1688
          svr hostname = kms.domain.local
kms.domain.local internet address = 192.168.0.2

If your environment does not support DDNS, you must either manually create your Service Resource Records (SRV RRs) in order to publish the KMS host, or you must point all your clients to the KMS server manually. To avoid failed DNS publishing events in your event log, you should also disable auto-publishing using the slmgr.vbs /cdns command-line option.

Manually created SRV RRs can coexist with SRV RRs that KMS hosts automatically publish in other domains for which DDNS is available. However, you must maintain all records to prevent conflicts and incidents.

Use the following settings on your DNS server if it doesn't support DDNS:

Service: _VLMCS

Protocol: _TCP

Port number: 1688

Service host: FQDN of KMS host

If your organization uses a non-Microsoft DNS server, the needed SRV RRs can be created as long as the DNS server is compliant with Berkeley Internet Name Domain (BIND) 8.2 or higher. Consider authorizing your KMS server so that it can perform RR updates. If this isn't possible, you should use the following parameters to register the service manually:

Name: _v1mcs._tcp

Type: SRV

Priority: 0 (or other priority value)

Weight: 0 (or other weight value)

Port: 1688

Hostname: FQDN of KMS host

5.1. Using Multiple Key Management Servers In Your Environment

By default, KMS clients query DNS for KMS service information. The first time a KMS client queries DNS for KMS service information, it chooses a KMS host from the list of SRV RRs that DNS returns. If the client is Vista or Server 2008, the KMS host is picked randomly, and if the client is Windows 7 or Windows Server 2008 R2, the priority and weight parameter provided in the DNS record are taken into account. Establishing KMS host priority groupings and weighting within each group allows you to specify which KMS host the clients should try first and balances traffic among multiple KMS hosts.

You can add priority and grouping under the DnsDomainPublishList Registry key, which you can find under:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\
SoftwareProtectionPlatform

If the KMS host that a client selects does not respond, the KMS client removes that KMS host from its list of SRV RRs and randomly selects another KMS host from the list. When a KMS host responds, the KMS client caches the name of the KMS host and uses it for subsequent activation and renewal attempts. If the cached KMS host does not respond on a subsequent renewal, the KMS client discovers a new KMS host by querying DNS for KMS SRV RRs.

5.2. Configuring DNS In a Multiple-Domain Situation

By default, the KMS host registers itself in the DNS domain to which it belongs. If there are more than one DNS domain names in which the KMS host must be registered, a list of DNS domains can be created for a KMS host to use when publishing its SRV RR. To automatically let KMS publish its SRV RRs in multiple DNS domains, take the following steps:

6. Uninstalling KMS

When you want to decommission your KMS server or migrate the KMS functionality, you have to uninstall your KMS. To do so, take the following steps:

7. Troubleshooting the KMS and the KMS Client

When troubleshooting KMS host and KMS client activation problems, you should start checking the Windows event log for KMS-related errors. The errors are displayed by error codes, but by using the Windows Activation Client tool, slui.exe, you can translate them back to understandable error messages. The following syntax shows how to use slui.exe to translate an error code back to an understandable error message:

slui.exe 0x2a <Error Code>

For example, using SLUI.exe 0x2A 0xC004C008 launches the dialog box shown in Figure 2.

Figure 2. Windows Activation Client error code help

You can now use this error message to further troubleshoot your problem, by using it as a search term in your favorite search engine, for example. You can also use the VAMT to help you troubleshoot activation errors, because it provides you with detailed information about activation status.

8. Configuring KMS for Activation of Office 2010

Before you can extend your KMS server to also support activation of Office 2010 clients, you'll need to install the Microsoft Office 2010 KMS host license pack and your KMS server must already be the latest version—which is also a prerequisite in order to activate Windows 7 and Windows Server 2008 R2.

The Microsoft Office 2010 KMS Host License Pack consists of an executable called KeyManagementServiceHost.exe. When running the KeyManagementServiceHost.exe file, the KMS server functionality will be extended by installing the host license files so that activation of Microsoft Office 2010 will be possible. The KeyManagementServiceHost installer will also ask you to supply your Microsoft Office 2010 KMS host product key, so that the KMS server can start to activate Office 2010 products. The activation count threshold for Office 2010 is 5.

You can verify whether the Office 2010 KMS instance is working correctly by using the slmgr .vbs script. The only difference compared to using slmgr.vbs on a normal KMS instance is that you now have to provide the Activation ID (which is bfe7a195-4f8f-4f0b-a622-cf13c7d16864). The following command shows detailed license information for the Office 2010 KMS instance:

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

Look for the License Status line in the output of this command and check that it states Licensed.

Microsoft Office 2010 Professional is by default equipped with a KMS key, so if the KMS server and DNS are set up correctly, any Microsoft Office 2010 professional installation will be able to find the KMS server and activate.

9. Monitoring the KMS Servers

So that you can monitor your KMS servers, Microsoft provides management packs for Microsoft Operations Manager (MOM) 2005 and System Center Operations Manager (SCOM) 2007. These management packs constantly monitor your KMS services and report problems to the centralized Operations Manager console; then you can take action.

The Key Management Service management pack monitors the status of the KMS service running on the KMS host. It can monitor DNS publishing and as well as Low Activation Count. Informational, warning, or critical alerts appear in SCOM.

10. Using Asset Intelligence Reports in SCCM 2007

System Center Configuration Manager provides the ability to report on client access licenses (CALs) using its Asset Intelligence feature. Before you can enable CAL data collection, you must make some changes in your environment:

• You must enable success logon event logging using Group Policy on all clients for which you want to receive CAL status.

• You must extend the configuration.mof file so that the corresponding WMI data classes will be inventoried.

At this point, the CAL reports can be run using the reporting functionality within System Center Configuration Manager.