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.
- Find the master browser on the segment on which the server
is located. Run this command on the segment on which the missing server
The response is similar to:
Status for 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.
Browsing is active on domain.
Master browser name is: MasterBrowser
Master browser is running build 1381
1 backup servers retrieved from master BackupBrowser
There are 100 servers in domain DomainName on transport
There are 1500 domains in domain DomainName on transport
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
- 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
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 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
browstat forceannounce \device\netbt_el59x1 domainname Or, you can run the following command from the missing server's
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.
- 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 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
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.
- 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
- 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 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.
either of these tests does not work, resolve the name resolution
- 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.
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 To remote this command to the master browser, run the following
browstat view \device\netbt_ieepro1 \\masterbrowser 0x40000000 |
findstr /i bbr
NOTE: These flags are defined in the following CIFS Browsing Protocol
- 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:
Computer Name Missing in the Browsing List
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.
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.
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
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
For more information, refer to the "Microsoft Windows NT
Browser" white paper at the following Microsoft Web site: