Help Center


Target computer name mismatch


The name of the target computer doesn't match the name being used to connect to it.  Windows security requires that the name of the computer used to connect matches the name of the computer itself.

Possible Causes

Most likely caused by a DNS error causing the name to resolve to the wrong computer.

For example the path \\host1\ADMIN$ is trying to connect to a computer named host2 because DNS returns the wrong IP address for host1.

We have also seen this error occur when a target machine doesn't recognize Domain credentials because the target computer has lost it's trust relationship with the Domain.

Recommended Fix

Ensure that the target computer is the correct computer.  Verify by using a ping or nslookup.

If you are using Windows DNS, consider scavenging your old records. You can do this by running

 dnscmd <ServerName> /startscavenging 


or from the DNS MMC right click on the DNS Server and select "Scavenge Stale Resource Records".

If credentials you are using are Domain credentials, verify that the target hasn't lost it's trust relationship. (try connecting via Windows Explorer to \\TargetComputerName\ADMIN$). If credentials have been lost you will need to rejoin the target computer to its respective domain. You can also use the utility NETDOM, from Microsoft, if it is available.

You may also need to restart your DNS Client service on your Console computer. To do this from cmd.exe run

sc stop dnscache

and then run

sc start dnscache

This will clear out your DNS cache and force new lookups to pull from DNS. 

Was this article helpful?
4 out of 4 found this helpful
Have more questions? Submit a request


  • 0

    Something similar happened to me.

    The client was connected via VPN. I tried some deployments. Sometimes they would error out, sometimes they would fire off correctly and finish. I just kept redeploying until the instal didn't error out.

    I think I lost connection during one of those deployments, because at some point, the client went offline according to PDQ Inventory, and wouldn't come back online.

    This morning, I brought the client (a laptop) into the office, it picked up an IP on a different subnet, and inventory wouldn't recognize the client as having this new IP. The old VPN IP was still listed. I checked DNS, and the A and PTR were both correct for this client. I deleted it from Inventory and rescanned AD to pick it up, but it still showed the old IP.

    I think an ipconfig /flushdns on the client is what finally fixed it. I deleted it from Inventory again, and resynced Inventory with AD, and the client showed up correctly, online, with the new IP address.

    I've got a handful of other laptops in this state, and I'm hoping all it takes is an ipconfig /flushdns for them, too.

Article is closed for comments.