Best Practices for NT Networks
George Spalding
Client or Server – It’s Decision Time!
Boost your network performance by disabling the Server components and taking charge of the Browser!
The Situation:
You have a rapidly growing network with about 240 or so client nodes in a single location running a combination of NT 4.0 Workstation, Windows 95 & a few (you just haven’t gotten around to these people or maybe you just don’t like them) WFW 3.11 machines. You also have six NT 4.0 Servers with one PDC and 3 BDCs (you’re paranoid) for your single domain structure (DOMAIN_MAIN), an Exchange Server and a SQL Server. The BDCs are also functioning as your print servers. All network files and necessary resources are contained on the six NT servers. The company has standardized on TCP/IP but has yet to implement routers (but they are coming soon) so you have decided not to implement WINS at this time. You have a legacy Netware server so you are also running IPX/SPX (NWLink).
You are steadily replacing the old WFW machines with new hardware running NT 4.0 WS (good move). Life used to be good but over the last few months as you added more and more total nodes to the wire things began to slow down at somewhat unpredictable times and to top it all off every client’s Network Neighborhood (Connect Network Drive in the WFW machines) now lists nearly all 240 nodes and the 6 NT servers. Your customers are complaining about several things: 1) general network performance is slower than it used to be and getting worse with each passing day (you hear comments like, "Some UPgrade!"); 2) mapping drives is a pain because the NT servers and the NT clients are all lumped in the same list under DOMAIN_MAIN and the 95 & WFW clients are listed in the first screen under nothing; and 3) every once in a while, for no reason whatsoever, the entire network slows to less than a crawl for what seems like minute or two causing timeouts, resends (and ticked off users). You are at a loss because you bought high-end hardware and followed all the default installation instructions from Microsoft (you even took a class)…and deep inside you are certain that if you don’t fix this problem soon management is going to suggest that you call a consultant... and that is not a good thing in your environment (the last consultant they called is now the CIO).
The Problem:
Before we go into what is actually happening let’s take a brief look at some of the underlying technology inherent in all Microsoft products released since WFW 3.1.
Oversimplifying a bit, every Microsoft operating system contains two major types of components governing network access, one is a workstation component and the other a server component. These actually take the form of services in NT but they exist in 95 & WFW as well.
The workstation component in 95 & WFW IS 95 & WFW. The reason for the existence of these products is to be a standalone box or a workstation on a network. There is no way to separate this workstation "component" from the actual product itself. On the other hand, the workstation component in NT (both Workstation and Server OS) is a separate service which can be individually managed through the Services icon in Control Panel. (Yes, NT servers have a workstation service, read on) The purpose of this service or component is to provide the client portion of a client-server connection…to connect to shared folders and shared printers in a Microsoft network. The workstation component is NOT the culprit or the cause of your problem, just leave him be.
That brings us to the server component. 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 is the component which allows us to "share" directories, folders and printers so that that "clients" (running the workstation component) can "connect" to us. Network Neighborhood presents us, upon request, with a list of every single computer in the Microsoft network (see inset for Novell solutions) with the server component active (grouped by domain or workgroup) even though that particular computer may have nothing shared (no folders, no printers). By default, the creation of this list is managed by the Computer Browser service. These server components are the true culprits but the Browser service is a willing accomplice in our problem.
Let’s talk in detail about this Computer Browser service which runs automatically in all of our MS operating systems. Designed to give users a dynamically updated list (menu) of available resources (Network Neighborhood/Connect Network Drive) it runs under the covers in every Microsoft network.
The Computer Browser service continually gathers the list of available resources on PCs called Master Browsers. Conceptually it is hierarchical in nature, let’s take DOMAIN_MAIN for example. The PDC is also the Domain Master Browser, two of the BDCs are Backup Browsers (because they are on the same subnet, once you add routers there will be a Master Browser for each subnet, probably a BDC). Every computer with the server component active (that’s right, every computer) announces itself as it boots up (technically, as every service starts) to the Master Browser at 1, 2, 4, 8 and then 12 minute intervals continuing to announce itself every 12 minutes as long as it’s up. (We’re not going to even mention what happens when we have multiple domains on the same subnet). The Backup Browsers get a new copy of the Master "Browse" list every 12 minutes as well. (You can discover which of your machines are serving in what Browser capacity with the Browse Monitor utility in the NT 4.0 Resource Kit). When the user clicks on Network Neighborhood, the client software requests a current list of resources (servers) from the Backup Browser and that is what shows up in the NetHood windows, when the user then double clicks on a particular computer, then a request is sent directly to that computer to return a list of its "shares" and that list is displayed to the user.
Believe it or not, Master and Backup Browsers are chosen through an election process. This "election" is more like playing "King of the Hill" with "Assistant King of the Hill" and "King of the Sub-Hill". It runs something like this: Every time a domain controller boots up a browser election is held, the PDC will always win the Domain Master Browser role and BDC(s) will always win the Backup Browser role (unless they’re on a different subnet in which case they will be the Master Browser on that subnet). These elections are announced by special broadcast election packets and every machine with default server component settings will participate in the election process. These domain controller elections work fairly well because the election packets that are broadcast contain the information that they are NT 4.0 servers and domain controllers which are pre-determined to be "King of the Hill". The real problem with this concept occurs when a normal client, let’s say a WFW machine requests a browse list from the Browser service and doesn’t get an answer, the WFW client then calls an election and sends out a broadcast election packet proclaiming to one and all that "I am the Master Browser unless someone more powerful than I am responds". Since every machine in the network is more powerful than the WFW client, this forces every machine (with the default server component settings) to respond. In many networks, that can be hundreds of machines sending election packets to knock this guy off. After several seconds of the election broadcast "storm" the winners are decided and (surprise!) it’s the NT servers again. But wait there’s a flaw in Win95 which tells it to maintain a browse list even if it loses the election. (Ever get different browse lists in the Win95 NetHood at different times, even though you knew the machines you couldn’t see were up?)
It gets better. Look at the chronology of Microsoft’s product release: ’93 - WFW 3.11; ’94 - NT 3.51; ’95 - Windows 95; ’96 - NT 4.0. During the election WFW announces that it’s WFW, an NT 3.51 server knows about WFW and therefore wins an election against it. When Win95 was released, there were only NT 3.51 servers that were unaware of the existence of Win95, so Win95 tells its election packet that it’s really WFW, that way the NT 3.51 server will win its election. Now we have NT 4.0 which knows about everybody but Win95 is still saying that it’s WFW.
Wait, it still gets better. Everything I’ve just told you about the Browser is protocol-dependent. This means that if you are running two protocols, say TCP/IP and IPX, then you’ve got two browser elections happening and two Master Browsers and two browse lists, etc. But wait, you’ve had Netware, in most Netware environments administrators have bound both the 802.2 and the 802.3 frame types to cover their butts. Now you get three browser elections (one for TCP/IP, one for IPX/802.2, and one for IPX/802.3) and three Master Browsers and three browse lists. Need I go on. The current browser election process is, quite frankly, a mess. More politely, the entire concept of browsing as Microsoft has implemented it, does not scale well in a corporate environment. Microsoft’s own documents tell us that their estimate of Computer Browser traffic is 31% of total Client Initialization traffic, 31% of the total Client-to-Server traffic and a whopping 51% of the total Server-to-Server traffic (that’s more than half!! and remember, by default, EVERY machine is a server). In recognition of this fact, today we have WINS (it helps a little, but also needs tweaking) and tomorrow (NT 5.0) we get Dynamic DNS and no browsing. But while this is welcome relief it does not attack the root of the problem. Why are all these client machines running the server component when they are not really servers?
The Solution:
In a nutshell, the optimum solution is to simply turn off the server component on every machine that is not performing the "server" function. In NT Workstation, Control Panel, Services, Server, Startup, Disabled.
You will also have to disable the Computer Browser service or you will receive error messages on bootup. DO NOT DO THIS ON THE REAL NT SERVERS!!! These are the guys who are supposed to have the server component active and announce themselves to the world, etc.
In Windows 95, go to Control Panel, Network, highlight File and Printer Sharing for Microsoft Networks and click Remove.
In Windows for Workgroups, use Notepad or Sysedit to add the following entry to the SYSTEM.INI:
SYSTEM.INI
[Network]
NoSharingControl=1
This will disable the server components and the user will not be able to turn them back on without editing the SYSTEM.INI.
With all these Server components disabled, these client machines will not 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.
Don’t forget to start eliminating network protocols as soon as you can.
Implications:
The Good:
Reduce total Microsoft network traffic by around 30% to 40%
Increase overall network performance dramatically
Clean up Network Neighborhood display
The Bad:
Can’t really "browse" the network
Administrator must "map" shares via logon scripts, "NET USE" or persistent connections
Administrative shares not available
The Ugly:
May have significant negatives for larger installations using SMS
AN ALTERNATIVE:
There are some situations which do require the server components to remain active (shared printer, shared team or project folders, etc.). In those cases there is still one incredibly beneficial change that you can make to every machine running the server component that you do NOT want to participate in Browser elections and that you do NOT want to be the Master or Backup Browser.
In NT (Workstation or Server), you’ll need to edit the registry. In the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
Browser\Parameters
Change the value of the REG_SZ entry MaintainServerList to No
In Windows 95, go to Control Panel, Network, highlight File and Printer Sharing for Microsoft Networks, click Properties, set the value for Browse Master to Disabled.
In Windows for Workgroups, comment out our previous entry and add the following entry to the SYSTEM.INI:
SYSTEM.INI
[Network]
;NoSharingControl=1
MaintainServerList=No
These entries will prevent each machine from being a Master Browser and from participating in Browser elections while still allowing them to function in the role of "Servers".
====================================================
NETWARE INSET
If you are using WFW, Win95 or NTW on a Novell (3.x or 4.x) network and have installed the Novell Client (Redirector) from Microsoft you will probably still be running Microsoft’s server components. Please disable/remove them as specified. If you have installed the Novell File and Print Sharing from Microsoft on Win95, please remove it. This was designed to allow purely Netware clients to see your Win95 machine as a Netware Server, a truly bad idea. If you are using Novell’s Client32 software (strongly recommended) for any of the client platforms, it prohibits you from installing File and Print sharing for Netware Networks and you should not install File and Print Sharing for Microsoft Networks. In NT Workstation you will still have to disable Microsoft’s Server service and Computer Browser service.
Pick one IPX frame type (802.2 strongly recommended) and bind only that one on all clients and servers. (Netware 3.11 servers are the only ones that require 802.3). This will significantly reduce Browser traffic which is protocol-dependent.