Windows Server 2008 R2 loses ability to connect to network share

Question

I could sure use some help with this one:

I've got two Windows Server 2008 R2 x64 Terminal Servers, as well as several 2003 servers (DNS / Wins / AD / DC). On the two 2008 boxes, every now and then they will get in this mode where you can't map a drive to a random server. I say random server because it's not always the same server that you can't map to.

Here is a summary of what I can and can't do:

net view \\servername Sometimes this works, sometimes it does not.
net view \\FQDN This always works.
net view \\IPAddress This always works.
ping servername Sometimes this works, sometimes it does not.
ping FQDN This always works.
ping IPAddress This always works.

I've been looking all over for a solution to this. It sure seems like Microsoft would have a hotfix by now.

The kicker to this is that it sometimes works great, especially after a reboot. It may run for 2 weeks just fine, but all of a sudden it will fail to resolve the remote server name. It will then be this way for a few days, then it might start working again. Also, while it's in the mode of not working, the other servers have no problem getting there. It's just these 2008 R2 Terminal Servers.

Setting a static entry in the Hosts file and LMHosts does not make it work. All servers have static IPs and they are registered in DNS and Wins just fine.

Here is a long thread on MS Technet of the exact same problem, but they don't have a good solution. Here is their workaround (It was from June of 2010):

Good news - a hotfix is in the works and a workaround has been identified:
Root cause is that since this is SMB1 all user sessions are on a single TCP connection to the remote server. The first user to initiate a connection to the remote SMB server has their logon-ID added to the structure defining the connection. If that user logs off all subsequent uses of that TCP session fail as the logon-id is no longer valid. As a workaround for now to keep the issue from happening you will want to have the user not logoff the Terminal Server only disconnect their sessions.

Any word from anyone out there about a solution? Any help would sure be appreciated.

Thanks, James

Solution

This sounds like a bug in the name resolution process. Since both IP and FQDN work, it seems to me that SMB is working just fine. But having hosts/lmhosts not fix the problem also suggests name-resolution problems, and problems that happen before it gets to the DNS-resolution step.

A way to verify if it is even attempting DNS resolution on those, or to see what it is attempting to resolve, is to try a packet-capture on the affected server once it gets into that state. Looking at the various permutations it tries to resolve (if any) should provide some clues.

• If it is attempting to resolve everything but the right domain, you may need to look into the DNS Suffix lists on your network connections.
• If there is no DNS traffic related to the server in question, the fault is in software somewhere before it gets to DNS resolution. That would be a Microsoft question, and keep the packet capture since they'll probably ask for one.
• If it DOES correctly resolve the servername into an IP via DNS, but still doesn't work, that points to a fault somewhere else in the stack, possibly in the antivirus or 3rd party firewall area. Or a bug that needs Microsoft's attention.

Comments

[Greg Askew]

Are you able to access\\ipaddress\share?

[JamesB]

Yes, pretty much anything I do with the IP Address or FQDN works. It's only when I use the server name itself, and that sometimes will work (might work for 2 weeks, might quit working for 2 days, then might start working again).

[JamesB]

Check out what I found... It's somewhat of an extension or followup to the original Technet article bit.ly/fNszUz. In that article they are giving the link to the MS Patch for this (support.microsoft.com/kb/2194664). I have not tried it yet but will tonight and will report back how it goes. Normally when I reboot the server everything works just fine for quite some time... so I don't know how fast I will know if it really fixed it (2 weeks or so probably).