cannot browse shares by netbios name

Are you using a static IP address?

What the message is displayed when using "\\server1"?

I had a similar problem once (but had static ip) and fixed the issue by enabling netbios over tcp/ip
temp.JPG

what error you are getting

attatched is screenshot of error.  All of the servers are static IP addresses, only 3 of my 8 2008 R2 servers are having this problem and none of my 2008 or 2003 servers have this problem.  When I use "net view \\server1" it returns System error 53 has occurred.  NetBIOS is enabled over TCP/IP.
ee1.jpg

Could this UNC issue be a DNS issue even though its only happening on that machine?

Can you access the UNC path from the local machine?

Also, if you do a "ping -a x.x.x.x" does it resolve the hostname? And are the computer all on the same domain and or network?

Meant to include in last comment to do that ping test from a different machine to the machine your having issues with.  I would almost bet if you added that ip="servername" to host file on a machine trying to connect to the machine having issues it might work.  But I wouldn't consider that a fix, just will help tell us whats causing the issue.

Every machine can ping each other by IP address, NetBIOS name, and FQDN.  They all resolve correctly.  From a 2008 R2 server with the problem, ping -a x.x.x.x gives the FQDN, flushing the DNS cache still returns the FQDN.  All servers tested (both with and without the problem) yield the same results.  

I have edited the hosts file and it does not change the problem.  Also I have disabled NetBIOS over TCP/IP on both the target server and the 2008 R2 server and I get a different error.

At this point I don't think it is a DNS or NetBIOS name issue.  Is there anyway I can change the Zones of this question?  I think this should be a SMB and Windows 2008 R2 problem.  

More information, might help.  The 2008 R2 servers having this problem are terminal servers.  The 2003 server is the location for the majority of the mapped drives.  All of the servers are on the same domain on the same network and subnet.  The logon script is what maps the drives.  After a reboot it works until it breaks and any subsequent user that logs on cannot map drives by the NetBIOS name as it is configured in the logon script.  Any user that still has the drives mapped continue to work.  

As a workaround I am changing the logon script to use FQDN instead of the NetBIOS name.  If/When the problem reoccurs, I will update this question.  

Real fast

https://www.experts-exchange.com/questions/25047812/Windows-7-Stops-Connecting-to-Share-Drives.html 

I just noticed another thread with a similar problem, but its the client that can't connect to the servers without reboot ever once in a while

to change zone you will have to click request attention in the body of your original question on the lower right corner. That creates another question in community support though, in the reason block tell them whats going on.

On the Win2008, at the command prompt, type nbtstat -n.

The local NetBIOS names table for the WINS client computer is listed. Verify that each name indicates Registered in the Status column.

For cases where the name is shown to be either Registered or Registering, you can type nbtstat -RR to release and refresh registration of the local NetBIOS names of the client with WINS.

If you find that NetBIOS names are not registering verify your WINS service service is running (or installed); it's installed as "Windows Internet Name Service (WINS)" located @ %windir%\System32\wins.exe.  Once the service is installed/running, verify your DHCP server Scope Options have a entry for 044 WINS/NBNS Servers which points to the IP('s) of your WINS server.  If you are using static IP's verify each node has the WINS server manually specified.

NetBIOS name was registered and re-registering them did not resolve the issue.  

I've seen similar file sharing issues when a specific version of Symantec Endpoint protection is installed on file servers.  What are you using for Antivirus protection?

Also, try running TCPView on the client and server.   You should see a connection being established from both the TS and file server.  May give you some additional details.

Thanks help on zone changing Fixforyou, All of my automatic services are started, and I don't have any errors in the event log that indicate any kind of network problem.  I can't just restart services on the server, it is a terminal server.  The users that are working would get kicked off, or loose mapped drives, etc.  It is easier to schedule a restart every time the problem happens.  We have an upcoming maintenance scheduled that we can have the servers to ourselves for testing.  I'll let you know on the services after that.  

TCPView on the 2008 R2 servers shows that it trys to make the connection but it never connects.  on the target 2003 server the connection never shows up.  Its like it doesn't even make it to the server.  This just tells me that it is definitely a problem with the 2008 R2 servers as was originally suspected.  

Thanks tdfarmer.  Can you check to make sure clocks are in sync between the servers?  Also what security software are you running?

Still need help with this?

If so, disable windows firewall for a moment, (on the server you are trying to access)

Clocks are synced, within a few minuscule fraction(s) of a second.  ESET NOD 32, all firewalls were already disabled.

tdfarmer,
Messing around with the NetBIOS settings isn't really going to get you very far. NetBIOS doesn't do anything by default on a Windows 2008 server. On that same screen that fixforyou posted, click on the DNS tab, rather than WINS. It should look similar to the attached. You'll want to make sure that either the "Append parent suffixes of the primary DNS suffix" is checked. Alternatively, you can fill in the "Append these DNS Suffixes (in order):" box with your domain suffix if you want to. Let me know if that doesn't work for you. There are some other options using Windows 2008 DNS.  
DNS-Settings.JPG

Re-start your computer browser service and then try again

I think you have to activate your computer browsing service first, because it is disabled by default

my DNS tab looks exactly the same except I have our DNS servers specified manually.  DNS is working properly, after a DNS cache flush, it resolves when you ping by either NetBIOS name or FQDN.  Enabling the computer browser service did not change anything about the problem.  I did have it enabled on one machine, but restarting it did not change the problem either.

Firewall issue?

try to disable your firewall and also your antivirus.

It sounds like, for some reason, the computers are either changing the DNS suffix or it's getting switched to something other than what you want. I said that fiddling with NetBIOS settings won't get you anywhere because NetBIOS isn't used by default anymore. When you attempt to ping or navigate to a computer using just the computer name, the DNS suffix of the domain that the computer you are using is a member of is appended to the name prior to connection. The work around is to add the DNS suffix (or suffixes) you want into the box at the bottom of that screen on the computers that are having issues. This will force the correct DNS suffix to be populated and will also allow you to append multiple DNS suffixes when you are trying to connect to a resource. If the first suffix fails, it will move to the next, and so on.

Another potential technique to resolve this would be to build a GlobalNames zone on your Primary DNS server. The GlobalNames zone is Windows 2008's solution for single label name resolution (AKA, NetBIOS name resolution). A couple of articles I dug up will give you an explanation of what it is, how to set it up, and what it does:
http://www.petri.co.il/windows-DNS-globalnames-zone.htm and http://www.petri.co.il/using-globalnames-zone-window-server-2008.htm

The caveat to this is that the Primary DNS server (or any server that replicates DNS in an AD Integrated Zone, AKA, all your DCs) will need to be Windows 2008. Also note that if you *do* have a globalname zone already built and you're having trouble, you may need to ensure that all the IP information is properly configured with the host name in the globalnames zone.

Windows firewall is blocking netbios traffic. I just saw that a reboot resolves this for a moment. What happens is netbios registers BEFORE the firewall service starts. After the firewall service starts it doesn't re-register with the browser. So, after 12 minutes, it will disappear.

Enable firewall logging (C:\Windows\pfirewall.log) and verify that occurs drop on TCP ports 137, 138 and 139. These ports are used by NetBIOS protocol.

acbrown2010, I will look into ensuring that this is setup as you have suggested.  Manojkundliya, mkuehngoe, ChiefIT, robertodeacruz the firewall is disabled.  The AV software we have deployed does not have any firewall type functionality.  A reboot can resolve this problem from anywhere from 1 day to 1 week (from what I've seen so far) before the issue returns.  I will add that it has always returned.  

Please provide this information:

Go to the R2 server and typ Browstat /status
Go to the 2003 server standard and typ Browstat /status

I am thinking you have two servers that are competing for the domain master browser service election. When one sees the other, the Browser service will stop and an election is forced. You can see an error in the event logs that will say that the browser service has stopped and an election has been forced. It will tell you of the conflicting master browser.

Another thought on my mind is you have a mulithomed computer. The problem being is Netbios binds to both adapters. At a point when the internal adapter is busy, it will look at the external adapter for netbios resolution.

So, let's say you are trying to communicate with the 2003 server, and the 2003 server has two network adapters (one inside and one outside). Now the 2003 server will register for a while on the inside adapter upon reboot, because it wasn't busy trafficking data. Then, all of a sudden the outside adapter needs to pick up the ball because the inside adpater is busy.

To tell if this is a problem, go to the 2003 server and type:
Net Config Redir

You should see:

000000000        For SMB
;kjhlkjhslkfjh      a hex MAC address of nic 1
lkdashf;dlsakj   a hex MAC address of NIC 2

sounds te me like NTLM blocking
http://blogs.technet.com/b/askds/archive/2009/10/08/ntlm-blocking-and-you-application-analysis-and-auditing-methodologies-in-windows-7.aspx

to fix your problem try this:

Run "regedit" on Windows Server 2008 based computer.
Expand and locate the sub tree as follows.
HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters
Add a new REG_DWORD key with the name of "Smb2" (without quotation mark)
Value name: Smb2
Value type: REG_DWORD
0 = disabled
1 = enabled
Set the value to 0 to disable SMB 2.0, or set it to 1 to re-enable SMB 2.0.
Reboot the server.

from: http://www.petri.co.il/how-to-disable-smb-2-on-windows-vista-or-server-2008.htm

We have exactly the same problem with 2008 R2 and windows 2003 file shares. It's not just happening on Remote Desktop servers, it happens on the normal 2008 R2 fileserver as well.

Only restart solves the problem, temporary, it works well for several days after the restart.

Removing the virus scanner doesn't solve the problem.

We have exactly the same configuration for 3 Remote Desktop servers and this is happening usually on only one server at a time, the other 2 works well.



If you try to stop the workstation service, it will not stop, you can't even kill the process with process explorer.

We also have the same issue with 2008 R2 servers. We are on a 2003 domain and after a couple hours of people logging into the servers this issue occurs.

I had the same issue today.
Installing WINS on one of the DC's and adding the IP to the fixed address resolved my problem.