Troubleshooting the Microsoft Computer Browser Service

Although there is no centralized method to determine if the browse list across a WAN is complete, there are techniques to determine if the servers on a particular segment are represented in the browse list on a remote segment. These same techniques can be applied on all segments throughout the WAN. However, the results of these tests can change if the roles of the servers change when browser elections occur. Only if all the servers in a domain throughout the WAN are completely static, and no servers come online or go offline, will the results of these tests have meaning over time.

The tests that are described below rely on the Browstat.exe utility from the Microsoft Windows Support Tools. Sample output will be for the TCP/IP protocol only. Also, as with most network problem diagnosis, to troubleshoot the browser service, the administrator must have full knowledge of the network segment boundaries and router configurations on the network. As an example, assume that a client on a remote segment does not have a server in its browse list that is located on another segment.

Because of the time sensitivity of the Browser service and its use of broadcast datagrams, you should not perform these steps until after you wait for the 48-minute cycle (the full propagation cycle in a multiple-segment domain environment).

Remember that name resolution among all browsers is critical and that the first thing to do is to establish a robust name resolution infrastructure with WINS. A lot of time can be wasted trying to track down browser issues, which are really caused by name resolution problems.

1. Find the master browser on the segment on which the server is located. Run this command on the segment on which the missing server resides:
   browstat status
   The response is similar to:
   Status for domain DomainName on transport \Device\NetBT_IEEPRO1
   
   Browsing is active on domain.
   Master browser name is: MasterBrowser
   Master browser is running build 1381
   1 backup servers retrieved from master BackupBrowser
   \\SmallerServer
   There are 100 servers in domain DomainName on transport
   \Device\NetBT_IEEPRO1
   There are 1500 domains in domain DomainName on transport
   \Device\NetBT_IEEPRO1
   This information should indicate which server is acting as the master browser on the segment. However, if the local master browser was slow to respond, this information may have been received from another master browser.
   
   The results of this command give you the "\Device\Protocol_NIC" string, which you can use with other browstat commands.
   
   To find the local master browser on the client's segment, run the following command:
   browstat getmaster \device\netbt_el59x1 domainname
   Using the status or getmaster switch sends a DomainName<1d> query and returns the current master browser for that segment. The Browser service is not used to find which computer is acting as the master browser. You can perform this step remotely if the Browser service itself is used to indicate which computers are acting as the master browser on the segment, but this requires the administrator to know the names of all the servers on each of the segments. Also, this is a poor troubleshooting technique because the Browser service itself is being used to troubleshoot a browser problem. And even if this piece of the browser does not have a problem, the list that is returned may be out-of-date by as much as 36 minutes. To remotely determine the list of master browsers on the domain, run the following command:
   browstat view \device\netbt_ieepro1 \\pdcname | findstr /i mbr
   Next, the administrator must determine which master browser is on the segment that contains the missing server's name.
   
   If a master browser cannot be found, you can force an election by stopping and starting the Browser service on a domain controller that is on the server's segment. In a few minutes, run this test again. Or, on the console of a server on the server's segment, you can force an election by running the following command:
   browstat elect \device\netbt_ieepro1 domainname
2. Determine if the master browser has the server's name in its list. The master browser is the first server in the chain of communication that must contain the missing server's name. This test determines if the master browser has received the server's Host Announcement frame. Note that the "\device..." string is obtained from the output above. Run the following command:
   browstat view \device\netbt_ieepro1 \\masterbrowser | findstr /i missingserver
   If the master browser has the server in its list, the command will return a response that is similar to:
   \\MissingServer NT 04.00 (W,S,NT,PBR,DFS) "Description" of server
   \\MissingServer
   If the local master browser does not have the server's name, you can run the following command from any computer on the missing server's segment:
   browstat forceannounce \device\netbt_el59x1 domainname
   Or, you can run the following command from the missing server's console:
   browstat announce \device\netbt_el59x1 domainname
   It may be useful to verify that the missing server can map a network drive to the master browser to verify network connectivity.
   
   Also, you can reboot the server to force a Host Announcement frame.
   
   
3. Determine if the PDC has received the server's name from the master browser. Run the following command:
   browstat view \device\netbt_ieepro1 \\pdc | findstr /i missingserver
   The output should be similar to:
   \\MissingServer NT 04.00 (W,S,NT,PBR,DFS) "Description" of server
   \\MissingServer
   If the server's name is missing, it is probably because of name resolution problems. For the PDC to obtain the list of servers from the master browser, the server's master browser must be able to resolve the DomainName<1b> name so that it can send the directed Master Announcement frame by using UDP port 138. For the PDC to respond to this announcement to obtain the server's name, it must be able to resolve the master browser's computer name. (For the server's master browser to obtain the domain-wide list from the PDC, it, too, must be able to resolve the PDC's computer name.)
   
   Name resolution in both directions is critical. To verify that the server's master browser can resolve the DomainName<1b> entry, run the following command:
   browstat getpdc \device\netbt_el59x1 domainname
   To verify that the PDC and the master browser can resolve each other's computer name, map a network drive from the master browser to the PDC and from the PDC to the master browser. If any of these steps does not work, resolve the name resolution problem.
   
   
4. Determine the master browser on the client's segment. Do this by using the same steps as in step 1, but on the client's segment.
5. Determine if the master browser has the missing server's name on the client's segment. Run the following command:
   browstat view \device\netbt_ieepro1 \\mbclientseg | findstr /i missingserver
   If the server has the entry, the output should be similar to:
   \\MissingServer NT 04.00 (W,S,NT,PBR,DFS) "Description" of server
   \\MissingServer
   If the master browser does not have the missing server's name, it is probably because of a name resolution problem. Verify that the master browser on the client's segment is able to resolve the DomainName<1b> name by running the following command:
   browstat getpdc \device\netbt_el59x1 domainname
   Also, the master browser must be able to resolve the computer name of the PDC. To verify this, map a network drive to the PDC.
   
   If either of these tests does not work, resolve the name resolution problems.
   
   
6. Determine the backup browsers on the client's segment. To reduce the demands on the segment master browser, when a client requests a browse list, it will choose a backup browser if one is available. Therefore, it is more likely that all the clients will use backup browsers. There are two ways to determine the local backup browsers for this segment.
   
   From the master browser's console, run the following command:
   browstat locallist \device\netbt_ieepro1 | findstr /i bbr
   This will return a list of entries similar to:
   \\BackupBrowser NT 04.00 (W,S,BDC,NT,BBR,DFS) "Description" of server
   \\BackupBrowser
   To remote this command to the master browser, run the following command:
   browstat view \device\netbt_ieepro1 \\masterbrowser 0x40000000 | findstr /i bbr
   NOTE: These flags are defined in the following CIFS Browsing Protocol document:
   
   
   ftp://ftp.microsoft.com/developr/drg/cifs/cifsbrow.doc
7. Determine if the backup browsers have the missing server's name. For all clients on this segment to retrieve a reliable browse list, you must check every backup browser for the missing server's name. For each backup browser, run the following command:
   browstat view \device\netbt_ieepro1 \\backupbrowser | findstr /i missingserver
   If a backup browser does not contain the missing server's name, verify that the backup browser can map a network drive to the master browser. The backup browser role is the most dynamic browser role. Master browsers instruct potential browsers to become backup browsers depending on the browser load. Wait 12 minutes and then repeat steps 6 and 7.

For additional information about how the computer name might not exist in the browsing list, click the article number below to view the article in the Microsoft Knowledge Base:

Multihomed Issues

For the PDC to build a single domain-wide list, it cannot be a multi-homed server. Each master browser on remote segments will establish a connection to the PDC. Because there is no guarantee that every master browser will choose the same interface on the PDC, the PDC must be single-homed so that a single domain-wide list can be built. Also, all master browsers must be single-homed. Every 12 minutes, the master browser connects to the PDC and requests the domain-wide list. The master browser then issues a Master Announcement Browser frame to the PDC telling it to connect to the master browser and obtain its local lists. However, because the PDC does not maintain separate IP addresses for each interface on the master browser, when the PDC connects to the master browser, it only obtains the list of computers and servers that are collected on that particular interface.

Other Considerations

To avoid experiencing intermittent browser functionality and having to perform these tests, you may need to dedicate computers on each segment to maintain a consistent domain-wide list. If servers are frequently shut down and restarted, consider placing a BDC if the number of segments is not large, or at minimum a Windows-based member server on each segment with the IsDomainMaster registry setting set to True. This will give the server an edge during elections in becoming the master browser for the segment.

If none of the steps above work to allow you to proceed to the next step, verify that none of the browser servers that you have identified have a "name in conflict" error. You can check for this by running the following command: You can use this command remotely by using either the -A or -a switch.

The browser is very sensitive to the configuration of the routers throughout the WAN. Because the browser roles are determined by broadcast elections, UDP broadcasts must not be forwarded. Strange behavior can occur if UDP broadcast traffic is forwarded in one direction but not the other. This may generate "8003" browser events causing a continuous cycle of elections.

Another step that you can take to try to resolve problems is to capture network traffic with a protocol analyzer such as the Microsoft Network Monitor tool. To directly view the browser exchanges, you can stop and then restart the Browser service. Unfortunately, there is no guarantee that a browser will assume the same role that it had after you stop and start the Browser service. However, this method can be especially useful to verify the communication when the master browser requests the domain-wide list from the PDC, and immediately following when the PDC requests the local list from the master browser. After the browser service has started on the master browser, within one or two minutes the full exchange should take place. Configure the protocol analyzer's capture buffer and frame size settings to allow for this quantity of traffic.

The list of servers returned by the browse service prior to Windows NT 4.0 was limited to 64 KB in size. When this size is exceeded, you will see a truncated alphabetical list of servers. To avoid this behavior, all browsers must be running Windows NT version 4.0 or later.

For more information, refer to the "Microsoft Windows NT Browser" white paper at the following Microsoft Web site: