Share via


MS Windows NT Browser

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By R. Dan Thompson IV, Randy McLaughlin

Server Operating System

Abstract

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

On This Page

Introduction
MS Browsing Overview
Microsoft TCP/IP and Name Resolution
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: windows NT Browser Error Codes
Appendix G: Network Layers Involved in Browsing
Appendix H: Windows NT Browser Protocol Frames

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 Windows NT® operating system–based network. The Microsoft networking browser maintains a list called the browse list. The browse list is an enumeration of all the available servers, workgroups, and domains (for Windows NT 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 (a directed datagram) or to a mailslot on any number of computers (a broadcast 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 Windows NT Server NetworkingGuide.

How Servers Manage Browsing for Microsoft Networking

In a Windows NT domain, every Windows NT 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 Windows NT Server, Windows NT Workstation, or the Windows® 95 operating system are backup browsers. If there is more than one Windows NT Server–based computer in the domain, no computer running Windows NT Workstation or Windows 95 should ever be a master browser in the domain. In a workgroup containing computers running Windows 95 and Windows NT Workstation, there is always one master browser. If there are at least two Windows 95- or Windows NT Workstation–based computers in the workgroup, there is also one backup browser. For every 32 computers running Windows 95 and Windows NT 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, Windows NT Workstation, or Windows NT 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 Windows NT 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

Windows NT Server

0x20000000

Windows NT 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 Windows NT is always elected over a computer running Windows 95. 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 Windows NT Server, Windows NT Workstation, Windows 95, 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 Windows NT Server, Windows NT 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:

135464 - 8003 Browsing Errors with UDP Forwarding and

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

To browse across the wide area network (WAN) to other subnetworks, at least one browser running Windows NT Server is required on the domain for each subnetwork. On the subnetwork where the PDC is located, this Windows NT 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.

When a domain master browser fails, other master browsers see only servers on their own local subnetwork. Eventually, all servers that are not on the local subnetwork are removed from the browse list.

How Servers Announce Themselves in Microsoft Networks

When a server is started, it announces itself by sending a host announcement to the master browser every minute. This announcement uses the special NetBIOS name of <DOMAIN><1d>. As the computer continues running, the time between server announcements is increased until it eventually becomes once every 12 minutes. If the master browser has not received a server announcement from a computer for three announcement periods, the computer is removed from the browse list. Therefore, there might be up to a 36-minute delay between the time that a server goes down and the time that it is removed from the browse list. Client computers sometimes need to retrieve lists of domains, as well as lists of servers in those domains. To support this, when a browser becomes a master browser, it broadcasts a DomainAnnouncement datagram every minute for the first five minutes, and then broadcasts once every 15 minutes after that. Master browsers in domains and workgroups announce their presence to the special NetBIOS name of <01><02>MSBROWSE<02><01> and register their names with this group. Master browsers on other domains receive these DomainAnnouncement datagrams and add the specified domain to the browse list.

DomainAnnouncement datagrams contain the name of the domain, the name of the domain master browser, and whether the master browser is running Windows NT Server, Windows NT Workstation, or Windows 95. If the master browser is running Windows NT Server, the datagram also specifies whether that browser is the domain's PDC. If a domain has not announced itself for three consecutive announcement periods, the domain is removed from the browse list. Therefore, a domain might be down for as long as 45 minutes before it is removed from the browse list. When a master browser is shut down correctly, it sends a ForceElection broadcast so that a new master browser can be elected. When a backup browser is shut down correctly, it sends an announcement to the master browser that it is shutting down. To do this, it sends a server announcement that does not include the browser service in the list of running services.

NetBIOS Special Names

In a LAN environment using any protocol or combination of protocols, all Microsoft network browsing activities are maintained using broadcasts and special NetBIOS names that identify the type of resource. All browsing services are provided on a per-protocol basis to prevent, for example, a NetBEUI-only client from enumerating a TCP/IP-only server in the process of querying the browser. The NetBIOS name space is not hierarchical, so all names must be unique on the network. Resources are identified by NetBIOS names, which are registered dynamically when the computer starts, a service starts, or a user logs on. The special NetBIOS names used in Microsoft networking are indicated by adding a hexadecimal value as a sixteenth byte at the end of the 15-character computer name or domain name. If the computer or domain name is less than 15 characters, spaces are used to pad the name to the sixteenth byte. The discussion of browsing in this paper uses the special NetBIOS names to explain how names are registered and resolved for browsing on Microsoft networks. The following table shows some of these special names:

Samples of NetBIOS Special Names

Special Name

Description

Registered unique user name:

 

<USERNAME><03>

Used to register the name of the user currently logged on in the WINS database so that users can receive net send commands sent to their user names

Registered unique computer names:

 

<COMPUTER><00>

Used by Microsoft networking workstations to receive second-class mailslot requests. All workstations must add this name to receive mailslot requests. This is the computer name registered for workstation services by a WINS client.

<COMPUTER><03>

Used as the computer name that is registered for the messenger service on a computer that is a WINS client.

<COMPUTER><20>

Used as the name that is registered for the server service on a Windows NT–based computer that is a WINS client.

<COMPUTER><Be>

Used as the unique name that is registered when the Network Monitor agent is started on the computer.

<COMPUTER><Bf>

Used as the group name that is registered when the Network Monitor agent is started on the computer. If this name is not 15 characters in length, it is padded with plus (+) symbols

<COMPUTER><1f>

Used as the unique name that is registered for network dynamic data exchange (DDE) when the NetDDE service is started on the computer.

Registered group names:

 

<01><02>MSBROWSE<02><01>

Used by master browser servers to periodically announce their domain on a local subnet. This announcement contains the domain name and the name of the master browser server for the domain. In addition, master browser servers receive the domain announcements sent to this name and maintain them in their internal browse list along with the announcer's computer name.

<DOMAIN><00>

Used by workstations and servers to process server announcements to support Microsoft LAN Manager. Servers running Windows 95, Windows NT, Windows NT Server, and Windows for Workgroups do not broadcast this name unless the LMAnnounce option is enabled in the server's properties.

<DOMAIN><1b>

Used to identify the domain master browser name, which is a unique name that only the primary domain controller (PDC) can add. The PDC processes GetBrowserServerList requests on this name. WINS assumes that the computer that registers a domain name with the <1b>character is the PDC. The 1B entry is resolved to when NetGetDcName is called.

<DOMAIN><1c>

Used for the internet group name, which the domain controllers register. The internet group name is a dynamic list of up to 25 computers that have registered the name. This is the name used to find a Windows NT domain controller for pass-through authentication. The 1C entry is resolved to when NetGetAnyDcName is called.

<DOMAIN><1d>

Used to identify a segment master browser (not a domain master browser). The master browser adds this name as a unique NetBIOS name when it starts. Workstations announce their presence to this name so that master browsers can build their browse list.

<DOMAIN><1e>

Used for all domain-wide announcements by browser servers in a Windows NT–based server domain. This name is added by all browser servers and potential servers in the workgroup or domain. All browser election packets are sent to this name.

The following example shows a sample NetBIOS name table for a Windows NT 4.0 primary domain controller (PDC), based on the list that appears if you type nbtstat -n at the command prompt. This example shows the sixteenth byte for special names, plus the type of NetBIOS name (unique or group).

Node IpAddress: [157.56.60.111] Scope Id: []
      NetBIOS Remote Cache Name Table
   Name               Type         Status
---------------------------------------------
DOMAINPDC      <00>  UNIQUE      Registered
DOMAINPDC      <20>  UNIQUE      Registered
DOMAINNAME     <00>  GROUP       Registered
DOMAINNAME     <1C>  GROUP       Registered
DOMAINNAME     <1E>  GROUP       Registered
DOMAINPDC      <03>  UNIQUE      Registered
DOMAINPDC      <1B>  UNIQUE      Registered
DOMAINPDC      <1D>  UNIQUE      Registered
..__MSBROWSE__.<01>  GROUP       Registered

In this example, several special names are identified for the Windows NT Primary Domain Controller (DOMAINPDC in the previous example) and the domain (DOMAINNAME), including the following:

  • computer\0x00 (shown as <00> in the example) indicates the computer name associated with the Workstation service.

  • computer\0x20 (shown as <20> in the example) indicates the computer name associated with the Server service.

  • domain\0x00 indicates the domain to which this computer belongs.

  • domain\0x1c indicates that the computer is a domain controller.

  • domain\0x1e indicates that this computer can serve as a backup browser in this domain.

  • computer\0x03 indicates the computer name associated with the Messenger service.

  • computer\0x1b indicates that this computer is the domain master browser.

  • computer\0x1d indicates that this computer is the segment master browser.

  • ..__MSBROWSE__.\0x01 indicates that this computer is the segment master browser.

How Clients Receive Browser Information

When an application running on a client computer makes a NetServerEnum call, the client sends the call to a browser. If this is the first time this call has been made by an application on this client, the client must first determine which computers are the browsers in its workgroup or domain. This datagram is in the form of a Get Backup List Request datagram sent to the special NetBIOS <DOMAIN><1d> name that the master browser has registered. This request is processed by the master browser for the client's domain and subnetwork. The master browser then returns a list of browsers active in the workgroup or domain being queried, via the Get Backup List Response datagram. The client selects the names of three browsers from the list, and then stores these names for future use. The client computer randomly chooses a browser from one of the three browser names and calls NetServerEnum, requesting a list of servers or domains. The browser server returns the list to the client, which then can be displayed in Network Neighborhood.

If the user selects a domain name in the browse list, a new set of browser servers must be found for the new domain. In this case, a Get Backup List Request frame is sent to the new domain name. After a user selects a server, the browser is no longer involved in the process of contacting the server for a list of available resources. The transport protocols on the client computer use whatever name resolution methods are available to find and connect to the server. When the client workstation attempts to connect to a server, a NetBIOS session is established between the two computer names. For example, when a Windows NT–based client workstation on an IP network connects to a Windows NT Server, the following occurs:

  • The NetBIOS name for the server is resolved to an IP address.

  • A TCP connection is established from the client to the server.

  • The client sends a NetBIOS session request to the server name over the TCP connection.

  • The server responds affirmatively, and the session is established.

  • The client and server negotiate a higher-level protocol to use over the NetBIOS session.

Only one NetBIOS session at a time is established between two computers. Additional connections for file or printer sharing are multiplexed over the same NetBIOS session.

Microsoft TCP/IP and Name Resolution

All computers are on the same wire in the LAN environment, so a user can browse all workgroups and domains because the network client can communicate directly with all master browsers. Multiple workgroups and domains can coexist on a LAN without incident because both the unique and group NetBIOS names depend on the name of the workgroup or domain. Name resolution becomes more complex in the WAN IP environment, however, because the broadcasts and messages used for name resolution are not forwarded across routers automatically on TCP/IP networks. This section summarizes name resolution issues related to WAN browsing, depending on whether Windows NT–based WINS servers are available in the enterprise.

NetBIOS over TCP/IP

Microsoft TCP/IP uses NetBIOS over TCP/IP, as specified in RFC 1001 and RFC 1002, which define a software interface that supports name resolution for NetBIOS client and server programs in the WAN environment. All Microsoft networking products use NetBIOS over TCP/IP for registering and locating NetBIOS resources on IP networks. The various methods used for name resolution include the following:

  • NetBIOS name cache

  • NetBIOS name servers (implemented as WINS for Windows NT networks)

  • IP subnet broadcasts

  • Static LMHOSTS files

  • Static HOSTS files

  • DNS servers

The order of methods use for NetBIOS name resolution depends on the node type (as defined in RFC 1001/1002) and the particular computer configuration for TCP/IP. The following are the node types:

  • B-node, which uses broadcasts to resolve names

  • P-node, which uses point-to-point communications with a NetBIOS name server to resolve names

  • M-node, which uses broadcasts first (b-node), and then name queries (p-node) if broadcasts are not successful

  • H-node, which uses name queries first (p-node), and then broadcasts (b-node) if the name server is unavailable or if the name is not registered in the WINS database

If WINS is enabled on a Windows 95 computer, the system uses h-node by default. Without WINS, the system uses b-node by default. To see which node type is configured on a Windows NT–based computer, check the value for NodeType in the following registry key:

Hkey_Local_Machine \System \CurrentControlSet \Services \NetBT \Parameters \NodeType
Value Type: REG_DWORD - Number
Valid Range: 1,2,4,8 (b-node, p-node, m-node, h-node)
Default: 1 or 8 based on the WINS server configuration

For more information, see the following Knowledge Base article:

160177: Default Node Type For Microsoft Clients ID.

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

The following diagrams summarize the methods for attempting name resolution with TCP/IP.

Cc767893.ntbrow01(en-us,TechNet.10).gif

Cc767893.ntbrow02(en-us,TechNet.10).gif

WAN Browsing with WINS on an IP Network

WINS solves two problems for browsing in the WAN: the building of a comprehensive domain list and name resolution for members within a domain or workgroup. The following list summarizes issues for browsing in a WAN environment with WINS:

  • Workgroups still cannot span subnetworks because they have no equivalent to the domain master browser.

  • The process of building domain lists uses the WINS database and domain\0x1b names to locate the domain master browser. Workgroup lists are still based on members' announcing their presence periodically. For example, an isolated workgroup on an island subnet with no domain members is invisible to the WAN until a domain member is added that shares the presence of the subnet.

  • The ability to expand a workgroup or domain depends on the ability to resolve the master browser's computer name. If WINS-enabled computers are running in workgroups and domains, this is adequate.

  • The ability to connect to a resource in a workgroup depends on the ability to resolve the resource's name. Again, WINS-enabled computers support this adequately. It is possible to connect to a resource that you cannot browse and to browse a resource that you cannot connect to.

Tip for browsing with WINS Because of how PDCs register the domain\0x1b entry with WINS, ensure that all clients and servers are members of a domain.

The unique NetBIOS name of domain\0x1b that the PDCs register is treated specially by WINS and is used to build a table of all domains on a WAN network. The browser on the client periodically connects to WINS and learns of all the systems that registered the domain\0x1b name. The browser then uses a NetGetDCName call on each of the domain\0x1b names, followed by an attempt on the domain\0x1c names. The browser then adds the domain master browser's name to its domain and workgroup list. This eliminates the need to strategically place workgroup or domain members on subnets to ensure that comprehensive domain and workgroup lists are built. With WINS, the domain\0x1e name registration is ignored and treated as a normal group name. This forces browser elections to remain on subnetworks, rather than extending elections to the WAN. This increases fault tolerance and reduces periodic network-wide traffic. The same is true for the domain\0x1d and <01><02>MSBROWSE<02><01> group names. This also reduces the scope of the announcement broadcasts on the subnetwork. The unique domain\0x1b name and the internet group domain\0x1c name are maintained by WINS and are used during logon and for NetGetAnyDCName calls.

Troubleshooting Browsing

While there is no centralized method to determine if the browse lists across the WAN are complete, there are techniques to determine if the servers on a particular segment are represented in the browse list on a remote segment. These techniques can be applied on all segments throughout the WAN, but the results of these tests can vary due to the roles of the servers changing when browser elections occur. Only if all the servers in a domain throughout the WAN are completely static and no servers come on or off-line, do the results of these tests have meaning over time. The tests described in this section rely on the Windows NT Resource Kit utility Browstat.exe. Example output is for the TCP/IP protocol only. Also, as with most network problem diagnosis, to troubleshoot the browser service the administrator must have full knowledge of the network segment boundaries, switches, and router configurations on the network. For example, if a client on a remote segment does not have a server in its browse list that is located on another segment, it is not advisable start troubleshooting until after the 48-minute cycle described above has passed. Remember that name resolution between all browsers is critical, and it is most important to establish a robust name resolution infrastructure with WINS. For browsing to work, name resolution must be functional.

The following are the steps to take in troubleshooting on the network.

  1. Find the master browser on the segment where the server resides.

    The following command must be executed on the segment where the missing server resides:

BROWSTAT STATUS Status for domain <DomainName> on transport \Device\NetBT_IEEPRO1 Browsing is active on domain. Master browser name is: <MasterBrowser> Master browser is running build 1381 1 backup servers retrieved from master <BackupBrowser> \SmallerServer There are 100 servers in domain DomainName on transport \Device\NetBT_IEEPRO1 There are 1500 domains in domain DomainName on transport \Device\NetBT_IEEPRO1

This should tell you which server is acting as the master browser on the segment. If the local master browser is slow to respond, you may have received this information from another master browser.

The results of this command gives you the "\\Device\\Protocol\_NIC" string and can be used with other Browstat commands.

To find the local master browser on the client's segment, execute the following:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

BROWSTAT GETMASTER \Device\NetBT_El59x1 <DomainName>

Using the Status or Getmaster switch issues a DomainName\<1d\> query and returns the current master browser for that segment.

Now you must determine which master browser is on the segment that contains the missing server's name. If a master browser cannot be found, you can force an election by stopping and starting the browser service on a domain controller that is on the server's segment. In a few minutes, re-run this test. Alternatively, on the console of a server on the server's segment you can force an election by executing the following command:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

BROWSTAT ELECT \Device\NetBT_IEEPRO1 <DomainName>.

  1. Does the master browser have the server's name in its list?

    The master browser is the first server in the chain of communication that must contain the missing server's name. This test determines if the master browser has received the server's Host Announcement frame. Note that the "\device…" string is obtained from the output above. Execute the following:

BROWSTAT VIEW \Device\NetBT_IEEPRO1 \<MasterBrowser> | FINDSTR /i <MissingServer>

If the master browser has the server in its list, the command returns something similar to the following:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

\<MissingServer> NT 04.00 (W,S,NT,PBR,DFS)

If the local master browser does not have the server's name, the following can be executed from any computer on the missing server's segment:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

BROWSTAT FORCEANNOUNCE \Device\NetBT_El59x1 <DomainName>

Or the following can be executed from the missing server's console:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

BROWSTAT ANNOUNCE \Device\NetBT_El59x1 <DomainName>

It may be useful to verify that the missing server can map a network drive to the master browser to verify network connectivity. Also, the server can be rebooted to force a Host Announcement frame.
  1. Does the PDC receive the server's name from the master browser?

    Execute the following:

BROWSTAT VIEW \Device\NetBT_IEEPRO1 \<PDC> | FINDSTR /i <MissingServer>

The output should be similar to the following:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

\<MissingServer> NT 04.00 (W,S,NT,PBR,DFS)

If the server's name is missing, this is probably due to name resolution problems. For the PDC to obtain the list of servers from the master browser, the server's master browser must be able to resolve the DomainName\<1b\> name so that it can send the directed Master Announcement frame, using UDP port 138. For the PDC to respond to this announcement to obtain the server's name, it must be able to resolve the master browser's computer name. (For the server's master browser to obtain the domain-wide list from the PDC, it too must be able to resolve the PDC's computer name.) Name resolution in both directions is critical. To verify that the server's master browser can resolve the DomainName\<1b\> entry, execute the following:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

BROWSTAT GETPDC \Device\NetBT_El59x1 <DomainName>

To verify that both the PDC and the master browser can resolve each other's computer names, map a network drive from the master browser to the PDC and from the PDC to the master browser. If any of these steps fail, resolve the name resolution problem.
  1. Which is the master browser on the client's segment?

    This is done using the same steps as in number 1 above, but is executed on the client's segment.

  2. Does the master browser have the missing server's name?

    Execute the following:

BROWSTAT VIEW \Device\NetBT_IEEPRO1 \<MBClientSeg> | FINDSTR /i <MissingServer>

If the server has the entry, the output should be similar to the following:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

\<MissingServer> NT 04.00 (W,S,NT,PBR,DFS)

If the master browser does not have the missing server's name, it is probably due to a name resolution problem. Verify that the master browser on the client's segment is able to resolve the DomainName\<1b\> name by executing the following:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

BROWSTAT GETPDC \Device\NetBT_El59x1 <DomainName>

The master browser must be able to resolve the computer name of the PDC. To verify this, map a network drive to the PDC. If either of these tests fail, resolve the name resolution problem.
  1. Which are the backup browsers on the client's segment?

    To reduce demands on the segment master browser, when a client requests a browse list, it chooses a backup browser, if one is available. Therefore, it is more likely that all clients will use backup browsers. There are two ways to determine the local backup browsers for this segment. From the master browser's console, execute the following:

BROWSTAT LOCALLIST \Device\NetBT_IEEPRO1 | FINDSTR /i BBR

This returns a list of entries similar to the following:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

\<BackupBrowser> NT 04.00 (W,S,BDC,NT,BBR,DFS)

To have the master browser perform this command remotely, execute the following:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

BROWSTAT VIEW \Device\NetBT_IEEPRO1 \<MasterBrowser> 0X40000000 | FINDSTR /I BBR

**Note:** These flags are defined in Appendix H.
  1. Do the backup browsers have the missing server's name?

    For all clients on this segment to retrieve a reliable browse list, every backup browser must be checked for the missing server's name. For each backup browser, execute the following:

BROWSTAT VIEW \Device\NetBT_IEEPRO1 \<BackupBrowser> | FINDSTR /i <MissingServer>

If a backup browser does not contain the missing server's name, verify that the backup browser can map a network drive to the master browser. The backup browser role is the most dynamic browser role. Master browsers instruct potential browsers to become backup browsers, depending on the browser load.
  1. Other considerations:

    To avoid experiencing intermittent browser functioning and having to perform these tests, you may need to dedicate computers on each segment to maintain a consistent domain-wide list. If servers are frequently shut down and restarted, consider placing a BDC if the number of segments is not large, or at minimum a Windows NT Member Server on each segment with the IsDomainMaster registry setting set to true. This gives the server an edge during elections in becoming the master browser for the segment.

For all the previous steps, if none of the suggestions allow you to proceed to the next step, verify that none of the browser servers that you have identified have a "name in conflict" error. This can be seen by executing the following:

NBTSTAT –n

This command can be performed remotely by using either the –A or –a switch.

The browser is very sensitive to the configuration of the routers throughout the WAN. Since the browser roles are determined by broadcast elections, UDP broadcasts must not be forwarded. Unpredictable behavior can occur if UDP broadcast traffic is forwarded in one direction but not the other. This may generate 8003 Browser events, causing a continuous cycle of elections.

Additionally you can resolve problems with a protocol analyzer such as the Microsoft Network Monitor. To view the browser exchanges directly, the browser service can be stopped, and then restarted. Unfortunately, there is no guarantee that a browser will assume the same role that it had before stopping and starting the browser service. However, this method can be especially useful to verify the communication when the master browser requests the domain-wide list from the PDC, and immediately following when the PDC requests the local list from the master browser. After the browser service has started on the master browser, the full exchange should take place within one or two minutes. Configure the protocol analyzer's capture buffer and frame size settings to allow for this quantity of traffic. The list of servers returned by the browse service prior to Windows NT 4.0 was limited to 64 KB in size. When this size is exceeded, the user sees a truncated alphabetical list of servers. To avoid this behavior, all browsers must be running Windows NT version 4.0 or later.

For More Information

For the latest information on Windows NT Server, check out Microsoft TechNet or visit our World Wide Web site at https://www.microsoft.com/ntserver and the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS).

Appendix A: Browsing in a Switched Environment

Throughout this discussion of the Windows NT Browser, browsing has been discussed in terms of a routed LAN environment. This section covers how LAN switching affects the browser service.

LAN switching is a technology that replaces hubs and shared media with a switch. A switch is a device that operates at layer 2 and/or layer 3 of the OSI model, building dedicated segments between two computers, thus eliminating the congestion associated with shared media. The net effect of switches is increased bandwidth to the desktop. LAN switching builds upon the concept of microsegmentation, or the ability to provide a dedicated segment to the desktop. Each port on the switch provides that dedicated segment. Switches working at layer 2 of the OSI model have the ability to build tables that associate a specific port with MAC addresses, which then allows packets to be forwarded directly to the appropriate port.

A connection can be dynamically generated between two ports on the same switch or directly from a specific port to the default gateway. Switches can have multiple data streams passing through them simultaneously. However, when a switch receives a broadcast or multicast packet, the switch must flood all of the ports except the originating port. This is a technique known as broadcast flooding. Under this circumstance the switch is operating like a simple bridge, and a network that is built only on switch technology appears flat. A flat network is a network that is comprised of only one broadcast collision domain. A network that is reduced to one collision domain is susceptible to broadcast storms and does not scale well.

Modern switches support VLANs as a mechanism to administer and scale switched networks. The VLAN in its simplest form is a grouping or collection of specified ports that form a single collision domain. Advanced VLAN configurations can be defined on a per-protocol basis or even by a user-defined specification. VLANs provide a great amount of flexibility in designing collision domains.

Browsing in a switched environment follows the same principles that were established in the previous sections of this paper. Additionally, you should consider the impact of VLAN design on the collision domains. Do the VLANs map to the IP subnets or not? The same steps that were discussed in the troubleshooting browsing section still apply, but they must be extended to include the VLANs as collision domains. You can no longer just consider physical segments as collision domains; a VLAN may be the new broadcast boundary.

Appendix B: The Multihomed Windows NT Browser

For the PDC to build a single domain-wide list, it cannot be a multihomed server. Each master browser on remote segments establishes a connection to the PDC. Since there is no guarantee that every master browser will choose the same interface on the PDC, the PDC must be single-homed so that a single domain-wide list can be built. Also, all master browsers must also be single-homed. Every 12 minutes, the master browser connects to the PDC and requests the domain-wide list. The master browser then issues a Master Announcement Browser frame to the PDC, telling it to connect to the master browser and obtain its local lists. Since the PDC does not maintain separate IP addresses for each interface on the master browser, when the PDC connects to the master browser, it obtains only the list of computers and servers collected on that particular interface.

Windows NT 4.0 provides a new registry parameter that allows the computer browser service to be disabled on one or more network interfaces. When the UnboundBindings registry parameter is added, it enables a multihomed domain master browser to provide a comprehensive browse list to computers on all subnets.

For more information, see the following Knowledge Base articles:

  • 158487: Browsing Across Subnets w/ a Multihomed PDC in Windows NT 4.0

  • 133241: Browsing Domain Master Browsers w/ Multiple NICs and Protocols

  • 135404: Multihomed Master Browser May Cause Event ID 8021 and 8032

Appendix C: Windows NT Printer Browsing

Windows NT allows the familiar browsing mechanism found in File Manager to enumerate printers for remote printing. This appendix describes the mechanism used for print browsing in a Windows NT–based environment and the registry keys that affect its behavior.

Shared printers are found when a user browses for a printer in a domain. A remote procedure call (RPC) (EnumPrinters) is made to the browse master. The RPC returns only the computers in the browse list that have set the printer flag (SV_TYPE_PRINT) in their host announcements.

The following is a network trace fragment that illustrates a client browsing a Windows NT Print Server:

Client request:

SMB: C transact TransactNmPipe, FID = 0x80a
MSRPC: c/o RPC Request: call 0x1  opnum 0x0  context 0x0  hint 0x364
R_WINSPOOL: RPC Client call winspool:RpcEnumPrinters(..)
R_WINSPOOL: DWORD Flags = 64 (0x40)
R_WINSPOOL: STRING_HANDLE Name = \\NTSERVER
R_WINSPOOL: DWORD Level = 1 (0x1)
R_WINSPOOL: LPBYTE pPrinterEnum [..] = 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00...
R_WINSPOOL: DWORD cbBuf = 804 (0x324)

Server response:

SMB: R transact TransactNmPipe (response to frame 89)
MSRPC: c/o RPC Response: call 0x1 context 0x0 hint 0x338 cancels 0x0
R_WINSPOOL: RPC Server response winspool:RpcEnumPrinters(..)
R_WINSPOOL: LPBYTE pPrinterEnum [..] = 08 00 00 00 DA 02 00 00 B4 02 00 00
B2 02 00 00 08 00 00 00 58 02 00...
R_WINSPOOL: LPDWORD pcbNeeded = 460 (0x1CC)
R_WINSPOOL: LPDWORD pcReturned = 3 (0x3)
R_WINSPOOL: Return Value = 0 (0x0)
The network trace above shows the network client receiving back a 
response from the server containing information from the RPC call 
EnumPrinters.(Additional information on this function is available in the 
Win32 SDK.)

Windows NT Server- and Workstation–based computers update the browse master by default every 10 minutes with print share information. This is done by the AddPrinter function.

The following is a network trace fragment that demonstrates a client enumerating shared resources to the print browse master:

SMB: C transact TransactNmPipe, FID = 0x200c
MSRPC: c/o RPC Request: call 0x1  opnum 0x5  context 0x0  hint 0x11C
R_WINSPOOL: RPC Client call winspool:RpcAddPrinter(..)
R_WINSPOOL: STRING_HANDLE pName = \\NTSERVER
R_WINSPOOL: PPRINTER_CONTAINER pPrinterContainer {..}
R_WINSPOOL: DWORD Level = 1 (0x1)
R_WINSPOOL: (Untyped 1) PrinterInfo {..}
R_WINSPOOL: Switch Value = 1 (0x1)
R_WINSPOOL: LPPRINTER_INFO_1W pPrinterInfo1 {..}
R_WINSPOOL: DWORD Flags = 24 (0x18)
R_WINSPOOL: LPWSTR pDescription = 35780264 (0x221F6A8)
R_WINSPOOL: LPWSTR pName = 35781864 (0x221FCE8)
R_WINSPOOL: LPWSTR pComment = 12163832 (0xB99AF8)
R_WINSPOOL: LPWSTR pDescription = \\NTCLIENT\Lexmark Optra PS,Lexmark Optra PS,
R_WINSPOOL: LPWSTR pName = \\NTCLIENT\Lexmark Optra PS
R_WINSPOOL: LPWSTR pComment =
R_WINSPOOL: PDEVMODE_CONTAINER pDevModeContainer {..}
R_WINSPOOL: DWORD cbBuf = 0 (0x0)
R_WINSPOOL: LPBYTE pDevMode = 0 (0x0)
R_WINSPOOL: PSECURITY_CONTAINER pSecurityContainer {..}
R_WINSPOOL: DWORD cbBuf = 0 (0x0)
R_WINSPOOL: LPBYTE pSecurity = 0 (0x0)

The following is a list of registry entries that manipulate client and server behavior in regard to print browsing:

  • HLM\SYSTEM\CurrentControlSet\Control\Print

    DisableServerThread – REG_DWORD

    Range: 0 or 1

    Default: 0 (false)

    Set this to 1 (true) to disable the browse thread on the current computer. This thread is used to call other print servers to notify them that this printer exists.

  • ServerThreadTimeout – REG_DWORD

    Range: Milliseconds

    Default: 36,000 (36 seconds)

    Specifies the amount of time that the ServerThread sleeps before it calls all the other print servers to notify them of the printers on this computer.

  • NetPrinterDecayPeriod – REG_DWORD

    Range: Milliseconds

    Default: 3,600,000 (1 hour)
    Specifies how long to cache a network printer. The cache is used to present the list of printers when the browse dialog is used.

  • RefreshTimesPerDecayPeriod – REG_DWORD

    Range: 1–5

    Default: 2

    Specifies how many times to inform the browse masters and backup servers per decay period. The default value is two times per hour. Do not set a 0 value if you specify both RefreshTimesPerDecayPeriod and ServerThreadTimeout; the system waits for the maximum of either the ServerThreadTimeout or the RefreshTimesPerDecayPeriod.

Appendix D: Windows NT Browser Components

Cc767893.ntbrow03(en-us,TechNet.10).gif

At system startup, the Windows NT Service Controller starts Services.exe (formerly Lmsvcs.exe, the LanmanServer service). For each service under its control, Services.exe creates a thread that begins execution at the service's service routine entry point. The browser service's service routine, in Browser.dll, proceeds as follows:

  1. Registers a service control routine for the browser service stop, pause, and continue

  2. Initializes the service from any hard-coded, registry, or command-line parameters

  3. Sends initialization information to the kernel mode datagram receiver (Browser.sys/Rdr.sys) code

  4. Starts the thread that does the actual work of the service

Browser.dll is a user mode component responsible for maintaining the browse list, forwarding APIs, and managing the various roles of the browser. When using Wnet functions to browse Windows NT network resources, the functions resolve, by the NTLM API (NETAPI32.DLL), to the NTLM service DLL Browser.dll. Browser.dll uses an internal API to work with the kernel mode NTLM datagram receiver to carry out the requested resource browsing functions. Both Lmsvcs.exe and Services.exe can be found under \<Winnt root>\System32 for their respective operating system versions.

The kernel mode portion of the browser functions as a datagram and remote mailslot receiver (second-class datagram-based mailslot messages). Datagrams of interest to browser services include NetServerEnum. In Windows NT 3.1, the kernel mode functions resided in Browser.sys, but for Windows NT 3.5x and Windows NT 4.0 these functions are incorporated into Rdr.sys.

All browser datagrams destined for computers running LAN Manager, Windows for Workgroups–, Windows 95–, Windows NT Workstation–, or Windows NT Server–based computers are sent to the mailslot name \Mailslot\Lanman. Browser datagrams destined only for computers running Windows NT Workstation or Windows NT Server are sent to the mailslot name \Mailslot\Msbrowse. Both Browser.sys and Rdr.sys are located in \<Winnt root>\System32\Drivers.

Appendix E: Windows NT Browser Registry Options

  • HLM\SYSTEM\CurrentControlSet\Services\Browser\Parameters MaintainServerList – REG_SZ

    Range: Yes, No, and Auto

    Default: Auto

    If this value is No, this server is not a browser.

    If this value is Yes, this server becomes a browser. It attempts to contact the master browser to get a current browse list. If it cannot find the master browser, it forces an election and is, of course, a candidate to become the master. In addition, setting MaintainServerList to Yes causes an election to be generated when the browser starts

    If the value is Auto, this server becomes a browser if the master browser for the domain considers it appropriate for the server to be a browser.

  • IsDomainMaster – REG_SZ

    Range: True and False

    Default: False

    This parameter gives the server an advantage during the election of a master browser in the domain. The PDC has this value set to True. For WAN environments, this specifies a workstation within a workgroup, which, as a potential browser, should be included in the global Lmhosts file. This helps with WAN browsing. It has two values:

    Setting this parameter to True forces the elevation of a workstation's priority for the browser.

    Setting this parameter to False has no effect.

  • UnboundBindings – REG_MULTI_SZ

    String: NetBT_<name of network adapter driver to be disabled>

    If you have more than two network adapters in the multihomed Windows NT–based server, enter each driver instance that you wish to disable on a separate line in the String field.

  • BackupBrowserRecoveryTime - REG_DWORD

    Default: 180000 milliseconds (30 minutes)

    When a backup browser fails in three attempts to contact the master browser, the backup browser shuts down for this length of time.

  • CacheHitLimit – REG_DWORD

    Range: 0 to 0xFFFFFFFF

    Default: 1

    A browser maintains a cache of responses to NetServerEnum requests, and this parameter helps to control that cache. To guarantee that it is worth keeping a response to a client in the cache, the browser waits until it sees CacheHitLimit browse requests of a given type before it adds the request to the cache. Every 15 minutes (or QueryDriverFrequency on a master browser), the browser ages the cache. Any entries in the cache that have had less than CacheHitLimit hits since the previous flush are discarded.

  • CacheResponseSize – REG_DWORD

    Range: 10 to 0xFFFFFFFF

    Default: 10

    This specifies the maximum number of cached browse responses for each transport that the browser keeps.

  • QueryDriverFrequency – REG_DWORD

    Range: 0 to 900 seconds

    Default: 30

    This parameter is only valid on the master browser TCP/IP. When the browser is a master browser, it queries the browser driver every QueryDriverFrequency seconds. This parameter is also used to control how often the response cache is flushed on a master browser. Decreasing this value increases the accuracy of browse responses; however, it increases the CPU load on the server. Increasing this value decrease the load on the server, but also decrease the accuracy of the browse responses.

  • HLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation

    \ParametersOtherDomains – REG_SZ

    Default: <none>

    Each workstation can be configured with up to four OtherDomains. The Domains are LAN Manager–only domains that the workstation is interested in browsing. If any OtherDomains are configured on a domain master browser, the OtherDomains are provided to all members of the domain

  • HLM\SYSTEM\CurrentControlSet\Services\LanmanServer

    \Parameters Hidden – REG_BINARY

    Range: 0 or 1

    Default: 0

    This determines whether the server's computer name and comment can be viewed by other computers in the domain. If the value is configured to 0, the server's name and comment can be viewed by other computers in the domain. If the value is configured to 1, the server's name and comment cannot be viewed by other computers in the domain.

  • LMAnnounce – REG_DWORD

    Range: 0 or 1

    Default: 0

    This option causes the browser to announce itself with a LAN Manager 2.x–compatible server announcement. By default, this option is configured not to send announcements to LAN Manager 2.x servers. Setting this parameter to 1, True, causes the server to announce itself to LAN Manager workstations. Set this parameter to 0, False, to not generate any LAN Manager broadcasts.

  • SizReqBuf - REG_DWORD

    Range: 512 - 65536 bytes

    Default: 4096

    This specifies the size of request buffers that the server uses. Small buffers use less memory; large buffers may improve performance. The exact value that works best in a specific environment depends on the configuration of that environment, but 14596 is a value that has been shown to work well in a fairly standard Ethernet environment. For more information, see the following Knowledge Base article:

    177266: Remote Directory Lists Are Slower Than Local Directory Listings

  • HLM\System\CurrentControlSet\Services\RDR\Parameters

    Windows NT 3.1 Advanced Server uses the following key:

    HLM\System\CurrentControlSet\Services\DGRcvr\Parameters

  • BrowserServerDeletionThreshold – REG_DWORD

    Range: 0 to 0xFFFFFFFF

    Default: 0xFFFFFFFF

    This parameter is only valid on master browsers. If the browser driver ages out more than BrowserServerDeletionThreshold servers in a single 30-second interval, the browser generates an event indicating a possible network problem. Its value is the number of servers. The default for this parameter is 0xffffffff, indicating that the event should never be generated.

  • BrowserDomainDeletionThreshold – REG_DWORD

    Range: 0 to 0xFFFFFFFF

    Default: 0xFFFFFFFF

    This is only valid on master browsers. It controls the number of domains permitted for the browser driver to age out in a 30-second interval, before generating an event indicating a possible network problem. Its value is the number of domains. The default for this parameter is 0xffffffff, indicating that the event should never be generated.

  • FindMasterTimeout – REG_DWORD

    Range: 0 to 0xFFFFFFFF

    Default: 0xFFFFFFFF

    This specifies the time out for FindMaster requests in seconds. On a slow network, it may be necessary to increase this value.

  • BrowserMinimumConfiguredBrowsers – REG_DWORD

    Default: 1

    This parameter indicates the number of configured browsers that are considered the minimum before the browser promotes other browsers to be backup browsers.

  • GetBrowserListThreshold – REG_DWORD

    Range: 0 to 0xFFFFFFFF

    Default: 0xFFFFFFFF

    This represents the threshold that the browser uses before logging an error indicating that too many of these requests have been missed. If more requests than the value of GetBrowserServerList are missed in an hour, the browser logs an event indicating that this has happened.

  • MailslotDatagramThreshold – REG_DWORD

    Range: 0 to 0xFFFFFFFF

    Default: 0xFFFFFFFF

    This represents the threshold that the browser uses before logging an error indicating that too many of these requests have been missed. If more mailslots than the value of MailslotDatagramThreshold are missed in an hour, the browser logs an event indicating that this has happened.

Appendix F: windows NT Browser Error Codes

  • Event ID: 8003

    Severity: Error

    SymbolicName: EVENT_BOWSER_OTHER_MASTER_ON_NET

    The master browser has received a server announcement from the computer %2 that believes that it is the master browser for the domain on transport %3. The master browser is stopping, or an election is being forced.

  • Event ID: 8004

    Severity: Warning

    SymbolicName: EVENT_BOWSER_PROMOTED_WHILE_ALREADY_MASTER

    A request has been submitted to promote the computer to backup when it is already a master browser.

  • Event ID: 8005

    Severity: Warning

    SymbolicName: EVENT_BOWSER_NON_MASTER_MASTER_ANNOUNCE

    The browser has received a server announcement indicating that the computer %2 is a master browser, but this computer is not a master browser.

  • Event ID: 8006

    Severity: Warning

    SymbolicName: EVENT_BOWSER_ILLEGAL_DATAGRAM

    The browser has received an illegal datagram from the remote computer %2 to name %3 on transport %4. The data is the datagram.

  • Event ID: 8007

    Severity: Error

    SymbolicName: EVENT_BROWSER_STATUS_BITS_UPDATE_FAILED

    The browser was unable to update the service status bits. The data is the error.

  • Event ID: 8008

    Severity: Error

    SymbolicName: EVENT_BROWSER_ROLE_CHANGE_FAILED

    The browser was unable to update its role. The data is the error.

  • Event ID: 8009

    Severity: Error

    SymbolicName: EVENT_BROWSER_MASTER_PROMOTION_FAILED

    The browser was unable to promote itself to master browser. The computer that currently believes it is the master browser is %1.

  • Event ID: 8010

    Severity: Error

    SymbolicName: EVENT_BOWSER_NAME_CONVERSION_FAILED

    The browser driver was unable to convert a character string to a Unicode string.

  • Event ID: 8011

    Severity: Error

    SymbolicName: EVENT_BROWSER_OTHERDOMAIN_ADD_FAILED

    The browser was unable to add the configuration parameter %1.

  • Event ID: 8012

    Severity: Success

    SymbolicName: EVENT_BOWSER_ELECTION_RECEIVED

    The browser driver has received an election packet from computer %2 on network %3. The data is the packet received.

  • Event ID: 8013

    Severity: Informational

    SymbolicName: EVENT_BOWSER_ELECTION_SENT_GETBLIST_FAILED

    The browser driver has forced an election on network %2 because it was unable to find a master browser to retrieve a backup list on that network.

  • Event ID: 8014

    Severity: Informational

    SymbolicName: EVENT_BOWSER_ELECTION_SENT_FIND_MASTER_FAILED

    The browser driver has forced an election on network %2 because it was unable to find a master browser for that network.

  • Event ID: 8015

    Severity: Informational

    SymbolicName: EVENT_BROWSER_ELECTION_SENT_LANMAN_NT_STARTED

    The browser has forced an election on network %1 because a Windows NT Server (or domain master) browser is started.

  • Event ID: 8016

    Severity: Error

    SymbolicName: EVENT_BOWSER_ILLEGAL_DATAGRAM_THRESHOLD

    The browser driver has received too many illegal datagrams from the remote computer %2 to name %3 on transport %4. The data is the datagram. No more events will be generated until the reset frequency has expired.

  • Event ID: 8017

    Severity: Error

    SymbolicName: EVENT_BROWSER_DEPENDANT_SERVICE_FAILED

    The browser has failed to start because the dependent service %1 had invalid service status %2.

    Status

    Meaning

    1

    Service Stopped%n

    2

    Start Pending%n

    3

    Stop Pending%n

    4

    Running%n

    5

    Continue Pending%n

    6

    Pause Pending%n

    7

    Paused%n

  • Event ID: 8019

    Severity: Error

    SymbolicName: EVENT_BROWSER_MASTER_PROMOTION_FAILED_STOPPING

    The browser was unable to promote itself to master browser. The browser will continue to attempt to promote itself to the master browser but will no longer log any events in the event log in Event Viewer.

  • Event ID: 8020

    Severity: Error

    SymbolicName: EVENT_BROWSER_MASTER_PROMOTION_FAILED_NO_MASTER

    The browser was unable to promote itself to master browser. The computer that currently believes it is the master browser is unknown.

  • Event ID: 8021

    Severity: Warning

    SymbolicName: EVENT_BROWSER_SERVER_LIST_FAILED

    The browser was unable to retrieve a list of servers from the browser master %1 on the network %2. The data is the error code.

  • Event ID: 8022

    Severity: Warning

    SymbolicName: EVENT_BROWSER_DOMAIN_LIST_FAILED

    The browser was unable to retrieve a list of domains from the browser master %1 on the network %2. The data is the error code.

  • Event ID: 8023

    Severity: Warning

    SymbolicName: EVENT_BROWSER_ILLEGAL_CONFIG

    The value for the parameter %1 to the browser service was illegal.

  • Event ID: 8024

    Severity: Informational

    SymbolicName: EVENT_BOWSER_OLD_BACKUP_FOUND

    The backup browser server %2 is out of date. Consider upgrading this computer.

  • Event ID: 8025

    Severity: Success

    SymbolicName: EVENT_BROWSER_SERVER_LIST_RETRIEVED

    The browser has retrieved a list of servers from remote computer %1 on transport %2.%n There were %3 entries read and %4 total entries.

  • Event ID: 8026

    Severity: Success

    SymbolicName: EVENT_BROWSER_DOMAIN_LIST_RETRIEVED

    The browser has retrieved a list of domains from remote computer %1 on transport %2.%n There were %3 entries read and %4 total entries.

  • Event ID: 8027

    Severity: Informational

    SymbolicName: EVENT_BOWSER_PDC_LOST_ELECTION

    The browser running on the domain controller has lost an election. The computer that won the election is %2 on the transport %3.%n The data contains the election version, election criteria, remote computer time up, and the same information for the current computer.

  • Event ID: 8028

    Severity: Informational

    SymbolicName: EVENT_BOWSER_NON_PDC_WON_ELECTION

    The browser running on this computer has won a browser election on network %2. This computer is a member of a domain, so the domain controller should become the master browser.

  • Event ID: 8029

    SymbolicName: EVENT_BOWSER_CANT_READ_REGISTRY

    The browser driver was unable to initialize variables from the registry.

  • Event ID: 8030

    SymbolicName: EVENT_BOWSER_MAILSLOT_DATAGRAM_THRESHOLD_EXCEEDED

    The browser driver has discarded too many mailslot messages.

  • Event ID: 8031

    SymbolicName: EVENT_BOWSER_GETBROWSERLIST_THRESHOLD_EXCEEDED

    The browser driver has discarded too many GetBrowserServerList requests.

  • Event ID: 8032

    Severity: Error

    SymbolicName: EVENT_BROWSER_BACKUP_STOPPED

    The browser service has failed to retrieve the backup list too many times on transport %1. The backup browser is stopping.

  • Event ID: 8033

    Severity: Informational

    SymbolicName: EVENT_BROWSER_ELECTION_SENT_LANMAN_NT_STOPPED

    The browser has forced an election on network %1 because a master browser was stopped.

  • Event ID: 8034

    Severity: Error

    SymbolicName: EVENT_BROWSER_GETBLIST_RECEIVED_NOT_MASTER

    The browser has received a GetBrowserServerList request when it is not the master browser.

  • Event ID: 8035

    Severity: Informational

    SymbolicName: EVENT_BROWSER_ELECTION_SENT_ROLE_CHANGED

    The browser has forced an election on network %1 because the Domain controller (or server) has changed its role

  • Event ID: 8036

    Severity: Error

    SymbolicName: EVENT_BROWSER_NOT_STARTED_IPX_CONFIG_MISMATCH

    The browser has failed to start because of an error in the DirectHostBinding parameter to the browser.

Appendix G: Network Layers Involved in Browsing

MAC Layer

Most browser frames are sent as broadcast or multicast at the MAC layer. The advantage of using broadcast is that everyone receives the frame. Additionally, the overhead of a sessions is not needed. However, broadcast traffic must be processed by all systems, including ones not interested in browsing. One potential ramification of using broadcast datagrams is that browsing is limited to a broadcast collision zone. This side effect occurs because most routers and switches are configured to not forward NetBIOS broadcast traffic.

Network Layer

All browser frames are sent to the broadcast network address. For example, if a station has an IP address of 130.20.1.1 and a subnet mask of 255.255.0.0, all browser frames are addressed to 130.20.255.255. Obviously this does not apply for transport protocols that lack a network layer, such as NetBEUI.

NetBIOS Layer

Most Microsoft protocols contain a NetBIOS protocol layer. Examples include NBFP in NetBEUI or NetBT in the TCP/IP stack. The browser uses an elaborate NetBIOS naming scheme to direct traffic. The names are controlled by adding a special code in the sixteenth character of the domain name. Even though a frame is broadcast at the MAC and network layer, only stations that have the special NetBIOS name registered accept the frames. The following is an example of an Windows NT 3.1 NBT [NetBIOS over TCP\IP] browser frame. Notice the destination NetBIOS name.

NBT: DS: Type = 17 (DIRECT GROUP)
NBT: Datagram Packet Type = DIRECT GROUP
NBT: Datagram Flags = 2 (0x2)
NBT: 0000.... = Reserved
NBT: ....00.. = B Node
NBT: ......1. = Not First Packet
NBT: .......0 = More Fragments Follow
NBT: Datagram ID = 164 (0xA4)
NBT: Source IP Address = 130.22.1.99
NBT: Source Port = 138 (0x8A)
NBT: Datagram Length = 189 (0xBD)
NBT: Packet Offset = 0 (0x0)
NBT: Source Name = BATCOMPUTER3<00>
NBT: Destination Name = DOMA<1D>
NBT: DS Data: Number of data bytes remaining = 119 (0x0077)

SMB Layer

All Browser frames ride on top of SMB Transact frames. Because the frame contains an SMB, it must also contain a NetBIOS layer, which contains one of the NetBIOS names discussed previously. The SMB Transact carries the command "Mailslot Write." Since the browser service is a mailslot receiver, the browser accepts mailslots addressed to \Mailslot\Browse. The mailslot data following the mailslot address is the Browser frame. The first byte is the browser command code. The following is an example of the SMB layer of a browser frame:

SMB: C transact, File = \MAILSLOT\BROWSE
SMB: SMB Status = Error Success
SMB: Error class = No Error
SMB: Error code = No Error
SMB: Header: PID = 0x0000 TID = 0x0000 MID = 0x0000 UID = 0x0000
SMB: Tree ID      (TID) = 0 (0x0)
SMB: Process ID   (PID) = 0 (0x0)
SMB: User ID      (UID) = 0 (0x0)
SMB: Multiplex ID (MID) = 0 (0x0)
SMB: Flags Summary = 0 (0x0)
SMB: .......0 = Lock & Read and Write & Unlock not supported
SMB: ......0. = Send No Ack not supported
SMB: ....0... = Using case sensitive pathnames
SMB: ...0.... = No canonicalized pathnames
SMB: ..0..... = No Opportunistic lock
SMB: .0...... = No Change Notify
SMB: 0....... = Client command
SMB: flags2 Summary = 0 (0x0)
SMB: ...............0 = Understands only DOS 8.3 filenames
SMB: ..............0. = Does not understand extended 
Attributes
SMB: ..0............. = No paging of IO
SMB: .0.............. = Using SMB status codes
SMB: 0............... = Using ASCII strings
SMB: Command = C transact
SMB: Word count = 17
SMB: Word parameters
SMB: Total parm bytes = 0
SMB: Total data bytes = 33
SMB: Max parm bytes = 0
SMB: Max data bytes = 0
SMB: Max setup words = 0
SMB: Transact Flags Summary = 0 (0x0)
SMB: ...............0 = Leave session intact
SMB: ..............0. = Response required
SMB: Transact timeout = 0 (0x0)
SMB: Parameter bytes = 0 (0x0)
SMB: Parameter offset = 0 (0x0)
SMB: Data bytes = 33 (0x21)
SMB: Data offset = 86 (0x56)
SMB: Setup word count = 3
SMB: Setup words
SMB: Mailslot opcode = Write mailslot
SMB: Transaction priority = 1
SMB: Mailslot class = Unreliable (broadcast)
SMB: Byte count = 50
SMB: Byte parameters
SMB: Path name  = \MAILSLOT\BROWSE
SMB: Transaction data
SMB: Data: Number of data bytes remaining = 33 (0x0021)

Appendix H: Windows NT Browser Protocol Frames

The Browser service consists of 10 special peer protocol frames. In addition, the Browser relies heavily on two LAN Manager APIs and RPC in Windows NT. The Browser uses these frames in conjunction with standard NetBIOS frames to operate.

The following are Windows NT browser frames and their command codes:

#define HostAnnouncement             1      0x01
#define AnnouncementRequest          2      0x02
#define Election                     8      0x08
#define GetBackupListReq             9      0x09
#define GetBackupListResp            10     0x0a
#define BecomeBackup                 11     0x0b
#define WkGroupAnnouncement          12     0x0c
#define MasterAnnouncement           13     0x0d
#define ResetBrowserState            14     0x0e
#define LocalMasterAnnouncement      15     0x0f

Server Type Field

The Server Type field appears in many of the browser frames. This field contains flag bits that indicate the current status of the server.

The following is an enumeration of Server Types:

SV_TYPE_WORKSTATION             0x00000001      All LAN Manager workstation
SV_TYPE_SERVER                  0x00000002      All LAN Manager server
SV_TYPE_SQLSERVER               0x00000004     Any server running with SQL
server
SV_TYPE_DOMAIN_CTRL             0x00000008     Primary domain controller
SV_TYPE_DOMAIN_BAKCTRL          0x00000010     Backup domain controller
SV_TYPE_TIMESOURCE              0x00000020     Server running the
Timesource Service
SV_TYPE_AFP                     0x00000040     Apple File Protocol servers
SV_TYPE_NOVELL                  0x00000080     Novell servers
SV_TYPE_DOMAIN_MEMBER           0x00000100     Domain Member
SV_TYPE_PRINT                   0x00000200     Server sharing print queue
SV_TYPE_DIALIN                  0x00000400     Server running RAS service
SV_TYPE_XENIX_SERVER            0x00000800     Xenix server
SV_TYPE_NT                      0x00001000     NT server
SV_TYPE_WFW                     0x00002000     Server running Windows for
Workgroups
SV_TYPE_SERVER_NT               0x00008000     Windows NT Non-DC server
SV_TYPE_POTENTIAL_BROWSER       0x00010000     Server that can run the
browser service
SV_TYPE_BACKUP_BROWSER          0x00020000     Server running a browser
service as backup
SV_TYPE_MASTER_BROWSER          0x00040000     Server running the master
browser service
SV_TYPE_DOMAIN_MASTER           0x00080000     Server running the domain
master browser
SV_TYPE_TERMINALSERVER          0X02000000     Server running Windows NT
Terminal Services
V_TYPE_APPSERVER               0x10000000     Server running Citrix
Winframe
SV_TYPE_ALTERNATE_XPORT         0X20000000     Return List for Alternate
Transport
SV_TYPE_LOCAL_LIST_ONLY         0x40000000     Return local list only
SV_TYPE_DOMAIN_ENUM             0x80000000     Return domain members
SV_TYPE_ALL                     0xffffffff     All servers

Host Announcement Frame

The Announce Packet is used to announce servers in the domain. When a Windows NT (or Windows For Workgroups) server announces itself, it sends a directed Announce to the unique master name for that workgroup <DOMAIN><1d>. When a Windows NT (or Windows for Workgroups) master browser announces itself, it sends a broadcast to the group election name <DOMAIN><1e>.

This announcement packet serves the following purposes:

  1. It indicates to backup browsers that the master has changed. Backup browsers notice this packet and update their saved version of the master browser name.

  2. The master browser places its information in its local browse list.

    If a master browser receives an announcement packet from another computer that believes that it is the master browser, the master shuts down, discards its local browser list, and forces an election. This allows the correct master to be determined.

    • UpdateCount: The UpdateCount field is used to indicate that information has been updated in the servers' announcement list. If contents of the master browser's server or domain list has modified, it increments UpdateCount and announces. This allows backup browsers to pick up these updates.

    • Periodicity: Below this is referred to as the Update Interval, and it is converted to minutes. The announcement frequency of the server. The server is removed from the browse list if it has not been heard from in three times its announcement frequency.

    • ServerName: Null-terminated OEM ASCII server name.

    • VersionMajor: The major version of the server.

    • VersionMinor: The minor version of the server.

    • Server Type: See above.

Example:

BROWSER: Host Announcement [0x01]
BROWSER: Command = Host Announcement [0x01]
BROWSER: Update Count = 7 (0x7)
BROWSER: Annoucement Interval [minutes] = 5
BROWSER: Name = BATCOMPUTER3
BROWSER: Major Version = 1 (0x1)
BROWSER: Minor Version = 51 (0x33)
BROWSER: Server Type Summary = 204803 (0x32003)
BROWSER: ...............................1 = Workstation
BROWSER: ..............................1. = Server
BROWSER: .............................0.. = Not SQL Server
BROWSER: ............................0... = Not Domain Controller
BROWSER: ...........................0.... = Not Backup Controller
BROWSER: ..........................0..... = Not Time Source
BROWSER: .........................0...... = Not Apple Server
BROWSER: ........................0....... = Not Novell
BROWSER: .......................0........ = Not Domain Member
Server
BROWSER: ......................0......... = Not Print Queue
Server
BROWSER: .....................0.......... = Not Dialin Server
BROWSER: ....................0........... = Not Xenix Server
BROWSER: ...................0............ = Not NT System
BROWSER: ..................1............. = Windows for
Workgroups
BROWSER: ...............1................ = Potential Browser
Server
BROWSER: ..............1................. = Backup Browser Server
BROWSER: .............0.................. = Not Master Browser
BROWSER: ............0................... = Not Domain Master
Browser
BROWSER: ...........0.................... = Not OSF
BROWSER: ..........0..................... = Not VMS
BROWSER: .0.............................. = Not Local List Only
BROWSER: 0............................... = Not Domain Enum
BROWSER: Browser Election Version = 779 (0x30B)
BROWSER: Browser Constant = 43605 (0xAA55)

Local Master Announcement Frame

This frame is basically the same as the Host Annoucement frame. It is used by the master browser to announce itself. These frames are usually sent to the special NetBIOS name <DOMAIN><1e>, which is used by all browsers.

Example:

BROWSER: Local Master Announcement [0x0f]
BROWSER: Command = Local Master Announcement [0x0f]
BROWSER: Update Count = 0 (0x0)
BROWSER: Annoucement Interval [minutes] = 12
BROWSER: Name = COOLBLADE
BROWSER: Major Version = 3 (0x3)
BROWSER: Minor Version = 50 (0x32)
BROWSER: Server Type Summary = 266251 (0x4100B)
BROWSER: ...............................1 = Workstation
BROWSER: ..............................1. = Server
BROWSER: .............................0.. = Not SQL Server
BROWSER: ............................1... = Domain Controller
BROWSER: ...........................0.... = Not Backup Controller
BROWSER: ..........................0..... = Not Time Source
BROWSER: .........................0...... = Not Apple Server
BROWSER: ........................0....... = Not Novell
BROWSER: .......................0........ = Not Domain Member
Server
BROWSER: ......................0......... = Not Print Queue
Server
BROWSER: .....................0.......... = Not Dialin Server
BROWSER: ....................0........... = Not Xenix Server
BROWSER: ...................1............ = Windows NT System
BROWSER: ..................0............. = Not WFW System
BROWSER: ...............0................ = Not Potential Browser
BROWSER: ..............0................. = Not Backup Browser
BROWSER: .............1.................. = Master Browser Server
BROWSER: ............0................... = Not Domain Master
Browser
BROWSER: ...........0.................... = Not OSF
BROWSER: ..........0..................... = Not VMS
BROWSER: .0.............................. = Not Local List Only
BROWSER: 0............................... = Not Domain Enum
BROWSER: Browser Election Version = 271 (0x10F)
BROWSER: Browser Constant = 43605 (0xAA55)

Domain / Work Group Announcement Frame

This frame is sent by the master browser to announce the existence of the domain. Other master browsers in different domains store these announcements along with the server's name. This is one way that they build their domain list. These frames are sent to the special NetBIOS name <01><02>__MSBROWSE__<02><01>.

  • Name: For this frame, Name is set to the Domain name, not the server name.

  • Comment Pointer: Unused value.

  • Server Name: The master browser that is announcing the domain. This name is stored by master browsers in other domains. This is used to double hop.

Example:

BROWSER: Workgroup Announcement [0x0c]
BROWSER: Command = Workgroup Announcement [0x0c]
BROWSER: Update Count = 0 (0x0)
BROWSER: Annoucement Interval [minutes] = 15
BROWSER: Name = DOMA
BROWSER: Major Version = 3 (0x3)
BROWSER: Minor Version = 10 (0xA)
BROWSER: Server Type Summary = 2147487744 (0x80001000)
BROWSER: ...............................0 = Not Workstation
BROWSER: ..............................0. = Not Server
BROWSER: .............................0.. = Not SQL Server
BROWSER: ............................0... = Not Domain Controller
BROWSER: ...........................0.... = Not Backup Controller
BROWSER: ..........................0..... = Not Time Source
BROWSER: .........................0...... = Not Apple Server
BROWSER: ........................0....... = Not Novell
BROWSER: .......................0........ = Not Domain Member Server
BROWSER: ......................0......... = Not Print Queue Server
BROWSER: .....................0.......... = Not Dialin Server
BROWSER: ....................0........... = Not Xenix Server
BROWSER: ...................1............ = Windows NT System
BROWSER: ..................0............. = Not WFW System
BROWSER: ...............0................ = Not Potential Browser
BROWSER: ..............0................. = Not Backup Browser
BROWSER: .............0.................. = Not Master Browser
BROWSER: ............0................... = Not Domain Master Browser
BROWSER: ...........0.................... = Not OSF
BROWSER: ..........0..................... = Not VMS
BROWSER: .0.............................. = Not Local List Only
BROWSER: 1............................... = Domain Enum
BROWSER: Comment Pointer = 28311416 (0x1AFFF78)
BROWSER: Server Name = ATT-SERVER

Announcement Request Frame

This frame causes all local browsers to announce themselves. This frame is sent at browser client startup to find the master browser for the domain. The frame is usually broadcast to the special NetBIOS name <DOMAIN><1d>, which is only registered by a master browser. Sometimes it is sent directly to the master browser.

Example:

BROWSER: Announcement Request [0x02]
BROWSER: Command = Announcement Request [0x02]
BROWSER: Unused Flags = 0 (0x0)
BROWSER: Reply System Name = A-CLIENT

Election Frame

This frame is sent when a master browser election is required. This usually occurs when the master browser goes down or when the network is starting up.

  • Version: Specifies the version of this election packet.

  • Criteria: Specifies the election criteria of the client. This contains two subfields.

  • Operating System: Specifies the operating system type and version which is one of the election criteria.

  • Election Revision: Part of the browser software version.

  • Election Desire: Contains items that help determine the election criteria. Some items deal with current browser state, such as Current Backup Browser.

  • TimeUp: The amount of time that the server has been up, which is one of the election criteria.

  • ServerName: Null-terminated ASCII server name.

Example:

BROWSER: Election [0x08]
BROWSER: Command = Election [0x08]
BROWSER: Election Version = 1 (0x1)
BROWSER: Election Criteria = 536940294 (0x20010F06)
BROWSER: Election OS Summary = 32 (0x20)
BROWSER: .......0 = Not WFW
BROWSER: ......0. = Not used
BROWSER: .....0.. = Not used
BROWSER: ....0... = Not used
BROWSER: ...0.... = Not Windows NT Workstation
BROWSER: ..1..... = Advanced Server Windows NT
BROWSER: .0...... = Not used
BROWSER: 0....... = Not used
BROWSER: Election Revision = 271 (0x10F)
BROWSER: Election Desire Summary = 6 (0x6)
BROWSER: .......0 = Not Backup Browse Server
BROWSER: ......1. = Standby Browser Server
BROWSER: .....1.. = Currently Master Browser Server
BROWSER: ....0... = Not Domain Master Browser
BROWSER: ...0.... = Not used
BROWSER: ..0..... = Not WINS Client
BROWSER: .0...... = Not used
BROWSER: 0....... = Not Advanced Server
BROWSER: Server Up Time [DD:hh:mm:ss] 0:0:31:31
BROWSER: Election Server Name = ATT-SERVER

Become Backup Frame

This frame is used by the master browser to tell a potential browser to become a backup. To see how the master browser determines this refer to the backup ration chart in the Master Browser section. Even though this message is only intended for one particular system, the master browser still broadcasts this frame.

Example:

BROWSER: Become Backup [0x0b]
BROWSER: Command = Become Backup [0x0b]
BROWSER: Name = BATCOMPUTER3

Get Backup List Request Frame

This frame is broadcast to get a list of backup browsers from a particular domain. The domain is specified by the special NetBIOS name in the NetBIOS frame section. It is sent with the name <DOMAIN><1d>. The workstation stores a maximum of three of the names returned. The GetBackupListRequest is also unicast to the domain master browser, which handles the case in which the queried domain has no members on the subnet. From this list it picks one at random to which to send NetServerEnum2.

Fields:

  • Requested Count: Indicates the maximum number for browser server names to return. It may return fewer.

  • Token: Used by the sender to correlate a request with a response. The client might send multiple requests on multiple transports for different domain names.

Example:

BROWSER: Get Backup List Request [0x09]
BROWSER: Command = Get Backup List Request [0x09]
BROWSER: Get Backup List Requested Count = 4 (0x4)
BROWSER: Backup Request Token = 1 (0x1)

Get Backup List Response Frame

This is the response to a Get Backup List Request.

Example:

BROWSER: Get Backup List Response [0x0a]
BROWSER: Command = Get Backup List Response [0x0a]
BROWSER: Backup Server Count = 2 (0x2)
BROWSER: Backup Response Token = 1 (0x1)
BROWSER: Backup Servers = LCSCOTTSU1
BROWSER: Backup Servers = RTHOM1

Master Announcement Frame

This frame is sent by the master browser on a subnet to the PDC (DomainMaster). It announces the presence of the master on the domain to allow the PDC to retrieve the local subnets domain list. This is one of the few browser frames that is sent directly to the master browser; it is a directed datagram.

Example:

BROWSER: Master Announcement [0x0d]
BROWSER: Command = Master Announcement [0x0d]
BROWSER: Master Name = LCSCOTTSU5

Reset Browser State Frame

This frame is a diagnostic packet that can be used to force a master browser to stop functioning as a master browser.

Options:

  • RESET_STATE_STOP_MASTER (0x01)

    This indicates that the master browser should stop functioning as a master. This means that it should remove the master name and the domain announcement name and fall back as a backup browser.

  • RESET_STATE_CLEAR_ALL (0x02)

    This indicates that a browser should clear its browser state. This means that the browser should discard its server list and effectively restart.

  • RESET_STATE_STOP (0x04)

    This indicates that the browser should stop functioning at all. For security reasons, the NT browser does not support this packet.

Example:

BROWSER: Reset Browser [0x0e]
BROWSER: Command = Reset Browser [0x0e]
BROWSER: Options Summary = 2 (0x2)
BROWSER: .......0 = Zero
BROWSER: ......1. = Reset Entire Browser State
BROWSER: .....0.. = Zero