Keep the Computer Browser Service Humming

2 tools, 3 best practices, and a 5-step procedure for troubleshooting computer browsing

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.

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 (x), 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_MACHINESYSTEMCurrentControlSetServicesLanmanServerParametersHidden 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.

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.