I first noticed this issue in https://social.technet.microsoft.com/Forums/en-US/cb4ccc69-d153-4781-9984-fb227d887baf/dcdiag-errors-failing-advertising-and-more-tests-appear-to-be-due-to-flatname-issues?forum=winserverDS
I'm using a server called ACMEDC1, trying to connect to an SMB share on ACMESRV1, which I've called "testshare".
Connecting to \\x.x.x.x\testshare (IP address) works
Connecting to \\ACMESRV1.acme.local\testshare works
Connecting to \\ACMESRV1\testshare fails with the error "Windows can't find '\\ACMEDC2\FILESHARE'. Check the spelling and try again."
I can connect to many other SMB shares (not all) from ACMEDC1 using the hostname, and most other clients have no issues connecting to ACMESRV1 SMB shares via the hostname.
From ACMEDC1, I can do a lookup of ACMEDC2 with nbtstat - it will resolve to an IP address and then it appears in the cache (so "nbtstat -a ACMEDC2" and "nbtstat -c" work). Likewise, netlookup works, and so does nmblookup (or whichever tool it was that does WINS lookups)
I've tried using message analyzer and I've found that no SMB packets leave the PC when using the failed "\\ACMESRV1\testshare". So it looked like something to do with the SMB client itself. When I do try to connect to the share, nothing ordinarily appears in the SMBclient logs. However, if I HAMMER (i.e. press enter around 20 times), I run into a few of these:
Log Name: Microsoft-Windows-SmbClient/Connectivity
Source: Microsoft-Windows-SMBClient
Date: 28/10/2015 12:44:00 p.m.
Event ID: 30800
Task Category: None
Level: Error
Keywords: (64)
User: SYSTEM
Computer: ACMEDC1.ACME.LOCAL
Description:
The server name cannot be resolved.
Error: The object was not found.
Server name: ACMESRV1.
Guidance:
The client cannot resolve the server address in DNS or WINS. This issue often manifests immediately after joining a computer to the domain, when the client's DNS registration may not yet have propagated to all DNS servers. You should also expect this event at system startup on a DNS server (such as a domain controller) that points to itself for the primary DNS. You should validate the DNS client settings on this computer using IPCONFIG /ALL and NSLOOKUP.
The servername in the above log has also appeared as "ACMESRV1.A", ACMESRV1.AC", ACMESRV1.ACM"... none of which I've entered myself. So the server above has the hostname followed by the period - which is why it's not resolving. I'm not even sure if that's the reason it is appearing, or whether it's simply a result of me trying to investigate. When trying to replicate that error, I'm not able to by hammering the "enter" button again.
If I intentionally put in the wrong server name (such as \\ACMESRV1234234), it will immediately create one of the 30800 events such as above.
If I use process monitor, I get a number of TCP Accept / TCP Receive entries - despite the fact that I can't pick anything up on Message Analyzer:
TCP Accept ACMEDC1.acme.local.microsoft-ds -> ACMESRV1.acme.local:51096 SUCCESS
TCP Receive ACMEDC1.acme.local.microsoft-ds -> ACMESRV1.acme.local:51096 SUCCESS
TCP Send ACMEDC1.acme.local.microsoft-ds -> ACMESRV1.acme.local:51096 SUCCESS
I then get four CreateFile events for EXPLORER.EXE:
\\ACMESRV1\TESTSHARE DISCONNECTED
\\ACMESRV1\PIPE\SRVSVC DISCONNECTED
\\ACMESRV1\PIPE\SRVSVC DISCONNECTED
\\;RdpDR\;:2\ACMEDSRV1\PIPE\SRVSVC BAD NETWORK NAME
Initially I thought that this could have been the other DNS server's fault - ACMEDC2, which ACMEDC1 is using for lookups. But the DNS lookups are fine when required (normally it seems to grab it from the cache).
I think the key problem is this one:
\\;RdpDR\;:2\ACMEDSRV1\PIPE\SRVSVC BAD NETWORK NAME
From searching, it appears that this refers to the RDP provider or something to that effect. No idea why this comes up at all. The network providers are the same on both ACMEDC1 and ACMEDC2, so it's not a configuration issue there. I just don't get it, and not sure where to go next.
I'm using a server called ACMEDC1, trying to connect to an SMB share on ACMESRV1, which I've called "testshare".
Connecting to \\x.x.x.x\testshare (IP address) works
Connecting to \\ACMESRV1.acme.local\testshare works
Connecting to \\ACMESRV1\testshare fails with the error "Windows can't find '\\ACMEDC2\FILESHARE'. Check the spelling and try again."
I can connect to many other SMB shares (not all) from ACMEDC1 using the hostname, and most other clients have no issues connecting to ACMESRV1 SMB shares via the hostname.
From ACMEDC1, I can do a lookup of ACMEDC2 with nbtstat - it will resolve to an IP address and then it appears in the cache (so "nbtstat -a ACMEDC2" and "nbtstat -c" work). Likewise, netlookup works, and so does nmblookup (or whichever tool it was that does WINS lookups)
I've tried using message analyzer and I've found that no SMB packets leave the PC when using the failed "\\ACMESRV1\testshare". So it looked like something to do with the SMB client itself. When I do try to connect to the share, nothing ordinarily appears in the SMBclient logs. However, if I HAMMER (i.e. press enter around 20 times), I run into a few of these:
Log Name: Microsoft-Windows-SmbClient/Connectivity
Source: Microsoft-Windows-SMBClient
Date: 28/10/2015 12:44:00 p.m.
Event ID: 30800
Task Category: None
Level: Error
Keywords: (64)
User: SYSTEM
Computer: ACMEDC1.ACME.LOCAL
Description:
The server name cannot be resolved.
Error: The object was not found.
Server name: ACMESRV1.
Guidance:
The client cannot resolve the server address in DNS or WINS. This issue often manifests immediately after joining a computer to the domain, when the client's DNS registration may not yet have propagated to all DNS servers. You should also expect this event at system startup on a DNS server (such as a domain controller) that points to itself for the primary DNS. You should validate the DNS client settings on this computer using IPCONFIG /ALL and NSLOOKUP.
The servername in the above log has also appeared as "ACMESRV1.A", ACMESRV1.AC", ACMESRV1.ACM"... none of which I've entered myself. So the server above has the hostname followed by the period - which is why it's not resolving. I'm not even sure if that's the reason it is appearing, or whether it's simply a result of me trying to investigate. When trying to replicate that error, I'm not able to by hammering the "enter" button again.
If I intentionally put in the wrong server name (such as \\ACMESRV1234234), it will immediately create one of the 30800 events such as above.
If I use process monitor, I get a number of TCP Accept / TCP Receive entries - despite the fact that I can't pick anything up on Message Analyzer:
TCP Accept ACMEDC1.acme.local.microsoft-ds -> ACMESRV1.acme.local:51096 SUCCESS
TCP Receive ACMEDC1.acme.local.microsoft-ds -> ACMESRV1.acme.local:51096 SUCCESS
TCP Send ACMEDC1.acme.local.microsoft-ds -> ACMESRV1.acme.local:51096 SUCCESS
I then get four CreateFile events for EXPLORER.EXE:
\\ACMESRV1\TESTSHARE DISCONNECTED
\\ACMESRV1\PIPE\SRVSVC DISCONNECTED
\\ACMESRV1\PIPE\SRVSVC DISCONNECTED
\\;RdpDR\;:2\ACMEDSRV1\PIPE\SRVSVC BAD NETWORK NAME
Initially I thought that this could have been the other DNS server's fault - ACMEDC2, which ACMEDC1 is using for lookups. But the DNS lookups are fine when required (normally it seems to grab it from the cache).
I think the key problem is this one:
\\;RdpDR\;:2\ACMEDSRV1\PIPE\SRVSVC BAD NETWORK NAME
From searching, it appears that this refers to the RDP provider or something to that effect. No idea why this comes up at all. The network providers are the same on both ACMEDC1 and ACMEDC2, so it's not a configuration issue there. I just don't get it, and not sure where to go next.