When people are chatty, it can be annoying, but it isn’t really harmful. It’s a different story with Windows NT, though. In this article, I’ll explain why being chatty is a bad thing for your network. I’ll then go on to show you how you can greatly reduce Windows NT’s chattiness, thereby increasing overall network performance.

Author’s Note

Before I get started, I’d like to point out that everything that I’m going to show you from this point forward involves modifying the registry. Making incorrect modifications to the registry can destroy Windows and/or your applications. I therefore strongly recommend that you make a full system backup prior to attempting any of the techniques that I’m about to show you.

The other precaution that you must take is to ensure that you are applying these changes to the correct version of Windows NT. This article focuses primarily on Windows NT 4.0. However, these methods will also work on Windows NT 3.51, so long as the system is running Service Pack 5 or above.

 

What’s wrong with a little chatter?
If you haven’t done much in-depth work with Windows NT networking, you’re probably wondering why there’s so much fuss about chattiness. In addition to all of the normal traffic that flows between clients and servers, Windows NT produces extra traffic. This extra traffic is responsible for domain controller replication, master browser elections and things like that. In essence, the chattiness is caused by operating system overhead.

At first, this chattiness might not seem like much of a big deal. After all, the operating system has to get its job done. However, excessive network chatter can cause problems. Chatter consumes bandwidth that would normally be used for other types of network traffic. On a local area network (LAN), this means slower response times for clients, since client computers must wait for the line to be free before transmitting packets. In the case of a wide area network (WAN), inefficiency is just the beginning. Excessive chatter can be costly since some carriers determine the total price of a WAN link based on the amount of traffic that flows across it.

You can never completely eliminate the chattiness because it’s required as a basic part of the operating system’s functionality. You can, however, modify the registry in a manner that greatly reduces it.

Reducing the exchange of browse lists
When I hear people talking about how chatty Windows NT is, the conversation inevitably leads to the browser service. By default, the master browsers contact the primary domain controller (PDC) every 12 minutes in an effort to exchange browse lists. However, you can eliminate a considerable amount of traffic from your network by increasing the amount of time that the master browsers wait prior to contacting the PDC.

You can control this time delay by modifying the registry on each master browser, or backup domain controller (BDC), within the domain. To do so, open the Registry Editor and navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Browser\Parameters. Once you arrive at this location, locate a registry key called MasterPeriodicity. This registry key is a REG_DWORD that contains an integer value. The value directly corresponds to the number of seconds that the BDC waits before contacting the PDC to exchange browse lists. The default value is 720 seconds (12 minutes). The value that you change this registry key to is up to you, but I recommend keeping the value below 900 (15 minutes).

SAM replication between a PDC and its BDCs
One of the bigger sources of traffic related to operating system overhead is related to SAM synchronization. As you’re probably aware, in a Windows NT environment, the SAM database contains all of the information related to user accounts and computer accounts. Although every domain controller has a copy of the SAM, SAM changes are only applied to the PDC. The PDC must then replicate these changes to the BDCs.

There are a couple of different ways that this synchronization can occur. The PDC has what’s known as a pulse time. By default, the pulse time is set to 300 seconds. Any changes to the SAM that occur in between pulses are collected and stored until the next pulse occurs. At the end of a pulse cycle, a pulse is sent to each BDC that’s in need of an update. If the PDC knows that a BDC is current, then no pulse is sent to that BDC. The pulse that’s sent to the BDCs contains all of the updates to the SAM that have been applied within the most recent pulse cycle.

Obviously, each pulse places traffic on the network. The amount of traffic varies, but it can be considerable if there are a lot of BDCs to update and/or a lot of changes have been made to the SAM. You can reduce the total amount of pulse-related traffic flowing across your network by increasing the pulse cycle.

To increase the pulse cycle, open the Registry Editor and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters. Once you’ve arrived at this location, locate the Pulse value. The Pulse value is a REG-DWORD whose value is an integer ranging from 60 to 172800. The numerical value represents the number of seconds between pulses. The default is 300.

Before you go and change the pulse value to 172800, there are some things that you must keep in mind. The longer the pulse value is set for, the longer it takes to update the BDCs. Therefore, suppose that you created a new user account. Until the account is propagated to the BDCs, the user’s ability to log on depends on whether the PDC attempts to authenticate the logon request or if the request is handled by a BDC.

If the request were handled by a BDC, and the pulse frequency were set to the default value, then the user could log on five minutes (300 seconds) after the account was created. If, however, you changed the pulse frequency to 172800, then it would be 48 hours before the user could log on. Keep in mind that this idea applies to password changes as well. The amount of time that a password change takes to occur is directly controlled by the pulse frequency. The point is that you must find a healthy balance between the amount of pulse traffic that you place on the network, and the time delay between pulses. If you are updating BDCs across an ISDN link or other medium that charges you by the packet or by the frame, then Microsoft recommends setting the pulse frequency to at least 3600 (1 hour).

If you decide to change the pulse frequency, then there’s another registry entry that you must look at and possibly change. The registry key is PulseMaximum. Like the Pulse key, this key is also located under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters key.

Like the pulse registry key, the PulseMaximum key is set to a value ranging between 60 and 172800. The idea is that a pulse is occasionally sent to all BDCs whether they need to be updated or not. This pulse simply ensures that the BDCs are alive and have accurate SAMs. The PulseMaximum key controls how often this mandatory pulse occurs.

So far I’ve talked about pulses as they relate to user account updates within the SAM. However, if you’re using a protocol analyzer such as Network Monitor to monitor pulse traffic, you may occasionally see unscheduled pulses occur. This is because SAM changes related to local security authority (LSA) secrets trigger immediate pulses. LSA secrets have to do with things like adding a workstation to the domain or modifying a trust relationship.

Closing SMB connections
SMB connections are designed to close after being dormant for a specific amount of time (10 minutes by default). Tinkering with SMB connection timeouts can reduce your network traffic, but not in the way that you might think.

As with some of the other concepts that I’ve been discussing, tinkering with the SMB connection timeout values is a trade off. Low connection timeout values cause connections to close very quickly. However, closing a connection quickly may cause a significant amount of SMB overhead because each time you close a connection, a new connection is established automatically

If you are using an ISDN connection or some other pay-by-the-frame or -packet medium, then Microsoft recommends changing the SMB timeout time from 600 seconds (10 minutes) to ten seconds. If you aren’t using an ISDN or similar connection, then you’re probably better off leaving this setting alone because lowering the value tends to increase the amount of SMB overhead.

You can modify the SMB connection timeout value by opening the Registry Editor and navigating to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\parameters. The specific key that you’re looking for in this location is the KeepConn key. This key is a REG_DWORD and contains an integer ranging from 1 to 65535. This number indicates the number of seconds that a connection will remain idle before timing out. For this change to work, you must modify this registry key on all Windows NT servers and workstations.

Domain controller location techniques
In a Windows NT environment, any domain controller can authenticate a user into the domain. The problem with this is that Windows NT doesn’t care where the domain controller is located. For example, you probably wouldn’t want users to be authenticated by a domain controller that exists in a different subnet, because doing so causes excessive network traffic. Fortunately, there is a registry setting that you can use to ensure that Windows NT looks for a local domain controller before workstations are allowed to look for non-local domain controllers.

You can find this setting at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBt\Parameters. This registry key is a REG_DWORD that accepts an integer value. I recommend setting the value to 4 on all servers and workstations. The number 4 corresponds to M-Node. M-Node is a broadcast mode that ensures that local domain controllers and name servers will attempt to be contacted before sending the workstation to a foreign subnet.

WINS-related traffic
If you’re still using WINS on your network, I recommend making the transition to DNS. If moving to DNS isn’t in your future plans though, you can adjust the amount of traffic that WINS causes on your network. Adjusting WINS is a little different than playing with some of the other settings that I’ve shown you. There is no one registry key that directly controls how much WINS-related traffic flows across the network. Instead, there are four values that either directly or indirectly influence the amount of traffic.

The WINS value that has the biggest influence on the traffic is the Renewal Interval. This value specifies how often a client must reregister its name into the WINS database. The Renewal Interval can be adjusted at HKEY_LOCALMACHINE\SYSTEM\CurrentControlSet\Services\WINS\Parameters. The key name is RefreshInterval. This REG_DWORD uses a hex value to specify how often a client must register its name. The default value is 0x54600, which translates into 96 hours. You can configure the renewal interval to last between 40 minutes and 96 hours. If you have some trouble with the hex conversions, then you’ll be happy to know that you can adjust this value directly through the WINS Manager without ever having to touch the Registry Editor.

A similar control is the Verify Interval. The Verify Interval controls how long WINS will wait before verifying that names that it doesn’t own are still active. You can find the verify interval at HKEY_LOCALMACHINE\SYSTEM\CurrentControlSet\Services\WINS\Parameters under the key name VerifyInterval. This key is a REG_DWORD, which uses a hex value to calculate the amount of time between verify operations. The default value is 576 hours (24 days) or triple the extinction interval, which I’ll discuss in a second, which ever is larger. For this registry key, 576 hours is the minimum value that you can use, but the maximum can be up to 9999 hours 59 minutes 59 seconds.

The extinction interval really doesn’t have much to do with network traffic. It controls the amount of time after an entry has been marked as released before that entry is considered to be extinct (or tombstoned). I am showing you this particular registry entry because the extinction interval must be adjusted in such a way that it is always larger than the renewal interval.

You can find this key at HKEY_LOCALMACHINE\SYSTEM\CurrentControlSet\Services\WINS\Parameters. The name of the key is TombStoneInterval. This key is a REG_DWORD and uses a hex value to represent the time-out time. The default value is 0x54600, which translates into 96 hours. The value can range between 40 minutes and 96 hours but must be larger than the removal interval value.

Trust relationships
Under certain circumstances, trust relationships can cause unnecessary traffic to be placed on the network. When a trust relationship is initially created, the trusting domain polls the trusted domain once every fifteen minutes in an attempt to locate a secure channel by which the two domains can communicate with each other. Once this secure channel is established, the polling stops and no more traffic flows between the two domains as a result of the trust relationship.

The exception to this is when a user from the trusted domain tries to access resources in the trusting domain. On such an occasion, the secured channel is used in an attempt to verify the user’s credentials. If the secured channel fails to function, then Windows assumes that there is a problem with the medium linking the two domains, and continuously retries the connection by polling for the remote domain controller once every fifteen minutes. This polling goes on indefinitely until the remote domain is contacted.

There is a way to reduce the polling frequency so that polling related traffic is placed onto your network less frequently. I was a little hesitant about including this technique as a way of reducing network traffic, because if polling between domains occurs, you’ve obviously got a bigger problem than simply needing to reduce some operating system overhead-related network traffic. In the end however, I decided to go ahead and show you the technique and allow you to make up your own mind as to whether to use it.

To change the polling frequency, open the Registry Editor and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters. The key that you must then locate is called ScavageInterval. This key is a REG_DWORD and contains an integer value that reflects the number of seconds between polling. The default value is 900 seconds (15 minutes). You can set this value lower to poll more frequently or higher to poll less frequently.

You talk too much
Although Windows NT does tend to be chatty, there are some steps that you can take to reduce the chatter. By doing so, you can reduce traffic and possibly even reduce the cost of your WAN links. This reduction in traffic can also help speed your overall network in general, reducing the amount of overhead and decreasing response times.