The errors are many:
Target computer name mismatch
Failed to connect to ADMIN$ share
The target account name is incorrect
The filename, directory name, or volume label syntax is incorrect.
These errors don’t necessarily mean that name resolution via DNS is broken but the chances are good that DNS needs some attention. The only exception is the error “Failed to connect to ADMIN$ share” which can be caused by a number of problems not related to DNS.
Maintaining a healthy DNS is an important task for sys admins. Most network applications (including PDQ Deploy and PDQ Inventory) require a healthy DNS to run optimally.
Diagnosing a DNS Problem
When you use the diagnose option from the error, you’ll need to identify the main error and the inner error. To see the inner error you may need to expand the error message. The inner error is what will help you determine if the problem is with the DNS.
For an example, we’ll look at the diagnosis of a Failed to Connect to ADMIN$ Share error. In bold are both the main (or outside) error and the inner error.
CLR Version : 2.0.50727.4963
Comments :
E-Mail :
Error Type : AdminArsenal.Runner.FileException
Memory : 8 GB (5 GB free)
Product : PDQ Deploy
Subject : PDQ Diagnose Report
Version : 7.0.0.0
Windows : Microsoft Windows 7 Enterprise (6.1.7600.0)
Failed to connect to ADMIN$ share
Computer Name: PC-2105
File Path: \\PC-2105\ADMIN$
Installer: Crystal 9
AdminArsenal.Runner.FileException
at AdminArsenal.Runner.RemoteRunner.TestAdminShareRead()
at AdminArsenal.Runner.RemoteRunner.Connect()
at AdminArsenal.Runner.RemoteRunner.Process()
System.IO.IOException
...That error Logon Failure: The target account name is incorrect means that, in this case, PDQ Deploy tried to deploy Crystal 9 to the computer PC-2105 but DNS reported a “bad” IP Address for this computer. DNS resolved PC-2105 to PC-2105.mydomain.com with IP Address 10.5.31.101. It turns out, however, that DNS resolved to an IP Address that was actually being used by another computer. When PDQ Deploy attempted to access \\PC-2105\ADMIN$ it failed because Windows security on the remote computer basically said “Hey, I am using IP Address 10.5.31.101 but my name isn’t PC-2105. Therefore you can’t come in because of a Target Name Mismatch!”
The user who reported this had to clean up some old records in DNS. Once he cleaned them up the deployment of Crystal 9 went off without a hitch.
Cleaning Up Old Records in Your DNS
A common way to clean up old, or stale, records in DNS is to perform a scavenge. In Windows DNS you can initiate a scavenge by right clicking on the DNS Server in the DNS Manager tool (from Microsoft) and selecting Scavenge Stale Resource Records. Also, you may want to enable the automatic scavenging (this is disabled by default in Windows DNS).
Other DNS Related Issues
What if you can resolve a Fully Qualified Domain Name (FQDN), but you can’t resolve just the computer name. For example, let’s say you have a computer called Bart. Bart resides in a different Windows Domain. Bart’s fully qualified name is Bart.vandalay.aalab.local but when you perform a nslookup of Bart, DNS fails to resolve. Yet, when you use the FQDN it resolves just fine.
This is most likely because your DNS suffix search order is not set correctly. When you try to resolve Bart from a different domain, by default my computer will append the same DNS suffix so when you type in nslookup bart it is actually sending nslookup bart.aalab.local, which is wrong. By changing the DNS Suffix search order it will actually try:
nslookup bart.aalab.local (which won’t resolve so DNS tries the next suffix)
nslookup bart.vandalay.aalab.local (which does resolve)
Nbtstat
Another tool that helps to determine what machine really is on the other end of that IP address is nbtstat. "Nbtstat -A X.X.X.X" is the equivalent of walking up to a house knocking on the door and asking who lives there. The post office (DNS) may have an old address but the answer at the door will give you the current owner of the address. Example of nbtstat results (Test81 is at address 10.0.0.153):
GPO (Group Policy)
DNS Suffixes are configured from your DHCP server, Group Policy (GPO) via AD or at the actual connection on your machine. To set the correct suffix search via GPO you change the DNS Suffix Search List policy at: Computer Configuration/Policies/Administrative Templates/Network/DNS Client
Final Notes
Here are a few good articles you can refer to when troubleshooting DNS on Windows Servers:
