Users on a Windows NT network often need to know what domains and computers are accessible from their local computer. Viewing all the network resources available is called browsing. The Windows NT Browser service maintains a list (called the browse list) of all available domains and servers. The browse list can be viewed using Windows NT Explorer and is provided by a browser in the local computer's domain.
Note: For the purposes of this discussion, the term server refers to any computer that can provide resources to the rest of the network. If a computer running Windows NT Workstation can share file or print resources with other computers on the network, it is considered a server in the context of the browser system. The computer does not have to be actively sharing resources to be considered a server.
This chapter includes descriptions of the following topics.
-
The types of browser computers
-
How browsers can work together to provide an accurate browser list, even if the master browser fails
-
Master-browser elections
-
The API calls used to register computers for the browser list and to receive the list from the master browser
-
How browsing across domains is handled
On This Page
The Windows NT Browser Service
Browser Elections
Browser Announcements
Browser Requests
Number of Browsers in a Domain or Workgroup
Browser Shutdown or Failure
Browse Service Across Multiple Workgroups and Domains
Windows for Workgroups and Windows 95 as Master Browsers
Microsoft LAN Manager Interoperability
Browser System Components
Monitoring Browsers
The Windows NT Browser Service
Windows NT assigns browser tasks to specific computers on the network. The computers work together to provide a centralized list of shared resources, eliminating the need for all machines to maintain their own lists. This reduces the CPU time and network traffic needed to build and maintain the list.
The Windows NT Browser system consists of a master browser, backup browsers, and browser clients. The computer that is 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 remotely sending a NetServerEnum application programming interface (API) call to either the master browser or a backup browser.
A datagram is a network message packet that can be sent to a mailslot on a specified computer (a directed datagram) or to a mailslot on any number of computers (a broadcast datagram). This centralized-browser architecture reduces the number of datagrams sent to produce the available resource list. The centralized-browser architecture also reduces demands on the client CPU and memory.
Specifying Browser Computers
When you start a computer running Windows NT Workstation or Windows NT Server, the Browser service looks in the registry for the configuration parameter MaintainServerList to determine whether or not a computer will become a browser. This parameter is found under:
\HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Browser \Parameters
Table 3.1 Allowable Values for the MaintainServerList parameter
| Parameter Value | Meaning |
| No | This computer will never participate as a browser. |
| Yes | This computer will become a browser. Upon startup, this computer attempts to contact the master browser to get a current browse list. If the master browser cannot be found, the computer will force a browser election. This computer will either be elected master browser or become a backup browser. Yes is the default value on a computer running Windows NT Server. |
| Auto | This computer, referred to as a potential browser, may or may not become a browser, depending on the number of currently active browsers. The master browser notifies this computer whether or not it will become a backup browser. Auto is the default value for computers running Windows NT Workstation. |
On any computer with an entry of Yes or Auto for the MaintainServerList parameter, Windows NT Setup configures the Browser service to start automatically when the computer starts.
Another parameter in the registry, IsDomainMasterBrowser, helps to determine which servers become master browsers and backup browsers The registry path for this parameter is as shown below.
\HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Browser \Parameters
Setting the IsDomainMasterBrowser parameter entry to True or Yes on a computer makes that computer a preferred master browser. A preferred master browser has priority over other computers in master browser elections. Whenever a preferred master browser starts, it forces a browser election.
Any computer running Windows NT Workstation or Windows NT Server can be configured as a preferred master browser. When the Browser service is started on the preferred master-browser computer, the Browser service forces an election. Preferred master browsers are given priority in elections, which means that if no other condition prevents it, the preferred master browser will always win the election. This gives an administrator the ability to configure a specific computer as the master browser.
To specify a computer as the preferred master browser, set the parameter entry for IsDomainMasterBrowser to True or Yes. Set the parameter in the following registry path:
\HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Browser \Parameters
Unless the computer is configured as the preferred master browser, the parameter entry will always be False or No. There is no user interface for making these changes; the registry must be modified.
Browser System Roles
A computer running Windows NT 3.1, Windows NT Advanced Server 3.1, Windows NT Workstation 3.5 or later, Windows NT Server 3.5 or later, Windows for Workgroups 3.11, or Windows 95 can be browsers. There are five types of computers in the browser system:
-
Non-browsers
-
Potential browsers
-
Backup browsers
-
Master browsers
-
Domain master browsers
Figure 3.1: Browser and non-browser computers
Non-browser
A non-browser is a computer that has been configured not to maintain a network resource or browse list.
Potential Browser
A potential browser is a computer that is capable of a maintaining a network resource browse list and can be elected as a master browser. The potential browser computer can act as a backup browser if instructed to do so by the master browser.
Backup Browser
The backup browser receives a copy of the network-resource browse list from the master browser and distributes the list upon request to computers in the domain or workgroup. All Windows NT domain controllers are automatically configured as either master or backup browsers.
Computers running Windows NT Workstation, Windows for Workgroups, or Windows 95 can be backup browsers if there are fewer than three Windows NT Server computers performing backup-browser functions for the domain.
Backup browsers call the master browser every 15 minutes to get the latest copy of the browse list and a list of domains. Each backup browser caches these lists and returns the list of servers to any clients that send a remote NetServerEnum API call to the backup browser. If the backup browser cannot find the master browser, it forces an election of the master browser.
The data limit for the list of servers maintained on computers running a version of Windows NT prior to version 4.0, Windows for Workgroups, or Windows 95 is 64K. This limits the number of computers in a browse list for a single workgroup or domain to between 2,000 and 3,000 computers.
Master Browser
The master browser is responsible for collecting the information necessary to create and maintain the browse list. The browse list includes all servers in the master browser's domain or workgroup, and the list of all domains on the network.
Individual servers announce their presence to the master browser by sending a directed datagram called a server announcement to the domain or workgroup master browser. Computers running Windows NT Server, Windows NT Workstation, Windows for Workgroups, Windows 95, or LAN Manager send server announcements. When the master browser receives a server announcement from a computer, it adds that computer to the browse list.
When a domain spans more than one subnetwork, the master browser will do the following tasks:
-
Maintain the browse list for the portion of the domain on its subnetwork
-
Provide lists of backup browsers on the local subnetwork of a TCP/IP-based network to computers running Windows NT Server, Windows NT Workstation, and Windows for Workgroups
If a TCP/IP-based subnetwork is comprised of more than one domain, each domain has its own master browser and backup browsers. On networks using the NWLink IPX/SPX-compatible network protocols, name queries are sent across routers, ensuring that there is always only one master browser for each domain. NetBEUI Frame (NBF) is not designed for a routed network and requires a separate master browser per subnet.
When a computer starts and its MaintainServerList registry entry is set to Auto, the master browser must tell that computer whether or not to become a backup browser.
Domain Master Browser
The domain master browser is responsible for collecting announcements for the entire domain, including any network segments, and for providing a list of domain resources to master browsers. The domain master browser is always the primary domain controller (PDC) of a domain.
The PDC of a domain is given priority in browser elections to ensure that it becomes the master browser. The Windows NT Browser service running on a PDC has the special, additional role of being the domain master browser.
For a domain that uses TCP/IP and spans more than one subnetwork, each subnetwork functions as an independent browsing entity with its own master browser and backup browsers. NwLnkNb and NBF transports don't use the domain master browser role because those transports have only a single master browser for the entire network. Browsing across the wide area network (WAN) to other subnetworks requires at least one browser running Windows NT Server, Windows NT Workstation, or Windows For Workgroups 3.11b on the domain for each subnetwork. A PDC typically functions as the domain master browser on its subnetwork.
When a domain spans multiple subnetworks, the master browser of each subnetwork announces itself as the master browser to the domain master browser, using a directed MasterBrowserAnnouncement datagram. The domain master browser then sends a remote NetServerEnum API 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, forming 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 API call to the domain master browser to obtain the complete browse list for the domain. This browse list is available to browser clients on the subnetwork.
A single computer may play multiple browser roles. For example, the master browser may also be the domain master browser.
Note: Windows NT workgroups cannot span multiple TCP/IP subnetworks. Any Windows NT workgroup that spans subnetworks actually functions as two separate workgroups with identical names.
Browser Elections
Browser elections occur to select a new master browser under the following circumstances.
-
When a computer cannot locate a master browser
-
When a preferred master browser comes online
-
When a Windows NT domain-controller system starts
A computer initiates an election by sending a special datagram called an election datagram. All browsers can receive election datagrams. When a browser receives an election datagram, it examines that datagram's election criteria. If the browser has better election criteria than the sender of the election datagram, the browser will issue its own election datagram and enter what is called an election in progress state. If the browser does not have better election criteria than the sender of the election datagram, the browser attempts to determine which system is the new master browser.
Figure 3.2: Browser election
The election criteria for a browser is based on the browser's current role in the domain and its current state, using the hierarchy in Table 3.2.
Table 3.2 The hierarchy of criteria for a browser election
| Operating System Type | 0xFF000000 |
| Windows for Workgroups or Windows 95 | 0x01000000 |
| Windows NT Workstation | 0x10000000 |
| Windows NT Server | 0x20000000 |
| Election Version | 0x00FFFF00 |
| Per Version Criteria | 0x000000FF |
| PDC | 0x00000080 |
| WINS System | 0x00000020L |
| Preferred Master | 0x00000008 |
| Running Master | 0x00000004 |
| MaintainServerList = Yes | 0x00000002 |
| Running backup browser | 0x00000001 |
The browser will use all of the appropriate election criteria to determine the sending computer's election criteria.
The following criteria determine whether or not a browser has won an election.
-
If the browser's election version is greater than the sender's election version, the browser wins. If not, the browser uses the next election criteria. The election version is a constant value that identifies the version of the browser-election protocol. The election version is the revision of the browser protocol and is not related to the operating-system version.
-
If the browser's election criteria is greater than the sender's election criteria, the browser wins. If not, the browser uses the next election criteria.
-
If the browser has been running longer than the sender, the browser wins. If not, the browser uses the next election criteria.
-
If none of the criteria above have determined the election, then the server with the lexically (alphabetically, including numbers and symbols) lowest name wins. For example, a server named "A" will become master browser over a server named "X."
When a browser receives an election datagram indicating that it wins the election, the browser enters the running election state. While in this state, the browser sends out an election request after a delay, based on the browser's current role in the domain.
-
Master browsers and the primary domain controllers delay for 100 microseconds (ms).
-
Backup browsers and backup domain controllers randomly delay for 200 ms and 600 ms.
-
All other browsers randomly delay between 800 ms and 3000 ms.
This delay occurs because Windows for Workgroups browsers go "deaf" for several hundred microseconds after sending an election datagram. This delay reduces the number of election datagrams sent. A browser winning an election may receive a different election datagram, causing it to lose an election later. By having less-likely winners delay longer, the less-likely winners typically don't send election datagrams.
The browser sends up to four election datagrams. If no other browser responds with an election criteria datagram that would win the election, the computer is promoted to master browser. If the browser receives an election datagram indicating that another computer will win the election, and the computer is currently the master browser, the computer will demote itself from master browser and become a backup browser.
To force an election, the client computer will broadcast an election datagram to the domain, indicating that an election should occur. This datagram is created to prevent the client that sends the datagram from winning the election.
When an election occurs, the Browser service on the computer that forced the election will log an event in the Event Viewer System log, indicating that it forced the election. An event is logged for each protocol on which the Browser service forces an election.
Browser Announcements
The Browser service must be notified by a resource when it is available for use on the Windows NT network. When a network computer running Windows for Workgroups, Windows 95, Windows NT Workstation, or Windows NT Server starts, it sends an announcement to the Browser service that it is an available resource.
Figure 3.3: Browser announcements
Master browsers are responsible for receiving announcements from computers running any of the following software.
-
Windows NT 3.1
-
Windows NT 3.1 Advanced Server
-
Windows for Workgroups
-
Windows 95
-
Windows NT Workstation 3.5, or later
-
Windows NT Server 3.5, or later
-
LAN Manager systems
Master browsers also return lists of backup browsers to computers running any of the following software.
-
Windows NT 3.1
-
Windows NT 3.1 Advanced Server
-
Windows NT Workstation 3.5, or later
-
Windows NT Server 3.5, or later
-
Windows for Workgroups 3.11, or later
-
Windows 95 clients
When a computer starts and its MaintainServerList parameter is set to Auto, the master browser is responsible for telling the system whether or not to become a backup browser.
When a computer becomes the master browser by winning an election, and the browse list is empty, the master browser forces all systems to announce. The master browser broadcasts a RequestAnnouncement datagram. All computers that receive this datagram must answer randomly within 30 seconds. This 30-second range for response prevents the master browser from becoming overloaded and losing replies, and protects the network from being flooded with responses.
Figure 3.4: Browsing for Backup Lists
A master browser cannot be forced to rebuild the browse list for a workgroup or domain. However, shutting down and restarting a computer that is configured as the preferred master browser, or stopping and restarting the Browser service, forces the build of a new browse list. When a preferred master browser starts, it forces an election, which it will win. Because there is no browse list, it then forces all members of the domain or workgroup to announce themselves.
If a master browser receives an announcement from another computer that claims to be the master browser, the master browser will demote itself from master browser and force an election. This ensures that there is never more than one master browser in each workgroup or domain.
Non-browser Announcements
A non-browser computer periodically announces itself to the master browser by sending a directed datagram to the master browser on the network. Initially, each non-browser will announce itself every minute. The announcement interval will be extended to once every 12 minutes. The computer announces its availability in intervals of 1 minute, 2 minutes, 4 minutes, 8 minutes, 12 minutes, 12 minutes, and then announces to the master browser only every 12 minutes. If the master browser has not heard from the non-browser for three consecutive announcement periods, the master browser will remove the non-browser from the browse list.
Potential -browser Announcements
Most computers are potential browsers; that is, they are capable of becoming either backup browsers or master browsers. These computers announce themselves in the same manner as non-browsers.
Backup-browser Announcements
Backup browsers are a subset of potential browsers and announce themselves in the same manner as non-browsers. However, backup browsers participate in browser elections. Backup browsers call the master browser every 15 minutes to obtain updated network-resource browse lists and lists of workgroups and domains. The backup browser caches these lists and returns the browse list to any client that sends out a browse request by making a call, using the NetServerEnum API, to the backup browser. If the backup browser cannot find the master browser, it will force an election.
Because it can take up to 15 minutes for a backup browser to receive an updated browse list, it is possible that a computer will appear in the browse list for as long as 51 minutes after it is no longer an available resource on the network. The time period consists of 36 minutes, which is three 12-minute announcement cycles plus the 15 minutes for the backup browser to receive an updated list.
Configuring the Browser Announcement Time
You can change how often a browser client announces itself. In the registry path, under:
HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \LanmanServer \Parameters
add the Announce parameter with a type of REG_DWORD, and set the number of seconds that the browser should wait between announcements. For example, if the default for Announce is 12 minutes, the length of time is set to 720.
The Announce value must be changed on all computers in the workgroup or domain before the new value can be used by all computers. As you decrease this value, announcement traffic increases. Increasing the Announce value reduces the amount of announcement traffic, but will increase the length of time that a shutdown computer will appear on the browse list.
Browser Requests
The purpose of the Browser service is to make a list of network resources available to users. To use this resource list, the client computer must know which computer to contact to request a copy of the list.
Figure 3.5: Flow of the Browser Request
The request issued to obtain the list of available network resources is a NetServerEnum API call. This request is sent when net view is entered at the command prompt or when the Map Network Drive dialog box lists the network resources. The client issues the NetServerEnum API call to a backup browser.
If this is the first time that a NetServerEnum API call is issued on the client computer, the computer must first find out which computers are the backup browsers for its workgroup or domain before it can send the API call. The client does this by issuing a GetBackupList datagram to the master browser.
The master browser receives and processes the GetBackupList request. The master browser returns a list of backup browsers active within the workgroup or domain being queried. The client selects the names of three backup browsers from the list and stores these names for future use. The NetServerEnum API call is sent to a backup browser randomly chosen from the three saved names.
If the master browser for the workgroup or domain being queried cannot be found after three attempts, the client will force the election of a new master browser in the domain. The client returns an ERROR_BAD_NETPATH message to the application, indicating that the master browser could not be found.
Number of Browsers in a Domain or Workgroup
The following rules determine the number of browsers in a domain or workgroup. In this discussion, the words domain and workgroup are used interchangeably.
If there is currently a PDC in the domain, it will be the master browser for the domain.
Every BDC in the domain will be a backup browser for the domain. The only exception to this is if the BDC is needed as a master browser because the PDC has failed. In that case, the BDC will be the master browser for the domain.
If a computer's MaintainServerList registry parameter is set to Yes, this computer will be a backup browser for the domain or TCP/IP subnet.
If no backup browsers are selected for the domain based on the preceding rules, the master browser determines the number of backup browsers for the domain. If a computer's MaintainServerList registry parameter is set to Auto, the master browser will select some of those computers to act as backup browsers based on the number of computers in the domain.
Table 3.3 Number of browsers in a domain or workgroup
| Number of Computers | Number of Backup Browsers | Number of Master Browsers |
| 1 | 0 | 1 |
| 2 to 31 | 1 | 1 |
| 32 to 63 | 2 | 1 |
For each additional 32 computers added to the domain, another backup browser is selected for the domain.
For the TCP/IP transport, each subnet independently enforces the preceding set of rules.
Browser Shutdown or Failure
If a backup browser shuts down properly, it sends an announcement to the master browser that it is shutting down. The backup browser does this by sending an announcement that does not include the Browser service in the list of running services.
If a Master Browser shuts down gracefully, it will send a ForceElection datagram so that a new master browser can be chosen.
If a computer does not shut down properly or if it fails for any reason, it must be removed from the browse list. The Browser service handles browser failures.
Non-browser Failure
When a non-browser fails, it stops announcing itself. The configured announcement period is between 1 and 12 minutes. If the non-browser has not announced itself after three announcement periods, the master browser removes the computer from the browse list. Therefore, it can take up to 51 minutes before all browsers know of a non-browser's failure. This figure includes up to 36 minutes for the master browser to detect the failure, and 15 minutes for all of the backup browsers to retrieve the updated list from the master browser.
Backup-browser Failure
As with a non-browser failure, when a backup browser fails, it may not be removed from the master-browser list for up to 51 minutes. If a browse list cannot be obtained from the missing backup browser, the client selects another backup browser from its cached list of three backups. If all of the client's known backup browsers fail, 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, the client forces an election.
Master-browser Failure
When a master browser fails, a backup browser detects the failure within 15 minutes and forces an election of a new master browser.
If a client performs its browse request (using the NetServerEnum API call) after a master browser fails 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 will not function correctly.
During the gap between the master browser's failure and the election of a new master browser, the workgroup or domain can disappear from the lists that are visible to computers in other workgroups and domains.
Domain Master-browser Failures
If the domain master browser fails, the master browser for each network segment provides a browse list, containing only the servers in the local network segment. All servers that are not on the local network segment will eventually be removed from the browse list. Users will still be able to connect to servers on the other network segments if they know the name of the server.
Because a domain master browser is also a PDC, an administrator can correct the failure by promoting a BDC to PDC. A BDC can perform most PDC network tasks, such as validating logon requests, but does not promote itself to PDC and does not become domain master browser in the event of a PDC failure.
Figure 3.6: Master browser failure
Browse Service Across Multiple Workgroups and Domains
Users need to browse multiple workgroups and domains to retrieve a list of servers within their workgroup or domain and a list of other workgroups and domains.
Figure 3.7: Browser service across multiple workgroups and domains
Upon becoming a master browser, each master browser in each workgroup and domain will broadcast a DomainAnnouncement datagram every minute for the first five minutes. After the first five minutes, the master browser will broadcast a DomainAnnouncement datagram once every 15 minutes. If a workgroup or domain has not announced itself for three announcement periods, the workgroup or domain will be removed from the list of workgroups and domains. Therefore, it is possible that a workgroup or domain will appear in the browse list 45 minutes after the workgroup or domain has failed or been shut down.
A DomainAnnouncement datagram contains the following information.
If the browser computer is running Windows NT Server, the DomainAnnouncement datagram will also specify whether or not the browser computer is the domain PDC.
Browse Service Across a Wide Area Network (WAN)
When using domains that are split across routers, each TCP/IP network segment functions as an independent browsing entity with its own master browser and backup browsers. Therefore, browser elections occur within each network segment.
Domain master browsers are responsible for spanning the network segments to collect computer-name information, in order to maintain a domain-wide browse list of available resources. The domain master browser and cooperating master browsers on each WAN segment provide browsing of domains that exist across multiple TCP/IP network segments. The domain master browser is the PDC of a domain. The master-browser computers on the subnets can be running Windows NT Server, Windows NT Workstation, Windows for Workgroups version 3.11b, or Windows 95.
Figure 3.8: Browser service across a WAN
When a domain spans multiple network segments, the master browsers for each network segment use a directed datagram called a MasterBrowserAnnouncement datagram to announce themselves to the domain master browser. The MasterBrowserAnnouncement datagram notifies the domain master browser that the sending computer is a master browser in the same domain and that the domain master browser needs to obtain a copy of the master browser's browse list. When the domain master browser receives a MasterBrowserAnnouncement datagram, it sends a request to the network segment's master browser, which announced itself in order to collect a list of the network segment's servers.
The domain master browser then merges its own server list with the server list from the master browser that issued the announcement. This process is done every 15 minutes and guarantees that the domain master browser has a complete browse list of all the servers in the domain. When a client issues a browse request to a backup browser, the backup browser returns a list of all the servers in the domain, regardless of the network segment on which they are located.
Workgroup using Windows NT or Windows for Workgroups cannot span multiple network segments. Any workgroup of either kind that does span network segments will function as two separate workgroups with the same name.
Browse Service Across a WAN with TCP/IP
Currently, Browser-service communication relies almost entirely on broadcasts. In a WAN environment, such as TCP/IP, where domains are separated by routers, special broadcast problems can arise because broadcasts, by default, do not pass through routers. There are two issues to consider.
The following topics discuss three methods that can be used to set up WAN browsing with TCP/IP. They are presented in order of preference.
The Windows Internet Name Service (WINS)
The Windows Internet Name Service (WINS) resolves NetBIOS names to IP addresses so that datagrams can be sent to the targeted computer. Implementing WINS eliminates the need to configure the LMHOSTS file or to enable UDP port 137. Using WINS requires the following configuration.
-
WINS is configured on a computer running Windows NT Server 3.5 or later.
-
Clients are WINS-enabled.
WINS clients can be configured with Windows NT 3.5 or later, Windows 95, Windows for Workgroups 3.11b running TCP/IP-32, LAN Manager 2.2c for MS-DOS, or Microsoft Network Client 3.0 for MS-DOS. The latter two are provided on the compact discs for versions 3.5 or later of Windows NT Server.
We usually recommend that you implement WINS for name resolution and browsing support. As an alternative, it is possible to have full domain browsing by using only LMHOSTS files on all computers, but this limits browsing to the local domain. Non-WINS clients still need the LMHOSTS file to browse a WAN, even if WINS has been implemented in the domain.
Note: A client will participate in domain browsing only when that client is using a workgroup name that is equivalent to the domain name (workgroup=domain). In the case of Windows NT computers, they can also join the domain to gain this functionality, instead of participating in a workgroup.
The LMHOSTS File
NetBIOS name resolution is typically performed through broadcasts, which will resolve names only on the local network segment. To resolve names of computers located on another network segment, the LMHOSTS file (located under \<winnt_root>\System32\drivers\etc) must be configured. The LMHOSTS file must contain a NetBIOS name-to-IP address mapping for all computers that are not on the local network segment.
To implement communication between network segments and the domain master browser, the administrator must configure the LMHOSTS file with the NetBIOS names and IP addresses of all browsers. To ensure that the master browser for each network segment can access the domain's PDC, the PDC for each domain must exist in the LMHOSTS file on each master browser and have the #DOM tag.
The LMHOSTS file on each network segment's master browser should contain the following information.
-
IP address and NetBIOS name of the domain master browser
-
The domain name, preceded by the tags #PRE and #DOM, as in the following example
130.20.7.80 <Browser_name> #PRE #DOM:<domain_name>
To guarantee that the PDC can request the local browse list from the network segment's master browser, TCP/IP and all other WAN transports must cache the client's IP address.
UDP Port 137 (NetBIOS Name Service Broadcasts)
Not all WANs will have problems browsing. Some routers can be configured to forward specific types of broadcasts and filter out others.
All NetBIOS over TCP/IP (NetBT) broadcasts are sent to the UDP port 137, which is defined as the NetBT Name Service. This usage is defined by Request for Comment (RFC) 1001 and 1002. Routers normally filter out these frames because they are sent to the hardware and subnet broadcast addresses. However, some routers allow all frames sent to this particular UDP port — which is used only by NetBT—to be forwarded. As a result, the browser looks as if it is on one, big, network segment. All domains and computers within the network segments are seen by all computers, including Windows for Workgroups computers.
Windows for Workgroups and Windows 95 as Master Browsers
The Vserver.386 and Vredir files on the Windows NT Server versions 3.51 and 4.0 compact discs are different from the files of the same names on the Windows NT Server version 3.5 compact disc.
These two files have been modified so that computers running Windows for Workgroups 3.11b or Windows 95 can be master browsers for a network. This enables a computer on a network with computers running only Windows for Workgroups 3.11b and Windows 95 to browse Windows NT domains on other networks.
As the master browser for the network, a computer running Windows for Workgroups 3.11b or Windows 95 will communicate with the PDC of the domain to obtain the browse list for the entire domain.
The Windows for Workgroups 3.11b or Windows 95 master browser will function as if a Windows NT master browser were on the network. The Windows for Workgroups 3.11b or Windows 95 master browser will contact the PDC every 15 minutes to give it the local network's browse list and to obtain the domain-wide browse list.
The following conditions must exist for a computer running either Windows for Workgroups 3.11b or Windows 95 to function properly as a master browser.
-
The computer must also be running TCP/IP.
-
WINS must be used for name resolution.
-
The domain's PDC must be a WINS client.
-
The Windows for Workgroups 3.11b or Windows 95 client must be in a workgroup that has the same name as the domain, and must also be a WINS client.
Microsoft LAN Manager Interoperability
For interoperability between Windows NT Workstation or Windows NT Server and LAN Manager browsers, some configuration is required.
Selecting the Make Browser Broadcasts to LAN Manager 2.x Clients check box causes the browser to announce itself to LAN Manager 2.x computers using a LAN Manager-compatible server announcement. The default configuration is not to send announcements to LAN Manager 2.x computers.
To activate Make Browser Broadcasts to LAN Manager 2. x Clients
-
Click Start, point to Settings, and click Control Panel.
-
Double-click Network.
-
Click the Services tab.
-
Double-click Server.
-
Select the Make Browser Broadcasts to LAN Manager 2.x Clients check box, and then click OK.
To configure this option on a Windows NT Workstation, change the Lmannounce parameter entry to 1 in the registry under the following path:
\HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \LanmanServer \Parameters
Each computer can be configured to browse up to four other LAN Manager domains. These domains are the LAN Manager-only domains that the local computer is interested in browsing. If any other domains are configured on a domain master browser, the other domains are provided to all members of the domain.
To configure other domains, in the registry under:
\HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \LanmanWorkstation \Parameters
add a value of OtherDomains with a type of REG_MULTI_SZ, and supply the other domain names.
Browser System Components
The Browser system consists of two components, the Browser service and the datagram receiver.
The Browser service is the user-mode portion of the Browser system and is responsible for maintaining the browse list, sending the API requests, and managing the various browser roles that a computer can have.
The Browser service actually resides within the Service Controller process (Lmsvcs.exe) and can be found under \<winnt_root>\system32. The Browser service is located in the registry path under the following key.
\HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Browser
The datagram receiver is the kernel-mode portion of the Browser system and is simply a datagram and mailslot receiver. It receives directed and broadcast datagrams that are of interest to the Windows NT Workstation and Windows NT Server services. The datagram receiver also provides kernel-level support for the NetServerEnum API, support for remote mailslot reception (second-class, datagram-based, mailslot messages), and the request-announcement services.
In Windows NT 3.5 and later, the datagram receiver is implemented in the Windows NT redirector (Rdr.sys). In Windows NT 3.1, there is a separate driver, Browser.sys, for the datagram receiver.
Monitoring Browsers
The Microsoft Windows NT Server Resource Kit 4.0 includes two utilities, Browmon.exe and Browstat.exe, that can be used to monitor the browsers within a workgroup or domain.
Browmon.exe
Browmon.exe is a graphical utility that can be used to view browsers — both the master and backups — for selected domains. It lists the browser servers for each protocol in use by computers in the domain.
Information: to open the Information dialog box, which shows the number of server announcements, domain announcements, election packets, and so forth.
Browstat.exe
Browstat.exe is a command-line utility that can be used to view the Browser servers — both the master and backups — in the specified workgroup or domain. Browstat.exe has some capabilities that Browmon.exe does not have, such as the ability to force an election and the ability to force a master browser to stop so that an election occurs.
Browstat.exe includes the following options.
Usage: BROWSTAT Command [Options | /HELP]
Where <Command> is one of:
ELECT ( EL) - Force election on remote domain
GETBLIST ( GB) - Get backup list for domain
GETMASTER ( GM) - Get remote Master Browser name (using NetBIOS)
GETPDC ( GP) - Get PDC name (using NetBIOS)
LISTWFW (WFW) - List WFW servers that are actually running browser
STATS (STS) - Dump browser statistics
STATUS (STA) - Display status about a domain
TICKLE (TIC) - Force remote master to stop
VIEW ( VW) - Remote NetServerEnum to a server or domain on transport
How to Find the Master Browser: Example
To find the master browser for a domain, the following command line must be used.
browstat getmaster <transport> <domain_name>
Where <transport> is one of the protocols installed on the system, in the form reported by net config rdr on the following Workstation active on line.
NwlnkNb NetBT_Lance1 NetBT_EE162 Nbf_Lance1
For example, the following command could be used to find the master browser for a domain named Seattle.
browstat getmaster NetBT_Lance1 Seattle
Note: When using Browstat.exe, you can use either the full command or the two- or three-character abbreviation, such as gm instead of getmaster.