Symptoms of multihomed browsers

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 information about the existence of other computers on the network that share file, print, and other resources. The browser service greatly reduces the number of server announcements on a network. The browser service also 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 nonroutable 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 nonroutable protocol, such as NetBEUI, a client also must be multihomed to connect to a remote server. When you use a routable protocol, such as Transmission Control Protocol/Internet Protocol (TCP/IP), an infrastructure of routers must be in place for the physical connection to be possible. Also, there must be an Lmhosts file that is configured for all clients that have the potential to 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) merges all the browse lists that are gathered by the master browsers on each segment across the wide area network (WAN). This role is called the domain master browser and can be performed only 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 that have more than one network adaptor. Multihomed servers can create unexpected and undesirable effects with the browser service.

Domain master browser issues: PDC

Note The domain master browser in Windows 2000 is the PDC emulator operations master (also known as flexible single master operations or FSMO). The PDC cannot be multihomed for there to be a single domain-wide list of servers. This is because the browser maintains a separate list of servers for each network adaptor and protocol combination. If the PDC is multihomed, there are two partial cumulative lists built for the domain, and no single 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 adaptors. The list of servers that the PDC builds on each network adaptor is not deterministic because it depends on which network adapter the PDC uses to contact the master browser.

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. Therefore, 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 adaptors, the PDC collects only the hosts that are discovered by the network adaptor that it is connected to. All other servers and domain names that are discovered on the other network adaptor are lost to the rest of the domain. If a multihomed server is a master browser on one network adaptor and a backup browser or a non-browser by election, or the UnboundBindings setting on the other network adaptor, there is no way to guarantee that the PDC will connect to the master browser's network adaptor. If the master browser has two network adapters, the odds of connecting to the correct interface are 50 percent. If the wrong network adapter is selected, all servers and domain names that are collected by this master browser are unavailable 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, the client 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 chosen network adaptor is not running the browser service, the client does not receive a browse list. Therefore, no backup browsers can be multihomed. If the chosen network adaptor is a browser, the list received may contain servers that are collected by a master browser on another segment, thereby removing the deterministic nature of the browser infrastructure.

Suggestions for workaround

How to make sure that the browser servers are singlehomed and enable the browsing service to operate correctly

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
By default, all domain controllers in a domain are browser servers. Therefore, the suggested workarounds can help to ensure that the browser servers are singlehomed and that they enable the browsing service to operate correctly.

To prevent multihomed Microsoft Windows NT servers from becoming browser servers, follow these steps:

1. Click Start, point to Settings, click Control Panel, and then double-click Services.
2. Click Computer Browser, click Properties, and then click Manual.
3. Click OK, click Close, and then restart the computer.

Or, use Registry Editor (Regedt32.exe) to edit the following registry subkey: Change the value of this subkey to false, quit Registry Editor, and then restart your computer.

Note In Windows 2000, instead of the value false, use the value no. To encourage singlehomed computers to become the browser servers, use Registry Editor (Regedt32.exe) to edit the following registry subkey: Change the value of this subkey to yes, quit Registry Editor, and then restart your computer.

Note The registry settings in this article do not work on a Windows 2000 domain controller if it is the PDC emulator.

For additional information about resolving this issue and to transfer these roles to a non-multihomed domain controller, click the following article number to view the article in the Microsoft Knowledge Base:

How to browse with a multihomed PDC

The domain master browser service properly binds to only one network interface. The PDC serves the role of the domain master browser. We suggest that your PDC is not multihomed.

If your PDC is multihomed because it serves as a router, and you cannot promote a singlehomed backup domain controller (BDC) to PDC, you can try the following technique to work around this problem.

Unbind the WINS Client (TCP/IP) interface from all your adaptors except for one. This will also unbind the NetBIOS, Workstation, and Server interfaces from this card. We recommend that these bindings remain on the adaptor that is on the busiest segment. Although the WINS Client (TCP/IP) interface is unbound from the other adaptors, there will still be connectivity to the PDC from the other segments. The TCP/IP Protocol interface is left bound, which will be able to route the requests to the bound interface. After unbinding the additional adaptors, you should make sure that WINS and any LMHosts files do not refer to the unbound adapters.

To unbind the WINS Client (TCP/IP) interface, follow these steps:

1. In Control Panel, double-click Network.
2. Click the Bindings tab.
3. In the Show Bindings For box, select All Adapters.
4. Expand all the adaptors.
5. Select WINS Client (TCP/IP), and then click Disable.

For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base: