The computer browser service was first introduced in Microsoft Windowsfor Workgroups 3.1. The purpose of the browser service is to collect andreport information about the existence of other computers on the network that sharefile, print, and other resources. The browser service greatly reduces thenumber of server announcements on a network. The browser service also reduces the overheadof every network client and server because clients and servers do nothave to maintain their own list of server resources.
The browser service was originally designed for computers connected on asingle-segment local area network (LAN) using a nonroutable protocol,such as NetBIOS Extended User Interface (NetBEUI). If a client requesteda list of servers from a multihomed browser server, the browser servicewould provide only the list of servers gathered on the network adapterthat received the browse request. This was done because it could not beassumed that a client would be able to connect to servers on the othersegment. When you use a nonroutable protocol, such as NetBEUI, a clientalso must be multihomed to connect to a remote server. When you use aroutable protocol, such as Transmission Control Protocol/InternetProtocol (TCP/IP), an infrastructure of routers must be in place forthe physical connection to be possible. Also, there must be anLmhosts file that is configured for all clients that have the potential to connect tothe remote servers.
Microcomputer networks have since evolved into much larger environmentsthat require routable protocols and distributed NetBIOS naming servers,such as the Windows Internet Naming Service (WINS) for NetBIOScommunication. With the growth of segmented LANs, the browser service hasbeen 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 masterbrowsers on each segment across the wide area network (WAN). This role iscalled 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 ofall the domains throughout the network. This allows for full browsing ofserver resources throughout the WAN.
The evolution of networking has also increased the number of servers andclients that have more than one network adaptor. Multihomed servers can createunexpected and undesirable effects with the browser service.
Domain master browser issues: PDCNote
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 thelist of additional domain names from the PDC, it sends aMasterAnnouncement frame to the PDC. This signals the PDC to retrieve alist of servers and workgroup announcements from the master browser.
Because all NetBIOS sessions between any two servers over TCP/IP can onlyreside on a single IP connection, there is no way for the PDC to maintainmore than one IP address for the master browser's computer name. Therefore, any server that is a master browser cannot be multihomedbecause the PDC will contact only the master browser on one of itsnetwork adapters.
If a multihomed server is a master browser on both network adaptors, thePDC collects only the hosts that are discovered by the network adaptor that itis connected to. All other servers and domain names that are discovered on theother network adaptor are lost to the rest of the domain. If a multihomed server is a master browser on one network adaptor and a backupbrowser or a non-browser by election, or the UnboundBindings setting onthe other network adaptor, there is no way to guarantee that the PDC willconnect to the master browser's network adaptor. If the master browserhas two network adapters, the odds of connecting to the correct interfaceare 50 percent. If the wrong network adapter is selected, all serversand domain names that are collected by this master browser are unavailableto 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 amaster browser can be multihomed. When a client requests a browse list,the client issues a GetBackupListRequest, and the response contains a list ofcomputer names. The client then establishes a session to one of thecomputer names in the response frame. If the chosen network adaptor isnot running the browser service, the client does not receive a browselist. Therefore, no backup browsers can be multihomed. If the chosen networkadaptor is a browser, the list received may contain serversthat are collected by a master browser on another segment, thereby removing thedeterministic nature of the browser infrastructure.
Suggestions for workaround
How to make sure that the browser servers aresinglehomed and enable the browsing service to operate correctlyImportant
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:
How to back up and restore the registry in Windows
By default, all domaincontrollers in a domain are browser servers. Therefore, thesuggested workarounds can help to ensure that the browser servers aresinglehomed and that they enable the browsing service to operate correctly.
To prevent multihomed Microsoft Windows NT servers from becoming browser servers, follow these steps:
- 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 registrysubkey:
Change the value of this subkey to false
, quitRegistry 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
, quitRegistry 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 view and transfer FSMO roles in the graphical user interface
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:
- In Control Panel, double-click Network.
- Click the Bindings tab.
- In the Show Bindings For box, select All Adapters.
- Expand all the adaptors.
- Select WINS Client (TCP/IP), and then click Disable.