Symptoms of Multihomed Browsers

ID: Q191611

The information in this article applies to:

Microsoft Windows NT Server version 4.0
Microsoft Windows NT Workstation version 4.0
Microsoft Windows NT Server, Enterprise Edition version 4.0

IMPORTANT: This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restoring the Registry" Help topic in Regedit.exe or the "Restoring a Registry Key" Help topic in Regedt32.exe.

SUMMARY

The computer browser service was first introduced in Microsoft Windows for Workgroups 3.1. The purpose of the browser service is to collect and report the existence of other computers on the network that are sharing file, print, and other resources. The browser service greatly reduces the number of server announcements on a network, and it reduces the overhead of every network client and server because clients and servers do not have to maintain their own list of server resources.

The browser service was originally designed for computers connected on a single-segment local area network (LAN) using a non-routable protocol, such as NetBIOS Extended User Interface (NetBEUI). If a client requested a list of servers from a multihomed browser server, the browser service would provide only the list of servers gathered on the network adapter that received the browse request. This was done because it could not be assumed that a client would be able to connect to servers on the other segment. When you use a non-routable protocol, such as NetBEUI, a client also has to be multihomed to connect to a remote server. When you use a routable protocol, such as the Transmission Control Protocol/Internet Protocol (TCP/IP), an infrastructure of routers needs to be in place for the physical connection to be possible. This was in addition to an LMHOSTS file configured for all clients that potentially could connect to the remote servers.

Microcomputer networks have since evolved into much larger environments that require routable protocols, and distributed NetBIOS naming servers such as the Windows Internet Naming Service (WINS) for NetBIOS communication. With the growth of segmented LANs, the browser service has been updated to accommodate the TCP/IP protocol in a domain environment. To obtain a single domain-wide browse list, the primary domain controller (PDC) has the role of merging all the browse lists gathered by the master browsers on each segment across the wide area network (WAN). This role is called the domain master browser and can only be performed by the PDC. WINS allows clients to easily access remote servers throughout the WAN, and each PDC periodically contacts the WINS server to obtain a list of all the domains throughout the network. This allows for full browsing of server resources throughout the WAN.

The evolution of networking has also increased the number of servers and clients with more than one network adapter. Multihomed servers can create unexpected and undesirable effects with the browser service.

MORE INFORMATION

Domain Master Browser Issues - PDC

The PDC cannot be multihomed for there to be a single domain-wide list of servers because the browser maintains a separate list of servers for each network adapter and protocol combination. If the PDC is multihomed, there are two partial cumulative lists built for the domain, and no one computer in the network can access the full list of servers in the domain. Each master browser can retrieve the list of servers from only one of the PDC's network adapters. The list of servers that the PDC builds on each network adapter is not deterministic because it depends on which network adapter the PDC uses to contact the master browser.

Windows NT 4.0 introduced the UnboundBindings registry entry that effectively turns off the browser for each network adapter specified. Even with the browser running only on one network adapter on the PDC, there is no way to guarantee that a master browser will only access the PDC through the active network adapter. All master browsers that communicate with the unbound network adapter on the PDC cannot receive the list of additional servers in the domain, nor the list of additional domains found in WINS or by other master browsers.

Therefore, to build a single domain-wide list of servers, the PDC cannot be multihomed.

Master Browser Issues

After the master browser obtains a list of servers in the domain and the list of additional domain names from the PDC, it sends a MasterAnnouncement frame to the PDC. This signals the PDC to retrieve a list of servers and workgroup announcements from the master browser.

Because all NetBIOS sessions between any two servers over TCP/IP can only reside on a single IP connection, there is no way for the PDC to maintain more than one IP address for the master browser's computer name. This means that any server that is a master browser cannot be multihomed because the PDC will contact only the master browser on one of its network adapters.

If a multihomed server is a master browser on both network adapters, the PDC will collect only the hosts discovered by the network adapter that it is connected to, and all other servers and domain names discovered on the other network adapter will be lost to the rest of the domain. If a multihomed server is a master browser on one network adapter and a backup browser or a non-browser by election or the UnboundBindings setting on the other network adapter, there is no way to guarantee that the PDC will connect to the master browser's network adapter. If the master browser has two network adapters, the odds of connecting to the correct interface are fifty percent. If the wrong network adapter is selected, all servers and domain names collected by this master browser will not be available to the rest of the domain.

Therefore, for the PDC to centrally collect all server and domain names, all master browsers must not be multihomed.

Backup And Potential Browser Issues

Because browser roles are determined by election, no server that can be a master browser can be multihomed. When a client requests a browse list, it issues a GetBackupListRequest, and the response contains a list of computer names. The client then establishes a session to one of the computer names in the response frame. If the network adapter chosen is not running the browser service, the client will not receive a browse list. Therefore, no backup browsers can be multihomed. If the network adapter selected is a browser, the list received may contain servers collected by a master browser on another segment, thereby removing the deterministic nature of the browser infrastructure.

Suggestions for Workaround

WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.

For information about how to edit the registry, view the "Changing Keys And Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe. Note that you should back up the registry before you edit it.

The PDC must be singlehomed for browsing to operate correctly. All domain controllers in a domain are by default browser servers. Therefore, the workarounds below can help ensure that the browser servers are singlehomed and enable the browsing service to operate correctly.

To prevent multihomed Windows NT servers from becoming browser servers:

Click Start, point to Settings, click Control Panel, and then double- click Services.

Click Computer Browser, click Properties, and then click Manual.

Click OK, click Close, and then restart the computer.

Or, use Registry Editor (Regedt32.exe) to edit the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Browser\Parameters\MaintainServerList

Change the value of this key to "false" (without quotation marks), quit Registry Editor, and then restart your computer.

To encourage singlehomed computers to become the browser servers:

Use Registry Editor (Regedt32.exe) to edit the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Browser\Parameters\IsDomainMaster

Change the value of this key to "yes" (without quotation marks), quit Registry Editor, and then restart your computer.

Keywords : kbenv kbnetwork ntdomain
Version : winnt:4.0
Platform : winnt
Issue type : kbinfo