So, is the KMS working? I’ve popped together some things to run through to verify Things™. No glossy pictures – I’ve covered most of this in greater depth with pretty pictures in my previous KMS posts 🙂
- Verify the KMS server record(s) is available via DNS.
The KMS servers must be registered in DNS so that the KMS clients can find them. Execute the following command:
nslookup -type=srv _vlmcs._tcp
…this will return all _vlmcs records. When setting up the KMS server, you will have the option to register it in DNS. Assuming it’s a Microsoft DNS and you have the appropriate permissions, it’s a no brainer! It’s also good for tracking down rogue KMS servers…
- Check the Event logs on client and the server.
It’s a straight forward process, that should happen on every working system. The KMS client sends a request to the KMS server, found courtesy of the _VLMCS records in DNS. This generates an event ID 12288.
This is the KMS client talking to the KMS server.
The server should then respond, and in turn log an event ID 12290, detailing the machine name, licence type, activation threshold and the result. You’ll find this in the KMS log on the KMS server.
The client, should then report an event ID 12289. This is effectively a closure. Everything has worked as expected. Happy days.
- The SLMGR.VBS tool.
The SLMGe.VBS came about with VISTA, and was probably the only good thing one could about the initial release of VISTA. SLMGR.VBS has a host, hah no pun intended >_<, of options to choose from. You can manually point the KMS client at a KMS server instead of using DNS discovery for example. You can also strip out VLKs and apply a MAK, or vice versa.
Typically, for troubleshooting, you’ll be querying the KMS client for information. The top two commands I’ve used thus far are:
- slmgr.vbs /dli
- slmgr.vbs /dlv
You can run these on both KMS client and KMS server.
Thanks for reading o/