Troubleshooting the Browser Service

By Ace Fekay, MCT, MVP
10/1/2012

Preamble:

Keep in mind, each subnet has it’s own master browser, and if you are using WINS, the master browser works together with the WINS service to enumerate an infrastructure wide browse list.

If not using WINS, it uses broadcasts, however, you’ll only see what’s on your own subnet, because NetBIOS broadcasts are more than likely blocked by routers, which is default, and many routers don’t allow NetBIOS broadcast across subnets to be enabled.

And if you are in a multi-subnetted environment, and you want full browsing capabilities, to get around routers blocking NetBIOS broadcasts, it’s suggested to use WINS.

And the default WINS settings out-of-the-box, work fine, as long as you set up DHCP WINS options correctly. There is no need to adjust WINS’ registry parameters, otherwise you’ll find yourself trying to change registry entries on multiple servers and mis-keying something. Here’s more info on configuring WINS:

WINS – What Is It, How To Install It, WINS Replication Partner Design Guidelines, How to Configure DHCP Scopes For WINS Client Distribution, and more:
http://msmvps.com/blogs/acefekay/archive/2010/10/27/wins-what-is-it-how-to-install-it-and-how-to-configure-dhcp-scopes-for-wins-client-distribution.aspx

 

Preferably install at least one server OS on each subnet:

If there is a server OS, and it’s not multihomed, especially if a DC on the subnet and it’s not multihomed (multihoming a DC is a really bad idea), then it should win, unless there’s a problem with the machine itself, such as some sort of security setting in your antivirus blocking traffic, or firewall blocking traffic on it.

If you find workstations are becoming masters, that means there are no server operating systems on those subnets, in such cases, the workstation will win Master Browser election.

And I realize in many large infrastructures, it would be nearly impossible to put a server operating system on each subnet. However, as long as there is a desktop using the latest client operating system that is always up and running 24/7, that will do the trick.

If a newer client OS were to be introduced, then it would start a master browser election, and win the election (OS version and server role is a factor in the election process). And any machine that someone clicks on Network Neighborhood or clicks a Browse button somewhere, would invoke an election, but if a desktop is running on the subnet 24/7, it will win the election, since it’s already up and running.

If you don’t want any other client machine to win the election and were to opt for only that one machine, you can set a registry entry using a GPO to disable participating in the browse list for all the machines in the subnet other than the client machine you chose to keep up and running 24/7:

Set the client machine of your choosing to:
Emulator MaintainServerList=Yes, IsDomainMaster=True

All other clients on the subnet, set it to:
MaintainServerList=Auto,IsDomainMaster=False

I’m not saying this is a perfect solution, but it’s something to consider. Otherwise, if no specific machine is up and running 24/7 on any given subnet, the browse list will be rebuilt each time everyone shuts down, then brings their machines up in the morning, and the cycle starts from scratch to rebuild the list of machines on that subnet.

 

Third Party Devices Participating in the Browser Service

I would like to point out that if you have any 3rd party devices, such as a Seagate BlackArmor NAS, it will jump in on the election process and may win, which in case will snafu your browse list. I had one of those devices at a customer site last year causing numerous problems with the browse list, which in turned snowballed to cause problems with Symantec BackupExec, and other services that rely on browsing.

After some troubleshooting, I found that the BlackArmor NAS was consistently winning the election causing the problems. I couldn’t find anything specific on how to disable browser service participation on the device. It has the latest firmware. I contacted Seagate, and they said they couldn’t help me to disable the device’s ability to participate in the Browser Service.

I finally moved it on to its own VLAN so it can be king of itself on that subnet, so to speak. I gave it it’s own island. Smile

 

Browse List Propagation:

We have to keep in mind with troubleshooting the browser service, there is a time period you have to wait for the list to fully enumerate and become available on the master. A good example is when a server is shut off on a segment, and the workstations kick in, or the server is rebooted, wins the election, and begins a new cycle to enumerate the browse list from WINS and/or broadcasts. This can take a minimal of 12 minutes, upwards to the 48-minute full propagation cycle in a multiple-segment domain environment.

 

When to Troubleshoot

Below are the generic troubleshooting steps I used to troubleshoot the browser service that helped me find out the BlackArmor device was the culprit.

If you are seeing problems with the browser service, such as computers disappearing from the browse list, whether the cause is a third party device, Unix/Linux machine running Samba, or simply based on the infrastructure’s design, it might be a good idea to start troubleshooting to find the culprit.

 

Prepare to Troubleshoot:

  • Make sure the Computer Browser service is Started. Make sure NetBIOS is enabled on al machines.
  • On Windows 2003 and 2000, install the Support Tools (from the Windows CDROM) in order to have the "browstat" utility available.
  • With Windows 2008 and newer, the utility is already installed as part of the operating system files.
  • If there are any antivirus software, third party firewalls, or firewall rules between locations blocking WINS traffic (TCP 42), it could block browser traffic, too. This of course, assumes the Computer browser service is running.

 

Firewall blocks – Test it with PortQry

You can use the Portqry.exe utility to test if the Browser, SMB, WINS and the ephemeral (service response) ports are permitted.

  • Browser: UDP 137/138, TCP 139
  • SMB: TCP 445
  • WINS: TCP 42
  • Ephemeral (Service Response Ports): Varies depending on OS:
  • Windows 2000/2003/XP: TCP/UDP 1024-5000
  • Windows 2008/Vista and newer: TCP/UDP 49152-65535

Description of the Portqry.exe command-line utility
http://support.microsoft.com/kb/310099

Active Directory Firewall Ports – Let’s Try To Make This Simple
http://msmvps.com/blogs/acefekay/archive/2011/11/01/active-directory-firewall-ports-let-s-try-to-make-this-simple.aspx 

 

Multihomed DCs:

And if you have any multihomed DCs, among numerous other problems, that is a major cause of browser problems. Multhoming DCs is not recommended for multiple reasons, including a "Multihomed Browser" scenario. I suggest to disable one of the interfaces.

More info regarding multihoming DCs and why not to do it:

Multihomed DCs (with more than one unteamed NIC or multiple IPs) with DNS, RRAS, iSCSI, and/or PPPoE adapters – A multihomed DC is not a recommended configuration, however there are ways to configure such a DC to work properly.
http://msmvps.com/blogs/acefekay/archive/2009/08/17/multihomed-dcs-with-dns-rras-and-or-pppoe-adapters.aspx

 

Troubleshooting Steps:

Run a browstat status to see who the browse master is for the segment. If it’s not the PDC Emulator, and some other device won the election, that can cause a problem.

To check current status of the browse service on the domain, run:
browstat status

You should get a response similar to:
Browsing is active on domain.
Master browser name is: <serverName>

Note, the machine that is the current master browser will either be, depending if the machine type exists on the segment: the PDC Emulator, a replica DC on the segment, a member server, joined workstation, or workgroup member, Unix or Linux with SAMBA, etc.

If you find a device is winning the election, then we need to disable that ability in the device. If there are no features for that, contact their support department, or put the device behind it’s own subnet or VLAN to prevent it from winning the election on the production network.

To find the current browse master on a segment, you’ll have to find the TransportID:
First run:

browstat getmaster \device\netbt_el59x1 <domainname>

It will error out because the "netbt_el59x1" probably doesn’t exist, and will respond with the transports currently bound to the browser. Copy and paste the transport that does show up into your next command:

browstat getmaster \Device\NetBT_Tcpip_{C2055954-4F86-446F-ACBA-E00BE731C3FB} <domainname>

Force an election by running:
browstat elect \device\netbt_ieepro1 <domainname>

Then check the event logs to see which machine won the election. If it’s a device, such as I’ve found that Linux/Unix with SAMBA, or devices such as a Seagate NAS, may win the election and cause browsing havoc within an environment and get that familiar, but unwanting "Access Denied" when trying to browse.

 

Reference:

Troubleshooting the Microsoft Browser Services:
http://support.microsoft.com/kb/188305

 

Comments, corrections and suggestions are welcomed.
Ace Fekay

Leave a Reply