A bit more on DNS suffix related things. This pretty much is relevant with any DNS SRV Record resolving issues, but this time involves an issue with a standalone (not domain joined) client machine failing to find KMS (Key Management Services) server location information from DNS.
I’m not going to describe how KMS works, but in short, it is a server application which activates client machines (can be workstations or servers) and applications on them without the need to travel the internet over to Microsoft activation services. KMS clients try to find the location of a KMS server by querying DNS for a service record (SRV RR) for a service called _VLMCS._tcp. When found, the answer contains the name of the KMS server which the client then contacts with the activation request.
I came across an activation failure when activating a standalone machine where everything seemed to be configured properly, no firewalls blocking traffic, DNS connectivity issues or anything. When trying to activate with
cscript.exe slmgr.vbs /ato
the system responded with the following obscure error message with no indication on what is wrong.
Error (0x8007007B): The filename, directory name, or volume label syntax is incorrect. (SWbemObjectEx)
…and more in the Application Log:
License Activation (slui.exe) failed with the following error code:
After checking that things are running normally on the KMS Server, double checking that the proper KMS Product Key is in fact installed on the client machine and ruling out connectivity issues I manually set the KMS server name by saying
cscript.exe slmgr.vbs /skms <kms_server_name:port>
Having done that, activation succeeded. This pointed out that it had to be a DSN issue. It turned out that the machine in question had no Primary DNS Suffix or a Connection Specific DNS Suffix configured at all. After configuring DNS Suffix on either one of those locations, the machine activated successfully.
If configuring DNS Suffix is for whatever reason not possible there are a few ways to solve the problem. You can set the name of the KMS Server or the domain manually. Setting the server is already mentioned above, and to set the domain in which to look for the KMS SRV record can be done with the following.
cscript.exe slmgr.vbs /skms-domain <domain_name>
Doing either of the above will result in a working DNS query and a successful activation.
To sum up, for KMS auto-discovery to work make sure the machine’s DNS Suffix is configured properly and that the SRV Record is found in the same zone.
For what it’s worth, a machine doing a SRV DNS query has to know the domain (or zone in DNS terms) in which to look for. This can be done by either specifying the domain name within the query itself (in this case telling that to the KMS client software with slmgr.vbs) or by configuring a Primary DNS Suffix or a Connection Specific DNS Suffix (or a list of those) for the machine.
In hindsight all this is pretty basic DNS functionality and obvious. Although in this case with the not so descriptive error message it wasn’t so straight forward to figure out.
All the above applies to all SRV resolving and of course to regular name resolution as well.
While doing some research for writing this I found out that this matter (along with other possible causes) is explained quite thoroughly in this support article: http://support.microsoft.com/kb/929826.