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.
Like most network applications, PDQ Inventory and PDQ Deploy require a healthy DNS environment. Anytime you attempt to deploy software or run a remote command or scan for Inventory attempts are made to find the correct targets by using DNS.
If you attempt to use the Diagnose option from the error make sure you verify both the main error and then the Inner Error. You usually need to expand the error message via the “more” link. The Inner Error is what we really need to determine if the problem is with DNS. For example Take this Diagnosis of a Failed To Connect to ADMIN$ Share error from a PDQ Deploy user. There are two errors. The outside or main error and then the Inner Error. (both errors in Bold). The Inner Error tells us that this is a problem with DNS.
CLR Version : 2.0.50727.4963
Comments :
E-Mail : 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 The Target Account Name is Incorrect!”
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.
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.
There can be other issues with DNS. Sometimes you can resolve a Fully Qualified Domain Name (FQDN), but you can’t resolve just the computer name. Here is an example. I have a computer called Bart. Bart resides in a different Windows Domain. Bart’s fully qualified name is Bart.vandalay.aalab.local
When I perform an nslookup of Bart, DNS fails to resolve. Yet when I use the FQDN it resolves just fine. This is most likely because I don’t have my DNS Suffix search order set correctly. Since I try to resolve bart from a different domain, by default my computer will append the same DNS suffix so when I 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)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
Here are some good articles to refer to when it comes to troubleshooting DNS on Windows servers:
