On a Server 2012R2 virtual machine, I’ve been getting SMBClient/Connectivity error 30803 every hour for well over a year. The error references an attempt to connect to a machine that does not exist on my network, though it has an internal IP address.
The machine name looks the a random name assigned by Windows Setup. I did find the name in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CachedMachineNames\NameUserPrincipal, but even after deleting that value, the errors. continued.
Log Name: Microsoft-Windows-SmbClient/Connectivity
Source: Microsoft-Windows-SMBClient
Date: 1/20/2020 10:00:22 AM
Event ID: 30803
Task Category: None
Level: Error
Keywords: (64)
User: SYSTEM
Description:
The network connection failed.Error: {Device Timeout}
The specified I/O operation on %hs was not completed before the time-out period expired.Server name: WIN-DAVCC6T0RBM.mydomain.local
Server address: 192.168.1.237:445
Connection type: WskGuidance:
This indicates a problem with the underlying network or transport, such as with TCP/IP, and not with SMB. A firewall that blocks port 445 or 5445 can also cause this issue.
Today, I took another stab at this. I pinged the ghost machine and it resolved. I did an NSLOOKUP using my domain controller ast eh DNS server and it resolved. The IP address, however, is not assigned to an active machine.
Checking DNS on the domain controller, I discovered an entry for the bogus machine dated 9/11/2018.
My hunch is that while setting up the machine, I changed the machine’s DNS server while it still had the random name from setup and a random IP from DHCP. That registered in the DNS server and hasn’t gone away. Somehow the machine is still using this registration to try to make an SMB connection, but since the IP is wrong, it’s not working.
I’m deleting the entry from the domain controller’s DNS. We’ll see if stops the random SMB connection attempts and fixes the error.
Good New, Bad News
After deleting the old DNS entry, the 30803 errors stopped. But they were replaced with a new 30800 error every hour:
Log Name: Microsoft-Windows-SmbClient/Connectivity Source: Microsoft-Windows-SMBClient Date: 1/21/2020 1:00:03 PM Event ID: 30800 Task Category: None Level: Error Keywords: (64) User: SYSTEM Description: The server name cannot be resolved. Error: The object was not found. Server name: WIN-DAVCC6T0RBM.mydomain.local
So the machine is still trying to find the old name; it’s just not resolving any more.
Since this always happens at a few seconds past the hour, I thought to run Sysinternals ProcMon while it occurred. And there is in fact one instance of the machine name in ProcMon: called by LogParser.exe in a failed attempt to open a pipe.
LogParser is a 2005-era event log parser that is still available for download. I run it every hour from task scheduler to check for certain errors. I was able to replicate the 30800 error by running my LogParser script manually.
The script uses a for statement to cycle through a list of machine names and event log names that come from a text file. The list is very short, and the script indicates that successfully process each event log in turn:
SVR2012R2,Application
SVR2012R2,System
Obviously the list does not include WIN-DAVCC6T0RBM. Well, it does have an empty line at the end, but removing that does not help. Where in the world is “WIN-DAVCC6T0RBM” coming from?
Interesting: when calling LogParser, I set -resolveSIDs:ON. Per the LogParser documentation, “When set to ‘ON’, this parameter causes the EVT input format to perform an account name lookup for each SID value in the events being parsed, and return the account name instead of the SID alphanumerical value.” Also I see in this thread that LogParser does cache SIDs, which explains why there is only one reference in the ProcMon trace.
If I change that to -resolveSIDs:OFF, I do not get the 30800 error. So is it a SID actually in the event data that LogParser is reading that is being resolved to WIN-DAVCC6T0RBM? There are in fact some entries in the System event log dating back to when this machine had the random name WIN-DAVCC6T0RBM—and even further back, when it was WIN-MAQERIEU4OT. The Application log had already truncated events from when the machine had the old name.
Long Diagnosis, Quick Solution
So LogParser.exe, running every hour with -resolveSIDs:ON, is trying to look up and open a pipe based on old machine names in the System event log. I saved and cleared the System log. After that, no more 30800 events when running LogParser.