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:
Add each DNS domain suffix to the following multistring Registry value:
DnsDomainPublishList in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\
CurrentVersion\SoftwareProtectionPlatform
After
changing the value, restart the Software Licensing Service, after which
the KMS host will create the SRV RRs. Note that this key has changed
from the original location in Windows Vista and Windows Server 2008,
where the location was HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL.
To
verify that the procedure has been successful, check the Application
event log on the corresponding KMS host. Event ID 12294 will be
displayed when the KMS host has successfully created the SRV RRs; Event
ID 12293 will be displayed when the process is unsuccessful.
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:
Uninstall the KMS host key by running the following command:
slmgr /upk
Install the default KMS or your MAK by running the following command:
slmgr /ipk [KMS Client or MAK]
Delete the necessary records from your DNS, or wait for DNS scavenging to delete the record for you.
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.
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.