Troubleshooting the Microsoft Computer Browser Service

ID: Q188305

The information in this article applies to:

SUMMARY

While there is no centralized method to determine if the browse list across the 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. But the results of these tests can change due to the roles of the servers changing when browser elections occur. Only if all the servers in a domain throughout the WAN are completely static, and no servers come online or offline, will the results of these tests have meaning over time.

The tests described below rely on the Windows NT Resource Kit utility Browstat.exe. Example 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, consider 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 waiting for the 48-minute cycle (the full propogation cycle in a multisegment domain environment).

Remember that name resolution between all browsers is critical and the first order of business 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.


MORE INFORMATION

  1. Find the Master Browser on the Segment Where the Server Resides.

    This command must be run on the segment where the missing server resides. Run the following command:

    BROWSTAT STATUS 
    
   Status for domain <DomainName> on transport \Device\NetBT_IEEPRO1

       Browsing is active on domain.
       Master browser name is: &lt;MasterBrowser&gt;
           Master browser is running build 1381
       1 backup servers retrieved from master &lt;BackupBrowser&gt;
           \\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. But, if the local master browser was slow to respond, this information may have been received from another master browser.

    The results of this command will give us the "\Device\Protocol_NIC" string, and can be used 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 who is acting as the master browser. This step can be done 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 returned may be out- of-date by as much as 36 minutes. To remotely determine the list of master browsers on the domain, send the following command:

    BROWSTAT VIEW \Device\NetBT_IEEPRO1 \\PDCName | FINDSTR /I MBR

    Now 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, an election can be forced by stopping and starting the browser service on a domain controller that is on the server's segment. In a few minutes, rerun this test. Alternatively, on the console of a server on the server's segment, an election can be forced 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: 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 something 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, then the following can be run from any computer on the missing server's segment:

    BROWSTAT FORCEANNOUNCE \Device\NetBT_El59x1 <DomainName>

    Or the following command can be run 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, the server can be reboot 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 the following: 
    
   \\<MissingServer>  NT  04.00 (W,S,NT,PBR,DFS) "Description" of server
   \\<MissingServer>

    If the server's name is missing, this is probably due to 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 it can send the directed Master Announcement frame using UDP port 138. And 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 form 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>

    And to verify both the PDC and the master browser can resolve each others 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 fail, resolve the name resolution problem.


  4. Determine Master Browser on the Client's Segment

    This is done using the same steps in step 1 above, but is run on the client's segment.


  5. Determine If 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 due to 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 fail, resolve the name resolution problems.


  6. Determine the Backup Browsers on the Client's Segment

    To reduce demands on the segment master browser, when a client requests a browse list, it will choose a backup browser if one is available. Therefor it is more likely that all 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 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, every backup browser must be checked for the missing server's name. For each backup browser, run the following commands:

    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 repeat steps 6 and 7.


Multihomed Issues

For the PDC to build a single domain-wide list, it cannot be a multihomed server. Each master browser (MB) on remote segments will establish a connection to the PDC. Because there is no guarantee that every MB 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 MB connects to the PDC and requests the domain-wide list. The MB then issues a Master Announcement Browser frame to the PDC telling it to connect to the MB and obtain its local lists. But because the PDC does not maintain separate IP addresses for each interface on the MB, when the PDC connects to the MB, it will only obtain the list of computers and servers 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 shutdown and restarted, consider placing a BDC if the number of segments is not large, or at minimum a Windows NT 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.

For all the steps above, if none of the suggestions 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. This can be seen by running the following command:

NBTSTAT -n

This command can be used 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 can be taken to try to resolve problems is to capture network traffic with a protocol analyzer such as Microsoft's Network Monitor. To directly view the browser exchanges, the browser service can be stopped and then restarted. Unfortunately, there is no guarantee that a browser will assume the same role that it had after stopping and starting the browser service. But 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 kilobytes in size. When this size is exceeded, the user will see a truncated alphabetical list of servers. To avoid this behavior, all browsers must be running Windows NT version 4.0 or later.

Additional query words: 


Keywords          : 
Version           : winnt:4.0
Platform          : winnt 
Issue type        : kbinfo

Last Reviewed: March 11, 1999