As I’ve described in the previous two installments, the KMS is a pretty simple and straight-forward service. When you think about, this makes sense because the only thing that it does is activate clients.

So how do you track what the KMS is doing and identify any issues? The first way is a vbscript located in %systemroot%system32 named slmgr.vbs. This little script is the main way to interact with the KMS and the activation client. Running this script with –dli as an option will list the activation information for the local system; if the local system is a KMS, then will also list KMS related data including the number of clients that it has activated in total. Remember that this number is important because Vista clients won’t activate unless the KMS has already activated at least 25 clients and Server 2008 clients won’t activate unless 5 other systems have already been activated. The following screenshot shows the output of slmgr –dli on a KMS:

slmgr.vbs –dli Results on a KMS

Of note are the following:

VOLUME_KMS_C_channel — The type of license key that was used to activate the system. For a KMS, this also indicates what type of clients it can activate, see Windows Activation: The KMS for details.

License Status — Indicates whether the local system has been activate or not.

Current Count — The number of client systems already activated.

DNS publishing enabled — Indicates whether this KMS system is publishing its SRV record in DNS.

slmgr –dlv displays the same basic information with some extra thrown in. This in shown in the next screenshot:

slmgr.vbs –dlv Results on a KMS

The two above commands also work on clients and show the same information minus the KMS specific items.

Both the KMS server and client add event log entries to track activations and activation requests. For the KMS server, there is a dedicated log view called Key Management Service located under Application and Services LOGs in the Event Viewer:

The KMS Event Log

The KMS will add an entry to this log every time it receives a request for activation. They will look like the following:

KMS Event Log Entry for an Activation Request

The first field in the info section (marked by the red arrow), is the success/failure code; 0x0 is success.

For clients, two events will be placed into the standard Application Event Log with EventIDs of 12288 and 12289 and provider name of Microsoft-Windows-Security-Licensing-SLC. 12288 indicates a client request and which KMS server the request is being sent to (blacked out):

Client Event Log Entry for an Activation Request

12289 indicates a reply from the KMS, the success/failure code (marked by the red arrow below) is the first field in the info section and is the same code listed by the event entry on the server side:

Client Event Log Entry for an Activation Request Result

There are a handful of common error codes, the full list is available in the Volume Activation 2.0 Operations Guide in Appendix 2.

That’s the bulk of it. Like I said at the start, its a simple service that does only one thing: activate clients.