Troubleshooting KMS Activation - Part 1, the client
Windows activation is simple and straightforward if you understand the components. I have had a few customers that stumbled when getting a KMS online and in every case it has been an issue with name resolution, network connectivity, or they simply did not understand how to use the keys. Activation is designed to help you with deployments and sustain your environment even in the event a key gets lost. KMS is the simplest of all the activation methods because you only need to worry about putting a key in one machine. You can then deploy new machines without having to ever worry about keys unless your device will be off the network for more than 6 months.
This is the first of a two part series to break down KMS troubleshooting in to a process that should help identify exactly what is at fault. I don't want to mislead or instill fear to those who are just starting out - the process is normally simple by design. However, for those who have run in to trouble, I'd like to publish a guide that will help you isolate and correct the issue you've encountered without spinning your wheels. Part 2 will be published next week with a focus on troubleshooting the server.
Part 1, Troubleshooting The Client
Let's assume you are a consultant from outside the organization and you know nothing about the environment, server or workstation. The first thing you'll want to do is understand how the client was built. It is possible the machine is retail or OEM, and neither of those use KMS for activation. Any of the "Home" versions, Basic, Premium, or Ultimate, are retail builds and do not use volume licensing methods at this time. Windows XP observed the same rules, neither XP Media Center or XP Home Edition were not capable of using the VLK. If you are using the OEM media such as a recovery DVD you would see the machine come online "pre-activated". This is a result of a marker in the BIOS that corresponds with the OEM media. Note: if this marker is not present, such as the case of "naked" OEM workstations, then KMS is not an option for activation. So we are assuming the machine was built using volume media and is capable of being a KMS client. You can test this to be sure by running a the command line and looking for the Name and Description. Right click on the command line icon on the start menu and select "Run As Administrator". Then type -
c:\windows\system32\cscript slmgr.vbs -dlv
My machine returned this output, I replaced any sensitive data with <>:
Software licensing service version: 6.0.6000.16386
Name: Windows(TM) Vista, Enterprise edition
Description: Windows Operating System - Vista, VOLUME_KMSCLIENT channel
Activation ID:<>
Application ID:<>
Extended PID:<>
Installation ID:<>
Partial Product Key:<>
License Status: Licensed
Volume activation expiration: 259060 minute(s) (179 day(s))
Key Management Service client information
Client Machine ID (CMID):<>
DNS auto-discovery:<>
KMS machine extended PID:<>
Activation interval: 120 minutes
Renewal interval: 10080 minutes
This also provided some insight in to resolving the KMS name. If no server name is given for the "DNS auto-discovery" field, you already know there is an issue. This may also occur if you did not run the command prompt as an administrator.
Next you will want to ensure you are able to contact the server. In the same command prompt, run some basic diagnostics to ensure you are able to resolve names and that you know which DNS servers/zones your machine is querying.
Retrieve your networking details, specifically the default DNS suffixes and search order -
ipconfig /all
My machine returned this output, I replaced any sensitive data with <> and am including only the first section:
Windows IP Configuration
Host Name . . . . . . . . . . . . : migreene-nc8430
Primary Dns Suffix . . . . . . . : <>
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : <>
System Quarantine State . . . . . : Not Restricted
I am assuming you know/understand basic network connectivity troubleshooting and will be able to diagnose any of those issues should they exist. The address should be valid, ping the DNS server, ping the local hostname, etc. Take note of the Primary DNS suffix such as "domain.edu" and the DNS Suffix Search List. If the wrong name is given, you know there is an issue with addressing and the wrong suffix is being assigned. If no name is given, there may be an issue or it is possible that no suffix is being given and the environment is relying on the DNS server to resolve FQDN's. If you are not providing a DNS suffix to clients either manually, via the domain, or via DHCP, you will want to hard-code your clients to the KMS.
This next step is as important as the first. Make sure the client can retrieve the SRV record. You may even find this step should be taken first, and then work backwards once you know that DNS is in order. In this case I have given an example, "servername.domain.edu". If you were actually troubleshooting you would use a known hostname, or the KMS hostname -
nslookup
> servername.domain.edu
Server:<>
Address:<>
Non-authoritative answer:
Name:<>
Address:<>
This tells you which DNS server your client is querying and whether it is responding. You should have returned a valid IP. If not, you now know the issue is on your DNS server or client configuration. Now query for the SRV record while still in nslookup -
>set q=srv
>_vlmcs._tcp
Server:<>
Address:<>
Non-authoritative answer:
_vlmcs._tcp.<> SRV service location:
priority = 0
weight = 0
port = 1688
svr hostname = <>
<> internet address = <>
If you are not able to resolve this SRV record, and you have not hard-coded a client to a KMS, the machine will not have enough information to find a KMS and activate. If you need to publish an SRV record manually to an existing forward lookup zone, instructions are published here -
Finally, it is a good idea to attempt an activation manually to see if any actionable error messages are returned. The command line can be run from the same elevated command prompt -
c:\windows\system32\cscript slmgr.vbs -ato
The result should be -
Activating Windows(TM) Vista, Enterprise edition (<>) ...
Product activated successfully.
If the activation fails, you may get actionable feedback such as notification that the KMS does not have at least 25 active clients, or the record could not be found in DNS. If an error code is returned you can find more information by running -
c:\windows\system32\slui.exe 0x2a 0x<error code>
If everything appears to be working on the client but the machine will still not activate, the issue may be some type of failure within the imaging process. For best results, sysprep should always be used when an image is being created for the purpose of deployment. One other possibility is the case of a "naked pc". If the machine was acquired from an OEM and did not have Windows installed, you should leverage MAK for activation instead of KMS. Windows volume licensing requires that the OS come from the OEM, and then an upgrade is performed to volume media for mass distribution via imaging. Key Management Service is not available if the machine was originally sold as "naked". My recommendation would be to use MAK and distribute it through either your image or the VAMT.
You may find other faults at the workstation level. For example, if there was a host based firewall preventing outbound traffic the client would not be able to contact the server (port 1688). It's also possible that some drive "freezing/thawing" tool is resetting the machine to a state before activation. New versions of such tools should allow exceptions for activation just as they would have been allowing for other OS components.
I can't possibly list every potential obstacle here but if I have missed something you faced and resolved through some other workflow, please let me know and I will post an update. Remember, on any new machine you have 30 days plus 2 -rearms using slmgr.vbs for a total of 90 days to bring a new install online, and for existing KMS clients you have 6 months to resolve any new issues. This provides a large window for troubleshooting and resolving any client-side difficulties you might encounter.
Once a KMS is online, you can resolve the name, and connect to it, it really does make imaging simple. There is no longer a need to contact licensing administrators to find a key or store it somewhere in a file. You can simply roll out new installations and by default they will look to the KMS and activate without the user or deployment specialist ever needing to worry about keys or activation. Above all, remember that volume activation was designed to create a process for remediation when a volume key is lost, without needing to redeploy existing machines.
Technorati tags: Microsoft, Windows_Vista, Activation, Key_Management_Service
Comments
Anonymous
January 01, 2003
its very nice post www.suwwa.comAnonymous
January 01, 2003
Thank you very much for the great information. Thanks <p><a href="http://www.tacticalpantsupply.com/" title="511 pants">511 pants</a></p>Anonymous
January 01, 2003
I would test out VAMT (Volume Activation Management Tool) for pushing out MAKs, or embed the MAK in your image. In either case, you will need to ask your licensing administrator for permission and you will most likely want to request additional activations for your MAK to compensate those you will be using. This is something I would recomend only as a temporary fix until you have at least 25 physical machines running Vista.Anonymous
January 01, 2003
Hello
I ran the NSlookup against our KMS server and was able to get ip address for that server, but our computers fail to activate themselves automatically every6 months and we have to run the slmgr.vbs /ato on them manually for activation.
Could you tell me what seems to be the problem?
ThanksAnonymous
November 13, 2007
The comment has been removedAnonymous
March 08, 2008
Mesi http://www.marasti.cn/horse degli.