Keep the Computer Browser Service Humming

Downloads
25643.zip

In "The Computer Browser Service," June 2002, InstantDoc ID 24879, I explained that the Microsoft Computer Browser service maintains lists of your network's Windows-based domains, workgroups, and computers, as well as other network equipment that supports the NetBIOS protocol. These browse lists are the source of the information that users see when they expand Network Neighborhood in Windows Explorer. In Windows 2000—based networks, Active Directory (AD) replaces the Computer Browser service. However, mixed Win2K—Windows NT networks that maintain pre-Win2K domain controllers (DCs) and networks with some clients that aren't AD-enabled still use the Computer Browser service.

In the Computer Browser service, the domain master browser in an IP network interacts with network segment master browsers, relying on NetBIOS name resolution and several special NetBIOS names, to assemble lists of computers and other equipment. But what do you do when the Computer Browser service on your network breaks down? To prepare for this possibility, you need to know about the tools and procedures you can use to troubleshoot browser service problems.

A Healthy WINS
You'll find that NetBIOS name-resolution failures are a root cause of many incomplete browse lists. Make the effort to implement a robust name-resolution subsystem on your network, and many of your browsing problems will vanish. Microsoft recommends using WINS for NetBIOS name resolution. In a network with multiple broadcast domains (i.e., a network segmented by routers or Virtual LANs—VLANs), maintaining a system of WINS servers can be a lot easier than the alternative (i.e., maintaining client-based LMHOSTS files).

I suspect that most of you who've been responsible for WINS servers have had to deal with WINS database corruption—it seems to come with the territory. Compact and scavenge (remove obsolete information from) your WINS database regularly to avoid common WINS-related problems and browsing problems. For a list of articles that can help you maintain healthy WINS servers, see "Related Articles in Previous Issues," page 36. You can also find a detailed description of WINS at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windows2000serv/reskit/tcpip/part2/tcpch07.asp.

As you work through your browsing problems, you might come to suspect a NetBIOS name-resolution problem. To assist in determining a point of failure, see the sidebar "NetBIOS Name-Resolution Steps," which summarizes how Windows queries various sources during NetBIOS name resolution.

Browmon and Browstat
Microsoft provides two tools specifically for monitoring and troubleshooting the browser service: Browser Monitor (Browmon—browmon.exe) and Browser Status (Browstat—browstat.exe). When working with either tool, keep in mind that the computer you run them on limits them. In multiprotocol networks, both tools report browse lists only for the protocols that the local computer supports.

Browmon is a GUI-based utility in the Microsoft Windows NT Server 4.0 Resource Kit and the Microsoft Windows 2000 Resource Kit. For each domain you ask Browmon to monitor, it shows the status of the browsing subsystem for each protocol, as Figure 1 shows. Double-clicking a protocol returns the detailed information that Figure 2 shows, including the names of the master and backup browsers and the domains and servers on each browser's browse list.

Browmon reports only on the status of the local collision domain—that is, it sees only the local segment master browser and backup browsers. You can use Browmon to quickly see which computers are acting as master browsers and backup browsers for your domains and to compare these browsers' browse lists. Browmon automatically refreshes its display at a user-specified interval.

Browstat is a much more powerful tool. In addition to displaying browse lists and the names of browser computers, Browstat can force an election and reset the master browser. An older version of Browstat is in the NT 4.0 resource kit; an updated version is in the Windows 2000 Support Tools. Both versions have the same troubleshooting capabilities, but the Win2K version is easier to use. The earlier version requires that you include on every command the protocol name as the Net Config Rdr command displays it. For example, when I type the command

net config rdr

on my Win2K Professional workstation, it reports the TCP/IP protocol name as NetBT_Tcpip_\{3F14F1D1-F77B-410E-8040-7582A8A889A2\}. Thus, the earlier version of Browstat requires the following command on my system to display a list of backup browsers:

browstat gb NetBT_Tcpip_
  \{3F14F1D1-F77B-410E-8040-
  7582A8A889A2\}

(Gb, or Getblist, is the Browstat subcommand to retrieve a list of backup browsers.) Some protocol names on some systems are quite long, as you can see.

The Win2K version of Browstat has a subcommand—Dumpnet—that displays the protocol names and assigns each a single-digit protocol number. You can use this protocol number in lieu of the protocol name with all of the other subcommands. On my Win2K Pro system, the command

browstat dumpnet

associates the numeral 2 with the TCP/IP protocol bound to the NIC (the numeral assigned depends on the binding order, so it differs on different systems). Thus, the command

browstat gb 2

displays a list of backup browsers.

When working with the earlier version of Browstat, I create a two-line command file in which I hard-code the protocol name. Listing 1, page 36, shows such a file for the IP protocol name NetBT_DC21x41. Then, I can call the file to easily run any Browstat command that uses the protocol named in the file. For example, if I named the Listing 1 file browip.cmd and placed it in the search path, the command

browip view mydomain

would display the browse list for the named protocol in the domain MYDOMAIN.

Note that to use this command file, you must replace NetBT_DC21x41 with the full protocol name used on the computer on which you execute Browstat. When you run Net Config Rdr on your computer, the section of the output that follows the words "Workstation active on" lists the full protocol name and media access control (MAC) address of each network adapter and protocol bound to the Workstation service. On my Win2K Pro system, Net Config Rdr displayed NetBT_Tcpip_\{3F14F1D1-F77B-410E-8040-7582A8A889A2\} (0030843E6609) for the TCP/IP protocol. You need the full name of the protocol—in this case, the full character string beginning with NetBT through and including the closing brace (\})—but not the MAC address, which is in parentheses after the protocol name.

Best Practices
To promote trouble-free browsing, I recommend the following browser best practices.

• On all multihomed computers, set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services Browser\Parameters\MaintainServerList registry subkey to No so that the computer can't take any active browser role.
• Determine which computers on each segment are the master browsers. On each segment, set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Parameters\IsDomainMaster registry subkey to True on one or two servers. If the segment has only one server, select one or two workstations to act as browsers in the event that the server is down. Remember how browser elections are decided—IsDomainMaster=True causes a workstation to win a browser election only if no servers are present on the network segment.
• Ensure that each potential segment master browser can find the domain master browser—that is, can resolve the domain_name<1Bh> NetBIOS name. If you configure all master browsers to use a working WINS subsystem, they'll be able to find the domain master browser. AD-enabled systems can query AD to find the domain master browser. If you don't have WINS or AD, you must configure each potential browser on network segments that don't host the PDC to use an LMHOSTS file.

Assuming a domain with a NetBIOS name of MYDOMAIN and a PDC with a NetBIOS name of DC1 at IP address 192.168.0.1, include in the LMHOSTS file the entries that Listing 2 shows. The first entry explicitly configures name resolution for the domain_name<1Bh> NetBIOS name. Note that you must enclose the domain name, including the hexadecimal character in position 16 of the name, in double quotes. In the file, you indicate a hex value by starting it with a backslash, the numeral 0, and the letter x (\0x), as Listing 2 shows. Add spaces after the domain name and before the backslash so that the backslash is in position 16. The second entry identifies DC1 as a DC for MYDOMAIN and generates a MYDOMAIN<1Ch> group record and records for DC1 that represent the Workstation, Messenger, and Server service bindings. Capitalize domain and computer names, PRE, and DOM. Type

nbtstat —R

to load the LMHOSTS file (be sure to use -R rather than -r; the -R switch reloads the cache, and the -r switch lists statistics). Type

nbtstat —c

to check the results.

A Troubleshooting Procedure
Successful browsing is the result of a complex interaction between many of Windows' basic network subsystems, so no one troubleshooting procedure works in all situations. The process you use will depend on the symptoms you see. Your success will often depend on a full and accurate understanding of your network structure. When you troubleshoot browsing, take into account the time a browse list can require to incorporate a change in membership.

I can't recommend a one-size-fits-all troubleshooting procedure, but I can describe how I would troubleshoot one typical scenario: A client's browse list is missing one or more computers, or perhaps all the computers from one broadcast domain. I've always found it useful to "pretend I'm the computer" when troubleshooting—that is, I step through the process that I know the system is using until I discover where the process is breaking down. Thus, my troubleshooting procedure traces the browse list from the broadcast domain on which the missing computer resides to the incomplete browse list on the client's broadcast domain.

The procedure assumes that you've checked the computer missing from the browse list to be sure it's operating properly and has good network connectivity. Along the way, you'll discover where the system is breaking down and have specific items to check when you find the trouble spot. While you're working through a browsing problem, keep in mind that it can result from name-resolution failures and can occur when a master browser is multihomed, when one or more computers have the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\Hidden registry subkey set to 1, when a segment master browser fails to receive an announcement from the computer, or when a master browser and the missing computer have no transport protocols enabled for NetBIOS in common.

For this procedure, it's best to work from a computer in the same broadcast domain as the segment master browser that you're checking so that potential routing or WINS server problems won't affect the test procedure. In the following steps, I assume a scenario in which you're using the Win2K version of Browstat, protocol number 2, a domain called MYDOMAIN, a PDC named DC1, a segment master browser named SERVER1, and a backup browser named BACKUP1.

1. Find the missing computer's segment master browser. Type

browstat status

Browstat should display the names of the segment master browser and backup browsers and a summary of the current browse list. Browstat resolves the domain_name<1Dh> NetBIOS name to the address of the segment master browser to retrieve this information from the segment master browser. After the segment master browser wins an election, its Computer Browser service registers the domain_name<1Dh> name with NetBIOS but doesn't register the name with WINS, ensuring that broadcast name resolution will resolve the name to the IP address of the local segment master browser.

If Browstat fails to locate a segment master browser, verify that at least one computer on the network segment is eligible to be a browser. Then, force a browser election in one of two ways. First, on the missing computer's network segment, stop and restart the Computer Browser service on a DC or on a computer with the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Brows-er\Parameters\IsDomainMaster registry subkey set to True. Alternatively, type

browstat elect 2 mydomain

2. Check the completeness of the segment master browser's browse list. Type

browstat view 2 \\server1

Browstat will retrieve the browse list from the server you specify in the command line. The browse list includes codes for the service that each computer performs. MBR identifies a master browser, PBR identifies a potential browser, and BBR identifies a backup browser.

If the browse list contains only computers on the local network segment, chances are that the segment master browser can't contact the domain master browser (i.e., the PDC), which could mean a routing or other network connectivity problem or a name-resolution failure. To determine whether a segment master browser can get the name of the PDC, type

browstat getpdc 2 mydomain

on the segment master browser. This command causes the computer that executes it to issue a NetBIOS name-resolution request for domain_name<1Bh> on the specified transport. If successful, it returns the name of the PDC.

If the command isn't successful, you can find the name of the PDC another way. In an NT 4.0 domain, Server Manager tells you which computer is the PDC. In a Win2K AD network, the PDC is the computer that owns the Flexible Single-Master Operation (FSMO) role PDC. To determine the owner of the PDC FSMO role, open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in console on a DC or other computer on which you've installed the Win2K Administration Tools. Click the domain, then select Operations Masters from the Action menu. Click the PDC tab to view the current owner of the PDC FSMO role. In an AD domain that uses WINS, the DC that owns the PDC FSMO role (also known as the PDC emulator) registers the domain_name<1Bh> name with WINS for the benefit of non-AD-enabled computers and applications.

If the Browstat Getpdc command fails to return the name of the PDC, you must solve the name-resolution problem. Describing how to fix name-resolution problems is outside the scope of this article, but the articles listed in "Related Articles in Previous Issues" cover this topic.

To retrieve browse lists from each other, the domain master browser and the segment master browser must both be able to resolve each other's computer_name<00h> names. You can map a drive from a segment master browser to the domain master browser to verify the two machines' ability to resolve each other's computer_name<00h> names.

If a computer is missing from its local segment master browser's browse list, you can use a Browstat subcommand to force all computers on the local segment to announce themselves. To do so, type

browstat forceannounce 2
  mydomain

After you force an announcement, be sure to wait long enough for browse list propagation to be completed before you do additional troubleshooting.

3. Check the completeness of the domain master browser's browse list. To display the domain master browser's computer browse list, type

browstat view 2 \\dc1

(remember that DC1 is the name of our domain master browser, or PDC). If the missing computer is listed on its segment master browser's list but not on the domain master browser's list, check for the name-resolution failures in Step 2.

4. Locate the client network segment master browser and check its browse list. If the browse list on the domain master browser is complete, the problem lies somewhere in the client broadcast domain or in the client's communication with the domain master browser. Follow the same procedures I describe in Steps 1 and 2 to locate the client segment master browser and check its browse list. If the client's segment master browser's browse list is incomplete, check for name-resolution problems as I describe in Step 2. If the browse list is complete, the problem might lie with the segment's backup browsers.
5. Locate the client network segment's backup browsers and check their browse lists. Because a client might be getting its browse list from any browser on the network segment, a problem at a backup browser can lead to incomplete information at the client. Up to 12 minutes can elapse while changes propagate from a segment master browser to a backup browser on the same segment.

You can use Browmon or Browstat to determine which computers are backup browsers on the client broadcast domain and compare the backup browsers' current browse lists. In Browmon, the browsers lacking the red dot on the icon are backup browsers. Or type the Browstat subcommand

browstat status

to list the names of backup browsers for each transport on the local network segment.

For each backup browser, type

browstat view 2 \\backup1

Check each of the browse lists for completeness. If a backup browser's browse list is incomplete, check its ability to resolve segment_master_browser<00h> by mapping a drive from the backup browser to the segment master browser.

Troubleshooting Multidomain Browsing
A browse list can contain the names of other domains. A master browser for one domain on a network segment receives domain announcements from the master browsers for other domains that exist on the same network segment. Domain master browsers that are configured to use WINS periodically query the WINS database for domain_name<1Bh> records. Browsers then include these discovered domains in their browse lists.

When a client wants to browse a discovered domain, it contacts a browser for the domain or the master browser that made the announcement or WINS registration to request a browse list for the domain. If the client can resolve the address for a browser, the client will be able to browse the domain. However, the client might be able to see a computer on a browse list and not be able to access that computer. The client must also be able to resolve the address of the computer, and because browsers can be slow to remove a computer from the browse list, the computer might no longer be up on the network when the client tries to access it.

Troubleshooting the Computer Browser system can test your skills, demanding the full range of knowledge of Windows networking subsystems. However, with a little patience, an understanding of how Windows works, and the right tools, you'll diagnose and correct the problem.

Related Articles in Previous Issues

You can obtain the following articles from Windows & .NET Magazine's Web site at http://www.winnetmag.com. SEAN DAILY "Recovering WINS," March 2002, InstantDoc ID 23833 "Navigating Name Resolution, Part 2," July 2000, InstantDoc ID 8931 "Navigating Name Resolution, Part 1," June 2000, InstantDoc ID 8695 DARREN MAR-ELIA "WINS and DHCP Preventive Maintenance," March 1999, InstantDoc ID 4872 MICHAEL D. REILLY "Implementing WINS," May 1999, InstantDoc ID 5212