The Computer Browser Service

Learn how this important service operates

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 (e.g., Network Attached Storage—NAS—units). 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, the Computer Browser service exists only to support earlier Windows versions. In native-mode Win2K Active Directory—AD—networks with AD-enabled clients, AD replaces the Computer Browser service. However, mixed-mode networks, which maintain pre-Win2K domain controllers—DCs—and networks with clients that aren't AD-enabled still use the Computer Browser service.)

When your network contains multiple Win2K and Windows NT domains, broadcast domains, or protocols, the browsing system (i.e., the process of maintaining and distributing browse lists, as well as the computers involved in that process) can quickly become complex. Troubleshooting the Computer Browser service to ensure that the list contains all the computers you want it to contain—and excludes those you want to hide from the general population of network users—exercises your full range of networking skills. Before you undertake such a task, you need to have a strong grasp of how the service works: what roles various systems can take, how those roles are determined, how systems interact within the context of the service, and what sorts of problems might cause the browse list to be incomplete.

Browser Roles
Any computer that can collect, maintain, and distribute a browse list is considered a browser and takes on one or more of five browser roles: master browser, domain master browser, backup browser, potential browser, and nonbrowser. Computers running Windows for Workgroups (WFW) 3.11 or any more recent Windows version (i.e., Windows XP, Win2K, NT, Windows Me, or Windows 9x) can act as a browser.

At start-up, Windows computers announce themselves through a broadcast to the local network segment (i.e., the broadcast domain for each network protocol the computer uses). On each segment, one computer takes the role of master browser and assumes responsibility for receiving these broadcast announcements. Each master browser maintains browse lists for its segment and—on IP-based networks only—forwards these lists to the domain master browser.

The PDC (or the PDC emulator in a Win2K AD network) always takes the role of domain master browser. The domain master browser acts as a central repository, compiling the browse lists it receives from the network's master browsers, then sending a complete browse list to each master browser. The domain master browser also takes on the role of master browser for its network segment. The domain master browser role is active only on networks that use TCP/IP. (For an explanation of how the Computer Browser service deals with various protocols on a network, see the sidebar "Broadcast Domains, Network Protocols, and Adapters.")

Backup browsers on each network segment receive a copy of the complete browse list from the segment's master browser, then supply that list in response to client requests. The master browser also acts as a backup browser and can include its name in the list of backup browsers that it sends to clients.

A potential browser can act as a master or backup browser, but might not currently be acting in either role. A nonbrowser is a computer that an administrator disabled from maintaining a browse list. When you attempt to start the Computer Browser service on a nonbrowser, the service fails to start with error code 2550 and the system logs event ID 7024. (Clients that don't run the Computer Browser service can still obtain a browse list and display it in Windows Explorer.)

As a Win2K or NT systems administrator, you can edit registry entries to influence the role each computer will play in network browsing. Table 1 summarizes these registry entries and their purposes. Most browser-related entries are found in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesBrowserParameters subkey.

When computers on a network segment belong to different domains or workgroups, at least one computer from each of the represented domains or workgroups maintains a browse list for that domain or workgroup. Master browsers for each domain and workgroup in the segment announce themselves to one another so that users can see resources in all the domains and workgroups, even those that exist outside the segment.

Which System Gets the Job?
When a potential browser that's a PDC, that you've configured as a preferred master browser, or that can't find a master browser for one of its network protocols comes online, it calls an election among the potential browsers in the segment. The election is rigged to tilt the outcome toward the Win2K or NT server with the most recent version of the browser-election protocol (i.e., the rules that different versions of Windows use to decide which computer will be master browser). For systems using the same browser-election protocol version, server versions of Win2K or NT always beat out XP, Win2K Professional, and NT Workstation versions, which always beat out Win9x and WFW versions. Within each set of versions (i.e., server, Win32 workstation, or Win9x and WFW), the pecking order from highest to lowest is PDC, WINS system, preferred master browser, running master browser, system configured to be a master browser or backup browser, and running backup browser. As a final tiebreaker, the computer whose name comes first alphabetically (regardless of case) wins; for example, a computer named ART would beat a computer named BOB.

To conduct an election, the computer calling the election broadcasts an election datagram containing a 1-byte Election Protocol Version field and a 4-byte Election Criteria field. The high-order byte of the Election Criteria field designates the OS priority, the next 2 bytes designate the election-protocol revision level (within the election-protocol version), and the bits of the last byte designate the computer's networking-services role or roles. Each potential browser evaluates the election fields, then broadcasts an election datagram if its Election Protocol Version or (when the election-protocol versions are the same) Election Criteria field is greater than the one received. The system that wins the election becomes the master browser; if a master browser already exists, it demotes itself to backup browser.

The Computer Browser service maintains one backup browser for the first 31 computers in a domain and an additional backup browser for each additional group of 32 computers. The master browser ensures that a sufficient number of backup browsers are active. All DCs and computers with the registry value MaintainServerList=Yes on the master browser's segment become backup browsers if they fail the master-browser election. If the segment still lacks a sufficient number of backup browsers, the master browser selects from the pool of potential browsers until the minimum number is met.

The Role of NetBIOS Name Resolution
How does a master browser find its domain master browser? How do clients find a browser that can respond to a request for the browse list? The answers lie in NetBIOS name resolution.

The browsing system uses several role-specific NetBIOS names that let browse servers and client browsers find each other; Table 2 lists these names, which systems register them, and how systems use them. When a browse server or client browser fails to resolve one of these names to the IP address of the computer taking on the corresponding role, you end up with incomplete browse lists. Understanding how the Computer Browser service uses each of these names will help you troubleshoot service failures.

The Computer Browser service registers three names. All potential browsers register domain_name<1Eh>, which identifies them as computers that will take part in browser elections for the named domain on their network segment. Each master browser registers domain_name<1Dh> and ..__MSBROWSE__.<01H>. (A network monitor trace shows that this name is actually <01h><02h>__MSBROWSE__<02h><01h>.) Backup browsers use domain_name<1Dh> to locate and communicate with the master browser when retrieving the browse list. Master browsers use ..__MSBROWSE__.<01H> to broadcast and receive cross-domain or cross-workgroup announcements on the local subnet. Master browsers that exist on network segments that also host master browsers for other domains or workgroups use these announcements to learn of one another so that the browse list can contain information about each domain and workgroup. In addition, the PDC registers domain_name<1Bh>. NT master browsers presume that the computer that registers this name is the domain master browser. (AD-enabled master browsers query AD to learn the name of the PDC emulator, which takes the role of domain master browser.)

When a backup browser (or a master browser in the role of backup browser) supplies clients with an incomplete browse list, the fault often lies in a NetBIOS name-resolution failure. For example, when a browse list contains only names of computers on the local network segment, the master browser might be having trouble resolving the name of the domain master browser, which it must do to obtain a complete global browse list. A TCP/IP-based Windows Me, Win9x, or WFW 3.11b system can be a master browser as long as both the Windows system in question and the PDC use WINS for name resolution (so that the Windows system can resolve domain_name<1Bh> to the PDC's IP address) and the computer's workgroup name is the same as the PDC's domain name.

Building and Maintaining a Browse List
After the designated PDC takes the roles of domain master browser and master browser for its segment, and after computers on other segments win election to the role of master browser for those segments, the infrastructure is in place to maintain the browse list. An overview of the process is as follows:

The default interval for the transfer of updated browse lists between the domain master browser and master browsers is 12 minutes. The Microsoft white paper "MS Windows NT Browser" (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/winntas/deploy/prodspecs/ntbrowse.asp) states that the list update interval between browsers is 15 minutes. However, I monitored my network, which includes an NT domain and a Win2K AD domain with Windows .NET Enterprise Server (Win.NET Enterprise Server—formerly Win2K Advanced Server) beta 3, Win2K AS, NT Server, Win2K Pro systems, and XP Professional Edition (all acting as browsers in a multisegment network). The packet trace confirmed the 12-minute interval.

On IP networks, the Computer Browser service uses both TCP and UDP protocols. A master browser and the domain master browser transfer browse lists between each other within the scope of a NetBIOS over TCP/IP (NetBT) session for highly reliable communication. All other communications use UDP, a connectionless IP protocol that doesn't guarantee packet delivery. To be more precise, these UDP communications use an implementation of the Common Internet File System (CIFS) protocol, which in turn is an enhanced version of the Server Message Block (SMB) file system protocol.

Because successful delivery of browser datagrams isn't guaranteed, the target Computer Browser service sometimes fails to receive datagrams on a busy network or a busy server. As a result, multiple announcement intervals are sometimes necessary to successfully pass along updated information. Because datagram delivery is imperfect, the Computer Browser service removes old information from the browse list only after the browser fails to receive datagrams from a source computer for three successive announcement intervals. Although a computer that shuts down cleanly announces the shutdown to the master browser, a system that shuts down unexpectedly stays in its master browser's browse list for 36 minutes. Because as many as another 36 minutes can pass before a backup browser on another network segment obtains an updated browse list, a computer might remain in the browse list of another network segment for as many as 72 minutes after it has shut down.

Understanding how the Computer Browser service works gives you a head start when you need to troubleshoot problems. (For a more detailed explanation of the Computer Browser service, see the Windows 2000 Server TCP/IP Core Networking Guide, "Appendix I - Windows 2000 Browser Service" at http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/tcpip/part4/tcpappi.asp.) In a future article, I'll describe the tools and procedures you can use to get to the heart of problems you might have with the Computer Browser service.