Description of the Microsoft Computer Browser Service

Microsoft Active Directory services in Windows 2000 and Windows XP replace the computer browser service used in earlier versions of Windows to provide the network basic input/output system (NetBIOS) name resolution. The browser service in Windows 2000 is provided for backwards compatibility with client computers that are running earlier versions of Windows.

This article describes the basic methods by which a server computer provides browse list functionality to client computers on the network. For a more detailed explanation of the browser components, see the following documents:

• Microsoft Windows NT 4.0 Resource Kit, Chapter 3, "Windows NT 4.0 Browser Service."
• The "CIFS/E Browser Protocol" document available at the following Microsoft Web site:
  ftp://ftp.microsoft.com/developr/drg/cifs/cifsbrow.doc
• The browser registry settings described in the Microsoft Windows NT 4.0 Resource Kit Regentry.hlp file.

The primary function of the browser service is to provide a list of computers sharing resources in a client's domain along with a list of other domain and workgroup names across the wide-area network (WAN). This list is provided to clients that view network resources with Network Neighborhood or the NET VIEW command.

The browser service maintains a list of the domain name or workgroup name the computer is in, and the protocol being used for each computer on the network segment being served by the computer running the browser service. On each network segment, a master browser is elected from the group of computers located on the segment that are running the browser service.

The master browser is responsible for collecting host or server announcements, which are sent as datagrams every 12 minutes by each server on the network segment of the master browser. The master browser instructs the potential browsers for each network segment to become backup browsers. The backup browser on a given network segment provides a browse list to the client computers located in the same segment.

NOTE: In a Windows NT domain structure, the primary domain controller (PDC) is always selected as the domain master browser. Only the PDC can be a domain master browser. If a PDC is not present, a domain master browser is not available and you are unable to obtain browse lists from workgroups other than the workgroup you are located in.

On a given network segment, there is only one master browser. All domain controllers other than the PDC are designated as backup browsers. Additionally, one backup browser is allocated for every 32 computers on the network segment.

In a workgroup configuration containing Windows NT Workstation-based computers, there is always one master browser. If there are at least two Windows NT Workstation-based computers in the workgroup, there is also one backup browser. For every 32 Windows NT Workstation-based computers in the workgroup, there is another backup browser.

If there is not a domain controller present on a given network segment, then an election process is started that chooses a master browser and backup browser from the computers on the segment using the following order of priority:

Domain Master Browser Role

Because the browser service is bound by broadcast segments and each master browser maintains its own separate list, there must be a way to merge these lists into a single domain-wide list. This functionality is provided by the domain master browser that is the PDC for the domain. This functionality is not required for network protocols other than Transmission Control Protocol/Internet Protocol (TCP/IP).

The PDC has is also responsible for connecting to its primary Windows Internet Name Service (WINS) server every 12 minutes to obtain a list of all the DomainName type <1b> entries that are registered by the PDCs throughout the enterprise. This is done by issuing an MSRPC R_WinsGetBrowserNames request. These names, along with the workgroup announcement datagrams collected by the master browsers throughout the WAN, build the full list of domain and workgroup names. The names discovered by workgroup announcements take precedence over those obtained from WINS. These domain and workgroup names also contain the name of the server registering any given computer in the browse list. In the event that a WINS server is not available, or it is not registered, the client's browser requests the list of servers from the computer that registered the name. This operation is done on behalf of the client by its browser and is called a double-hop.

The PDC merges all the lists gathered by the master browsers on each segment across the WAN. Every 12 minutes, the master browser connects to the PDC to obtain the domain-wide list. The list is obtained by first issuing a NetServerEnum request with a flag of 0xFFFFFFFF. This request retrieves the complete list of servers within the domain. The master browser then issues the same request with a flag of 0x8000000, which requests all of the domain and workgroup names.

To signal the PDC to retrieve the list collected by this master browser, the master browser sends the PDC a directed master announcement frame over User Datagram Protocol (UDP) port 138. This signals the PDC to immediately connect to the master browser and retrieve its list. This communication is also performed with two NetServerEnum requests. First, a NetServerEnum request with flag 0x40000000 is issued to request the local list of servers collected by the master browser. Then, a NetServerEnum request with flag 0xC0000000 is sent to retrieve the local workgroup announcement frames sent by the master browser of other domains or workgroups on its segment. Each backup browser on the segment issues a NetServerEnum request with flags of 0xFFFFFFFF and x80000000 at 12-minute intervals to obtain the complete list of servers, domains, and workgroup names.

Registration And Propagation Time

Because the browser service relies on server broadcasts, its communication is connectionless and by definition unreliable. When a server starts, it immediately sends a host announcement frame. This process is repeated at 4 minutes and again at 8 minutes. The process is then repeated every 12 minutes thereafter.

Allowing for the loss of a few datagram frames, it is reasonable to expect that the network segment's master browser will add a given computer's name to the browse list within 12 minutes after startup. Beyond this point, connection-oriented traffic is used and the sequences are more deterministic. Within 12 minutes, the segment's master browser will connect to the PDC to obtain the domain-wide list, and at the same time the PDC will connect to the master browser and learn of the new server.

Master browsers on remote segments also connect to the PDC at 12-minute intervals and soon learn of a new server. Within 12 minutes of the remote master browser learning of a new computer's name, all the backup browsers connect to their master browser. At this point, all browsers on a remote segment know about the new server. In a multi-segment WAN environment, the maximum amount of time it should take for all clients within the domain to see the new computer is 48 minutes (12 + 12 + 12 + 12). On a network on which broadcasts and network usage are well within safe parameters, this period should average approximately one-half as long (24 minutes).

Removing computers from the browse list may take more time. To allow for lost datagram frames, the master browser does not remove a server from its list until 3 announcement periods have passed. If the server is not shut down gracefully or if network connectivity is lost, the server can remain in the master browser's list for up to 36 minutes. After this time, the PDC is notified to remove the server name. The same communication flow follows to remove a server's name. Within 12 minutes, a master browser on a remote segment obtains the domain-wide list from the PDC, and within 12 minutes each backup browser connects to the master browser. This process can take as long as 72 minutes to finish (36 + 12 + 12 + 12). If the server is shut down gracefully, the browser sends a single Host Announcement frame indicating that it is no longer acting as a server. Upon receipt of this datagram, the master browser immediately removes the server from its local list. On a network on which broadcasts and network usage are well within safe parameters, this period should average approximately one-half as long (36 minutes).

Because a server's browser role is defined dynamically with periodic elections, determining the flow of communication used to provide the browse list to a specific client computer can be difficult. If a master browser is shut down gracefully, the master browser forces an election for a new master browser during shutdown. If the backup browser that wins the election has been present on the network long enough to receive a complete browse list, it starts as a master browser with a fully populated browse list, and browse functionality continues on the network segment without interruption.

If a server that was acting as the master browser is not shut down gracefully or if the master browser's force election request datagram is lost, there may be a delay before browse functionality is available on the network segment. An election of a new master browser is caused if a client computer requests a browse list and is unable to locate a master browser. It may take up to 12 minutes for a backup browser to discover that no master browser is present, depending on network usage.

Name Resolution Requirements

Name resolution across the domain is critical for the distributed browsing model to operate. All computers across the WAN that are potential master browsers must be able to resolve the DomainName type <1b> entry for the PDC. After a potential master browser receives a positive response to the query for a PDC, the master browser must also be able to resolve the computer name type <00> entry of the PDC. The PDC must be able to resolve the names of all computers that are potential master browsers in order to be able to connect to them. The PDC listens for directed master announcements from the master browsers on UDP port

This announcement triggers the PDC to resolve the computer name type <00> of the master browser, and to request the browse list maintained by the master.

Once a browse list is presented to a client computer, the client computer must resolve the NetBIOS name entry of any computer listed in order to view shared resources. Therefore, all client computers must be able to resolve the Internet Protocol (IP) address of all computers in the domain. In most networks configurations, this means that the distributed WINS infrastructure must be working properly.