®

Windows NT® Server

Server Operating System

Microsoft Windows NT Browser

White Paper
By R. Dan Thompson IV and Randy McLaughlin

Abstract

This white paper provides information and procedures for implementing the Microsoft WindowsNT Browser on Microsoft WindowsNT® 4.0 operating system–based client workstations and servers.

© 1999 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

The BackOffice logo, Microsoft, Windows, and Windows NT are registered trademarks of Microsoft Corporation.

Other product or company names mentioned herein may be the trademarks of their respective owners.

Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA

0599

Contents

Introduction......

MS Browsing Overview......

Microsoft Network Browser System......

How Servers Manage Browsing for Microsoft Networking......

Multiprotocol Considerations......

Master Browser Elections......

Role of Master Browsers......

Role of Backup Browsers......

Role of Domain Master Browsers......

Browser Failures with Microsoft Networking......

How Servers Announce Themselves in Microsoft Networks......

NetBIOS Special Names......

Samples of NetBIOS Special Names......

How Clients Receive Browser Information......

Microsoft TCP/IP and Name Resolution......

NetBIOS over TCP/IP......

Computer Name and Host Name Resolution with NetBIOS over TCP/IP...

WAN Browsing with WINS on an IP Network......

Troubleshooting Browsing......

For More Information......

Appendix A: Browsing in a Switched Environment......

Appendix B: The Multihomed Windows NT Browser

Appendix C: Windows NT Printer Browsing......

Appendix D: Windows NT Browser Components......

Appendix E: Windows NT Browser Registry Options......

Appendix F: windowsNT Browser Error Codes......

Appendix G: Network Layers Involved in Browsing......

MAC Layer......

Network Layer......

NetBIOS Layer......

SMB Layer......

Appendix H: Windows NT Browser Protocol Frames......

Server Type Field......

Host Announcement Frame......

Local Master Announcement Frame......

Domain / Work Group Announcement Frame......

Announcement Request Frame......

Election Frame......

Become Backup Frame......

Get Backup List Request Frame......

Get Backup List Response Frame......

Master Announcement Frame......

Reset Browser State Frame......

Introduction

Maintaining an accurate and efficient browse list on the network is important topic for Microsoft customers. This technical paper provides up-to-date information on Microsoft network browser architecture and reference material for advanced troubleshooting of browsing issues.

The browse list can be accurately maintained in any environment if the browser architecture, capabilities, and the way in which the network topology affects the browser’s ability to gather information on the network are taken into consideration.

Understanding the operation of the browser services available on Microsoft operating systems is critical in effective troubleshooting. For example, the browser service relies on broadcasts when gathering information locally and needs the services of WINS or other name-resolution methods to pass a browse list to remote networks. The details of this process and the methods used are presented in this paper.

This paper should dispel some common misunderstandings about the browse list. The presence or lack of a computer name in the browse list does not give a clear indication of the computer’s status on the network. A delay in gathering a browse list may occur due to various circumstances; however, a system can typically be contacted directly even though it cannot be found in Network Neighborhood. A system missing from the browse list should not be a cause for immediate concern, unless the system is consistently missing.

Although the primary focus of this paper is to give network administrators an understanding of browser architecture, it also deals with troubleshooting situations where the browse list is inaccurate or unavailable.

MS Browsing Overview

Microsoft Network Browser System

The browser is a network resource enumeration tool first created for LAN Manager 1.0. Windows for Workgroups enhanced the browser to make it truly client/server, and finally it was enhanced for domain browsing on a WindowsNT® operating system–based network. The Microsoft networking browser maintains a list called the browse list. The browse list is an enumerationof all the available servers, workgroups, and domains (for WindowsNT and LAN Manager networks). For example, when a user attempts to connect to any network resource, using Network Neighborhood, the list of servers that appears is the browse list. The browse list is provided by a browser in the local computer’s workgroup or domain.

The Microsoft networking browser system consists of a domain master browser, master browsers, backup browsers, and client computers. The domain master browser maintains the complete domain browse list. The master browsers periodically query the domain master browser to obtain a complete list of domain resources. The master browser maintains the browse list and periodically sends copies to the backup browsers. When a browser client needs information, it obtains the current browse list by sending a NetServerEnum2 call to either the master browser or a backup browser.

NetServerEnum2 returns information about the server type (SV_TYPE_SERVER) entries in a domain or workgroup. It allows client computers to view a specific set of servers in the workgroup or domain. NetServerEnum2 provides a server type mask that allows users to query for various types of servers, such as workstations, servers, time servers, domain controllers, and so on. Printer browsing and Windows Terminal Server clients rely on this type of browsing to enumerate their respective resources

This centralized browser architecture for Windows networking resources reduces the number of broadcast datagrams on the network. A datagram is a network packet that is sent to a mailslot on a specified computer (adirected datagram) or to a mailslot on any number of computers (abroadcast datagram). The centralized browser architecture also reduces the demands on the client computer’s CPU and memory.

Note: For Microsoft networking using the Microsoft TCP/IP protocol, broadcast name resolution is a direct implementation of Request for Comments (RFCs) 1001 and 1002 (NetBIOS Service Protocols). This implementation of NetBIOS over TCP/IP is wholly compliant with the RFCs, and does not involve any method of what has been referred to as NetBEUI encapsulation. For more information about NetBIOS over TCP/IP (NetBT), see the discussion of name resolution for Windows-based networking in WindowsNT Server NetworkingGuide.

How Servers Manage Browsing for Microsoft Networking

In a WindowsNT domain, every WindowsNT Server–based computer is a browser. The primary domain controller (PDC), if there is one, is the domain master browser, and the other computers running WindowsNT Server, WindowsNT Workstation, or the Windows®95 operating system are backup browsers. If there is more than one WindowsNT Server–based computer in the domain, no computer running WindowsNT Workstation or Windows95 should ever be a master browser in the domain. In a workgroup containing computers running Windows 95 and WindowsNT Workstation, there is always one master browser. If there are at least two Windows95- or WindowsNT Workstation–based computers in the workgroup, there is also one backup browser. For every 32 computers running Windows95 and WindowsNT Workstation in the workgroup, there is another backup browser. The following section describes how computers become browsers and summarizes the roles played by master and backup browsers.

Multiprotocol Considerations

The browser maintains all of its server information on a per-transport basis. A transport is the physical network card bound to a protocol. When a client application issues a NetServerEnum call, the code running on the workstation enumerates all the serviced networks and forwards the NetServerEnum call to a browser server for that particular transport. When a browser server receives the request, it returns only those servers on the same network from which it received the transaction originally. Therefore, browsing occurs on each transport independently, regardless of other available transports.

Master Browser Elections

Each computer running Windows 95, Windows for Workgroups, WindowsNT Workstation, or WindowsNT Server has configuration settings that determine whether that computer can become a browser. For servers running Windows NT, the value for MaintainServerList for the browser service determines its possible role as a browser. By default, servers are configured to have the potential to become browsers. Unless the server is specifically configured to never be a browser, the Microsoft networking browser service starts automatically when the computer starts, and the server announces itself on the networking using the special NetBIOS name <DOMAIN<1e>.

A master browser election always occurs in the following circumstances:

  • When a computer cannot find its master browser at system startup
  • When a computer determines that a master browser has disappeared
  • When a computer running WindowsNT Server starts (that is, a preferred master browser is started)

When any server needs to force a master browser election, it notifies the other browsers on the system by broadcasting an election datagram that contains the sending browser’s election version and election criteria. The election datagram and subsequent communications are sent to the NetBIOS name <DOMAIN<1e>.

The election version is a constant value that identifies the version of the browser election protocol. If the election versions are identical for both computers, the election criteria are compared. The election criteria consist of a 4-byte hexadecimal value. Specific groups of bytes are masked and their values set according to the following table:

Election Criterion / Value
Operating system type / 0xFF000000
WindowsNT Server / 0x20000000
WindowsNT Workstation / 0x10000000
Windows 95 / 0x01000000
Windows for Workgroups / 0x01000000
Election version / 0x00FFFF00
Per-version criterion / 0x000000FF
Primary domain controller / 0x00000080
WINS client / 0x00000020
Preferred master browser / 0x00000008
Running master browser / 0x00000004
MaintainServerList or BrowseMaster = yes / 0x00000002
Running backup browser / 0x00000001

When a browser receives an election datagram, the receiving browser compares the election version in the datagram with its own. If the receiving browser has a higher election version than any other browser, it is elected, regardless of any other election criteria. For example, a computer running any version of WindowsNT is always elected over a computer running Windows95. If the election versions are identical, the receiving browser compares the election criteria as follows:

  • If the receiving browser has a higher election criterion than the sending browser, the receiving browser issues its own election datagram and enters the election in progress state.
  • If the receiving browser does not have a higher election criterion than the sending browser, the receiving browser attempts to determine which computer is the new master browser.
  • If there is still a tie, the browser that has been running longest is elected. If there is still a tie, the browser that has a lexically lower name is elected. For example, when all other criteria are equal, a server named A1 is elected over a server named B1.

When a browser receives an election datagram indicating that it is elected, the browser enters the running election state. In the running election state, the browser sends an election request after a delay based on the browser’s current browser role:

  • 200 ms delay for master browsers
  • 400 ms delay for backup browsers
  • 800 ms delay for all other browsers

The browser broadcasts up to four election datagrams. If, after four election datagrams, no other browser with an election criterion that would win the election has responded, the browser becomes the master browser. If the browser receives an election datagram indicating that another system would be elected, the browser demotes itself to backup browser. To avoid unnecessary network traffic, a browser that has lost an election does not broadcast any unsent election datagrams.

Role of Master Browsers

The master browser maintains the browse list, which is the list of all servers in the master browser’s domain or workgroup, plus the list of all domains on the network. For a domain that spans more than one subnetwork or broadcast collision zone (Like a V-LAN), the master browser maintains the browse list for the portion of the domain on its subnetwork or broadcast collision zone. The rest of the domain is known based on domain announcements made by the domain master browser. Individual servers running WindowsNT Server, WindowsNT Workstation, Windows95, Windows for Workgroups, or LAN Manager announce their presence by sending a directed datagram called a server announcement(HostAnnouncement) datagram to the domain or workgroup’s master browser. This announcement includes the server’s NetBIOS name of <01<02>MSBROWSE<02<01>, <DOMAIN<1d>, or <DOMAIN<1e>, as appropriate for the type of server. When the master browser receives a server announcement from a computer, it adds that computer to the browse list. The master browser then returns lists of backup browsers to computers running WindowsNT Server, WindowsNT Workstation, Windows 95, and Windows for Workgroups. When a computer starts that is configured to automatically become a browser if required, the current master browser must tell that computer whether to become a backup browser. If its browse list is empty when a computer first becomes a master browser, it can force all servers to register with it by broadcasting an announce request (AnnouncementRequest)datagram. All computers receiving this datagram must respond by sending a server announcement at a random time within the next 30 seconds. The randomized delay ensures that the network and the master browser itself are not overwhelmed with responses. When a master browser receives a server announcement from another computer that claims to be the master browser, the receiving master browser demotes itself and forces an election as described in the previous section. This ensures that there is always only one master browser in each domain or workgroup.

Role of Backup Browsers

Backup browsers call the master browser every 15 minutes to get the latest copy of the browse list, as well as a list of domains. Each backup browser caches these lists and returns the list of servers to any clients that send a remote NetServerEnum call to the backup browser. If the backup browser cannot find the master browser, it forces an election.

Role of Domain Master Browsers

The browser service running on a domain’s primary domain controller (PDC) has the special additional role of being the domain master browser. The PDC of a domain has a bias in browser elections to ensure that it becomes the master browser. On networks using TCP/IP where a domain spans more than one subnetwork, each subnetwork functions as an independent browsing entity, with its own master browser and backup browsers. Name-query datagrams should not cross routers. When routers or switches are misconfigured and propagate UDP port 137 and 138 broadcasts, large numbers of event 8003 appear in the event log. For more information, see the following Knowledge Base articles:
Q135464 - 8003 Browsing Errors with UDP Forwarding and

Q190930 - UDP Broadcast Forwarding by Cisco's IP Helper.

To browse across the wide area network (WAN) to other subnetworks, at least one browser running WindowsNT Server is required on the domain for each subnetwork. On the subnetwork where the PDC is located, this WindowsNT Server–based computer is usually the PDC, which functions as the domain master browser. When a domain spans multiple subnetworks, the master browser for each subnetwork announces itself as the master browser to the domain master browser by sending a directed MasterAnnouncement datagram, using the computer’s NetBIOS <DOMAIN<1d>. The domain master browser then sends a remote NetServerEnum call to each master browser to collect each subnetwork’s list of servers. The domain master browser merges the server list from each subnetwork master browser with its own server list to form the browse list for the domain. This process is repeated every 15 minutes to ensure that the domain master browser has a complete browse list of all the servers in the domain.

The master browser on each subnetwork also sends a remote NetServerEnum call to the domain master browser to obtain the complete browse list for the domain. This complete browse list is thus available to browser clients on the subnetwork.

Note: Microsoft networking workgroups cannot span multiple subnetworks. Any workgroup that spans subnetworks actually functions as two separate workgroups with identical names. To span multiple collision zones, a Windows NT domain must exist.

Browser Failures with Microsoft Networking

A failed server stops announcing itself. When the master browser does not receive a server announcement for three of the server’s current announcement periods, the master browser removes that server from the browse list. It might take up to an additional 15 minutes for the backup browsers to retrieve the updated browse list from the master browser, so it could take as long as 51 minutes from the time a server fails to the time when it is removed from all browse lists.

Because a backup browser announces itself in the same way as a server, the procedure when a backup browser fails is the same as that for a server. If the name of this backup browser has been given to any clients, attempts made by those clients to contact this backup browser fail. The client then retries the NetServerEnum call on another backup browser on the client’s list of browsers. If all the backup browsers that a client knows have failed, the client attempts to get a new list of backup browsers from the master browser. If the client is unable to contact the master browser, it forces a browser election. The client then returns an error to the application, indicating that the master browser could not be found.

When a master browser fails, the backup browsers detect the failure within 15 minutes. The first backup browser to detect the failure forces an election to select a new master browser. Between the time that the master browser fails and the time that a new master browser is elected, the domain could disappear from the list of domains in the browse list. If a client performs its first NetServerEnum call after the old master browser has failed but before a backup browser detects the failure, the client forces an election. If a master browser fails and there are no backup browsers, browsing in the workgroup or domain does not work correctly.