The life of an NT systems administrator is fraught with peril. In one location, you have a rapidly growing network with about 240 client nodes running a combination of Windows NT 4.0 Workstation, Windows 95, and a few Windows for Workgroups (WFW) 3.11 machines (you just haven't had the time to standardize, or maybe you have no choice). You also have six NT 4.0 servers with one Primary Domain Controller (PDC) and--because you're paranoid--three Backup Domain Controllers (BDCs) for your single-domain structure (DOMAIN_MAIN), an Exchange server, and a SQL server. The BDCs also function as your print servers. The six NT servers contain all network files and necessary resources. The company has standardized on TCP/IP but has yet to implement routers, so you have decided not to implement Windows Internet Name Service (WINS) at this time. Because you have a legacy NetWare server, you are also running IPX/SPX (NWLink). Your users access the NetWare box using NT's Gateway Services for NetWare, and you plan to phase it out in the near future.
|Boost your network performance by disabling unnecessary server components and taking charge of the browser|
You are steadily replacing the old WFW machines with new hardware running NT 4.0 Workstation (good move). Life used to be good. But over the past few months, as you've added more nodes to the wire, the system has begun to slow down at unpredictable times. And to top it all off, every client's Network Neighborhood (Connect Network Drive in the WFW machines) now lists most of the 240 nodes and the six NT servers.
Your customers are complaining about several problems: 1) general network performance is slower than it used to be and getting worse ("Some upgrade!"); 2) mapping drives is a pain because the NT servers and the NT clients are all lumped together in the same list under DOMAIN_MAIN, and the Win95 and WFW clients are listed in the first screen instead of being grouped in a domain; and 3) every once in a while, for no reason, the entire network slows to a crawl for what seems like a minute or two, causing timeouts, resends, and ticked-off users. You are at a loss because you bought high-end hardware and followed all of Microsoft's default installation instructions. Deep inside, you're certain that if you don't fix this problem soon, management is going to suggest that you call a consultant. That possibility is not good in your environment: The last consultant they called is now the CIO.
But don't despair. Some slowdown in network performance is a result of the way Microsoft handles network browsing. By making some minor changes in the server components in your system and disabling the browser, you can recoup some of your lost performance.
Clients and Servers
To better understand Microsoft's network browsing, let's look briefly at some of the technology underlying all Microsoft operating systems since WFW 3.1. I'm oversimplifying a bit, but every Microsoft operating system contains two major component types that govern network access: a workstation component and a server component. These components take the form of services in NT, but they exist in Win95 and WFW, too.
In Win95 and WFW, you can't separate the workstation component from the product. Each of these products exists simply to be the OS for standalone boxes or workstations on a network. However, in both NT Workstation and Server, the workstation component is a separate service that you can manage individually through the Services applet in Control Panel. The purpose of this service is to provide the client portion of a client/server connection--that is, to connect to shared folders and shared printers in a Microsoft network.
The server component creates the capability for a given machine (running WFW, Win95, LanMan, or NT) to function as a server on the network. Active by default, this component lets you share directories, folders, and printers so that clients running the workstation component can connect to the server machine. On request, Network Neighborhood or Connect Network Drive presents lists of every computer (grouped by domain or workgroup) that has an active server component in the Microsoft network, even if a particular computer has nothing shared (no folders, no printers). By default, the computer's Browser service (which runs automatically in all Microsoft OSs) manages the creation of this list.
The NT Browser service is designed to give users a dynamically updated list of available resources (in Network Neighborhood or Connect Network Drive). The Browser runs under the covers in every Microsoft network.
A master browser runs the Browser service. A master browser is a machine that acts as a sort of name service that keeps track of all servers that report themselves to it; it creates and maintains the browse list. A backup browser receives the browse list from the master browser and sends it to computers that ask for it. (For more information about browsers, see Mark Minasi, "Domains and Workgroups," April 1996.)
Every computer with the server component active announces itself as it boots (technically, as every service starts) to the master browser at 1, 2, 4, 8, and then 12 minute intervals, and then continues to announce itself every 12 minutes as long as the computer or service is up. The backup browsers also get a fresh copy of the master browser list every 12 minutes. (You can find out which of your machines is serving in what browser capacity with the browser monitor utility--Browmon.exe--in the Windows NT Server 4.0 Resource Kit.) When the user clicks on Network Neighborhood, the client software requests a current list of resources (any machine with the server component running) from the backup browser. That list of servers shows up in the Network Neighborhood (or Connect Network Drive) window. When the user double-clicks on a particular computer, NT sends a request directly to that computer to return a list of its shared resources. The user then sees a display of that list.
Conceptually, the Browser service is hierarchical. In DOMAIN_MAIN, for example, because the PDC and the BDCs are on the same subnet, the PDC becomes the domain master browser, and two of the BDCs are backup browsers. After you add routers to the network, each subnet will have a master browser, probably a BDC.
Master and Backup Browsers
The system chooses master and backup browsers through an election process. This election is like playing king of the hill, with an assistant king of the hill, and king of the sub-hill, with an assistant king of the sub-hill. The process runs something like this: Every time a domain controller boots, a browser election takes place. The PDC will always win the domain master browser role, and a BDC will always win the backup browser role (unless you have a BDC on a different subnet from the PDC; in that case, one BDC will be the master browser on that subnet). Special broadcast election packets announce these elections, and every machine that has its server component settings active participates (the server component is turned on in all machines by default).
These domain controller elections work fairly well because when computers with server components broadcast election packets, the packets contain the information that the computers are NT 4.0 servers and domain controllers, and NT server domain controllers are always king of the hill. The problem with this arrangement occurs when an ordinary client--let's say a WFW machine--requests a browse list from the Browser service and doesn't get a timely answer. The WFW client then calls an election and sends out a broadcast election packet proclaiming to one and all, "I am the master browser unless someone more powerful than me responds." Because every machine on the network is more powerful than the WFW client, this announcement forces every machine (with active server component settings) to respond. In many networks, hundreds of machines might send election packet responses to knock this guy off. After several seconds of the election broadcast storm, the winners are decided, and (surprise!) they are the NT servers again.
Solving the Problem
The solution to the performance problem that browsing creates is to turn off the server component on every machine that is not performing the server function. To turn off the server component in NT Workstation, from Control Panel, select Services, and highlight Server, as you see in Screen 1. Click Startup and then Disabled, as Screen 2 shows. Click OK, then Close, then reboot.
On any NT box that is not functioning as a server, you must also disable the Computer Browser service. From Control Panel, Services, select Computer Browser, Startup, Disabled. If you don't disable the Computer Browser, you will receive error messages on bootup. But don't disable the Server service or the Browser service on the real NT servers in your network. These NT servers are supposed to have the server component active and announce themselves to the world and share their stuff.
In Win95, go to Control Panel, Network. Highlight File and printer sharing for Microsoft Networks, as you see in Screen 3. Click Remove.
In WFW, use Notepad or Sysedit to add the following entry to the SYSTEM.INI:
This command disables the server components; the user can't turn them back on without editing the SYSTEM.INI.
After you've disabled the server components, these client machines won't announce themselves to the computer Browser service, nor will they participate in any browser elections, thus eliminating a sizable portion of the total network traffic. In addition to disabling the server components, don't forget to trim additional network traffic by eliminating unnecessary network protocols wherever possible. This action will reduce browser-related traffic even further.
Pros and Cons
By disabling the server components on nonserver machines of all types, you can reduce network traffic by 30 percent to 40 percent, increase overall network performance dramatically, and clean up the Network Neighborhood display in Win95 clients. The disadvantages of disabling the Server components are that NT users can't use Network Neighborhood to browse the network; instead, Administrators (not users) must map drive letters to shares via logon scripts, NET USE, or persistent connections. In addition, the Administrative shares (C$, D$, E$, ADMIN$) become unavailable for remote administration.
Some situations require the server components to remain active, such as when individual users have a shared printer or shared team or project folders on their hard drive. An NT Workstation user may also want the ability to browse network resources and choose them at will. In those cases, you can make one beneficial change to every machine that must run the server component but that you don't want to participate in browser elections and that you never want to be the master or backup browser.
By editing the Registry, you can prevent each machine from becoming a master browser and from participating in browser elections. At the same time, you still let them function as servers and place themselves (and their respective shares) on the list of available resources. NT Workstations also will be able to browse the network using Network Neighborhood.
In NT (Workstation or Server), edit the Registry. In HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Browser\Parameters change the value of the REG_SZ entry in MaintainServer List to No.
To make the same change in Win95, go to Control Panel, Network, as Screen 3 shows. Highlight File and printer sharing for Microsoft Networks, click Properties, and set the value for Browse Master to Disabled. In WFW, comment out or remove the previously described entry that disabled the browser, and add the following entry to the SYSTEM.INI:
Server components and browsing have always been an integral part of Microsoft networking. This arrangement has worked well in the past for small networks. But as Microsoft and NT push toward larger enterprise networks, browsing and the electoral process have to go. NT 5.0 eliminates the concept of browsing. Until then, users have no choice but to carefully tweak their NT 4.0 and NT 3.51 networks to make them fly.