Windows 2000 Browser Service
Windows 2000 Browser Service |
|
The most frequent problem with the browser service is server names not replicating on browse lists across the network. The following example assumes that a client on one subnet cannot see a server located on another subnet in its browse list. By completing the sequence of commands described in the following steps, you can determine at which point a server missing from a browse list has stopped name replication. It is important that you understand the architecture of your network in order to perform a proper analysis.
For best results, run the following test procedures in the direction of propagation, starting from the subnet where the missing server is located and continuing through to the subnet where the client that cannot find the missing server is located.
Note
If any of these steps prevent you from proceeding to the next step, verify that none of the browser servers that you have identified have a name conflict error. You can determine whether there is a name conflict by running the following command:
nbtstat –n
If there is a name conflict, Nbtstat lists it in its Status column. If the DomainName <1d> or <1e> is in conflict, stop and restart the browser service on the computer in question.
This command can be run remotely by using the command line option –a.
Figures included with the following procedures use placeholders for various parts of the commands you need to use. Table I.4 describes these placeholders.
Table I.4 Placeholder Description for Figures
| Placeholders | Description |
|---|---|
| <Domain Name> | The name of the domain |
| <Protocol> | Identifies the transmission protocol.
Format: netbt_tcpip |
| <Network Adapter ID> | Unique identifier for the computer's network adapter
Format: nn-nn-nn-nn-nn-nn where n represents a hexadecimal integer |
| <Master Browser> | The name of the master browser |
| <Backup Browser> | The name of the backup browser |
| <DMB> | The name of the domain master browser. Because the domain master browser functionality resides on a PDC, the domain master browser is commonly referred to as "the PDC." |
| <Missing Server> | The server that is missing from the browse list |
Figure I.11 shows the direction of propagation.
Figure I.11 Direction of Propagation
The following command enables you to determine which server is acting as the master browser on the subnet where the missing server resides.
To find the master browser on the subnet where the missing server resides
Running this command tells you which server is acting as the master browser on the subnet, but if the local master browser is slow to respond, you might receive this information from the domain master browser.
Note
The results of this command gives you the address string \Device\<Protocol>_<Network Adapter ID> of the interface of the computer where the command is run. This address string can then be used with other Browstat.exe commands.
To determine which server is acting as the master browser on the subnet
Browstat.exe returns information similar to the example shown if Figure I.12.
Figure I.12 Results of Running Browstat.exe
While the command-line switch status causes Browstat.exe to run both a local DomainName[1D] and a remote DomainName[1B] query for the domain master browser, the switch getmaster only issues a DomainName[1D] query and returns the current master browser for that subnet.
To query only the local subnet for a master browser
browstat getmaster \device\<Protocol>_<Network AdapterID> <Domain Name>
Browstat.exe returns information similar to the example shown in Figure I.13.
Figure I.13 Locating the Current Master Browser
Using the getmaster switch produces the most accurate results when determining the master browser, since this method only issues the request on the local subnet.
This step can also be performed remotely by using the browser service itself to tell you which computers are acting as the master browser on the subnet, but this requires both that the administrator know the names of all the servers on each of the subnets and that the distributed browser service be working properly.
To remotely determine the list of master browsers on a domain
browstat view \device\<Protocol>_<Network Adapter ID> \\<DMBname> findstr /i mbr
Browstat.exe returns information similar to the example shown in Figure I.14.
Figure I.14 Locating Master Browsers on a Domain
The benefit of this method is that you can issue this command remotely. However, the results can be inconsistent, because this is a test that uses the browser service itself to troubleshoot a browser problem. Additionally, even if this piece of the browser does not have a problem, the list returned may be as much as 36 minutes old.
Because this remote method produces a complete master browser list, you need to determine which master browser is on the subnet containing the missing server's name.
If the master browser on the missing server's subnet cannot be found, you can force an election by stopping and starting the browser service on a domain controller or backup browser that is on the server's subnet. In a few minutes, run this test again to see if the missing browser reappears in the list. Alternately, you can force an election on the server's subnet from within the console of a server.
To force election of a master browser from a server console
browstat elect \device\<Protocol>_<Network Adapter ID> <Domain Name>
The master browser on the missing server's subnet is the first server in the communication chain that must contain the names of the servers on its subnet. If the missing server's name is not on its list, you have isolated the point of failure in the propagation sequence.
To determine if the master browser has the missing server in its name list
browstat view \device\<Protocol>_<Network Adapter ID> \\<Master Browser> findstr /i <Missing Server>
If the master browser has the server in its list, Browstat.exe returns information similar to the example shown in Figure I.15.
Figure I.15 Determining if a Master Browser has the Missing Server in its List
If the local master browser does not have the server's name, Browstat.exe displays no information, and you are returned to the command prompt. In this event, you can force all hosts on the subnet to announce themselves, and the missing server should reappear on the master browser's list.
To force all hosts on a subnet to announce themselves
browstat forceannounce \device\<Protocol>_<Network Adapter ID> <Domain Name>
Remember that host announcements are broadcasts, and broadcasts can get lost. The missing server can also be rebooted to force it to send a HostAnnouncement datagram.
It might also be useful to verify that the missing server can map a network drive to the master browser to verify network connectivity.
After 12 minutes, check to see if the master browser has the missing server in its list. If it does, the name should propagate through the rest of the domain and resolve the problem.
Determine if the domain master browser has received the server's name from the master browser.
To determine if the domain master browser has the missing server in its name list
browstat view \device\<Protocol>_<Network Adapter ID> \\<DMB> | findstr /i <Missing Server>
If the domain master browser has the server in its list, Browstat.exe returns information similar to the example shown in Figure I.16.
Figure I.16 Determining if the Domain Master Browser has Received the Server's Name From the Master Browser
If the domain master browser does not have the server's name, Browstat.exe displays no information, and you are returned to the command prompt with no further information.
If the server's name is missing in the domain master browser's list, its absence is most likely due to a problem with name resolution. In order for the domain master browser to obtain the list of servers from the master browser, the server's master browser must be able to resolve the DomainName[1B] name query so it can send the directed MasterAnnouncement datagram using UDP port 138 of the domain master browser. Also, in order for the domain master browser to respond to this announcement and obtain the server's list, it must be able to resolve the master browser's computer name from the master browser's IP address. Being able to resolve both IP addresses from computer names and computer names from IP addresses is critical.
To verify that the server's master browser can resolve the DomainName<1b> entry in the browse list
browstat getpdc \device\<Protocol>_<Network Adapter ID> <Domain Name>
If the server's master browser can resolve the DomainName<1b> query, Browstat.exe returns information similar to the example shown in Figure I.17.
Figure I.17 Verifying That the Server's Master Browser can Resolve the DomainName<1b> entry
To verify that both the domain master browser and the master browser can resolve each other's computer name, map a network drive from the master browser to the domain master browser and from the domain master browser to the master browser. If you cannot map drives in either direction the problem might be a name resolution problem.
This step follows the propagation chain by moving the testing process to the client's network subnet. Use the same procedures as listed in step 1, but run them on the client's network subnet.
The master browser on the missing client's subnet receives its list from the domain master browser in exchange for its own name list. Determine if the client's master browser has the missing server in its name list.
To determine if the master browser on the client's subnet has the missing server's name
browstat view \device\<Protocol>_<Network Adapter ID> \\<Master Browser> | findstr /i <Missing Server>
If the master browser has the server in its list, Browstat returns information similar to the example shown in Figure I.18.
Figure I.18 Determining if a Client's Master Browser has Exchanged Lists with the Domain Master Browser
If the master browser does not have the missing server's name, it is probably due to a name resolution problem. You then need to verify that the master browser on the client's network subnet is able to resolve the DomainName<1b> name.
To determine if the master browser can resolve the DomainName<1b> entry in the name list
browstat getpdc \device\<Protocol>_<Network Adapter ID> <Domain Name>
If the client's master browser can resolve the DomainName<1b> entry, Browstat returns information similar to the example shown in Figure I.19.
Figure I.19 Verifying That the Master Browser on the Client's Subnet is Able to Resolve the DomainName<1b> Name
Also, the master browser must be able to resolve the computer name of the domain master browser. To verify this, map a network drive from the master browser to the domain master browser, then map a network drive from the domain master browser to the master browser on the client's subnet.
If either of these tests fail, you need to correct the name resolution problems.
To reduce the processing demands on the master browser of a network subnet, client requests for a browse list are primarily directed to the backup browser.
To retrieve a list of backup browsers on the client's subnet remotely through the master browser
browstat view \device\<Protocol>_<Network Adapter ID> \\<MasterBrowser> 0X40000000 | findstr /i bbr
If there are backup browsers on the client's subnet, Browstat returns information similar to the example shown in Figure I.20.
Figure I.20 Retrieving a List of Backup Browsers
The hexadecimal number 0x40000000 is a bit mask that instructs the specified master browser that the list is to be generated from its local domain. These bit masks are defined in the Common Internet File System Browsing Protocol.
For the clients on this subnet to retrieve a reliable browse list, every backup browser must be checked for the missing server's name.
To check the name lists of the backup browsers for the missing server's name
browstat view \device\<Protocol>_<Network Adapter ID>\\<Backup Browser>| findstr /i <Missing Server>
Browstat returns information similar to the example shown in Figure I.21.
Figure I.21 Checking Backup Browsers for the Missing Server's Name
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. The number of backup browsers that are placed into service depends on the number of servers running on the master browser's network subnet.
If there is a browser election in progress, wait 12 minutes or more, and then attempt to find missing servers.
If you experience continual or intermittent problems with browser functionality, you can choose to dedicate computers to the browsing process on each network subnet to maintain a consistent domain-wide list. If servers are frequently shut down and restarted, consider placing a BDC or a Windows NT member server on each network subnet with the value of the IsDomainMaster entry in the computer's registry set to True. This entry (data type Reg_SZ) appears in the following registry subkey:
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser
\Parameters
Setting the value of IsDomainMaster to true gives the server preference during elections in becoming the master browser for the network subnet. For more information on IsDomainMaster, see "Specifying Browser Computers" earlier in this chapter.
Caution
Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Microsoft Management Console (MMC) or Control Panel whenever possible.
The browser service is very sensitive to the configuration of routers on an IP internetwork. Since the browser roles are determined by broadcast elections, UDP broadcasts must not be forwarded. Unpredictable behavior can occur if UDP broadcast traffic is forwarded in one direction but not the other. This can cause a continuous cycle of elections.
Another step that can be taken to resolve browser problems is to capture network traffic with a protocol analyzer such as Microsoft Network Monitor. To directly view the communication between browsers, the browser service can be stopped and then restarted. Unfortunately, there is no guarantee that a browser assumes the same role that it had before the browser service is restarted. However, this method can be especially useful to verify the communication process when the master browser requests the domain-wide list from the domain master browser, and immediately following that when the domain master browser requests the local list from the master browser. After the browser service has started on the master browser, within a few minutes the full exchange takes place. Configure the protocol analyzer's capture buffer and frame size settings to allow for this quantity of traffic.
The size of the list of servers returned by the browser service prior to Windows NT 4.0 was limited to 64 kilobytes. When this size is exceeded, the user sees a truncated alphabetical list of servers. To avoid this behavior, all browsers must be running Windows NT version 4.0 or later.
