Registry Tweaks to Tune Your Network

Change Registry values to maximize the efficiency of the NT Browser service and your domain controllers' synchronization process.

Richard Adams

April 30, 1999

14 Min Read
ITPro Today logo in a gray background | ITPro Today

Optimize NT Services on TCP/IP Networks

If you maintain a Windows NT network across multiple subnets and WAN links, you can make several Registry changes to enhance your network's efficiency and performance. In this article, I'll look at how you can reduce the amount of traffic that domain controller synchronization and NT's Browser service generate on an NT network.

Domain Controller Synchronization
Whenever you make changes to a SAM database on a PDC, NT must copy those changes to your domain's BDCs so that the BDCs' logon and authentication services are up-to-date. Three databases on each domain controller store SAM information; these databases are in the SAM Registry hive in %systemroot%system32config. (Make sure you include all the files in the config subfolder in your daily backups.) Each database has an update sequence number (USN) that NT uses to determine whether a PDC's database is in sync with a BDC's replica of the database. The PDC keeps track of changes to its SAM databases by listing recent database changes in a buffer in memory called the change log. The PDC retains a list of USNs for each of its BDCs' SAM databases. Periodically, a PDC checks its SAM databases to determine whether the databases have changed since the PDC last synchronized with its BDCs. If the databases haven't changed, the PDC waits for a set interval, then checks its databases for changes again. If the databases have changed, the PDC sends a directed message (i.e., a message that NT delivers to a specific IP address) to every BDC that has different USNs from the PDC's USNs. The directed message informs the BDCs that the PDC's SAM databases have changed, and contains the PDC's USNs. When a BDC receives an update message from a PDC, the BDC compares the USNs in the message with the USNs for its three databases. If one or more of its current USNs are lower than those that the PDC announces, the BDC establishes a secure session with the PDC and downloads changes from the change log.

You can change several Registry entries in your domain controllers' HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesNetlogonParameters Registry key to optimize this synchronization process' efficiency in your environment. The Pulse entry lets you adjust the interval at which a PDC checks its SAM databases for changes. By default, PDCs check their databases and update BDCs every 5 minutes. Change the Pulse entry on the PDC to the number of seconds you want the PDC to wait between database checks. Increasing this length of time can be beneficial if some or all of your BDCs connect to the PDC across a slow WAN link, as long as you don't perform many regular updates to the SAM databases. If you only infrequently make changes in the SAM, increase the Pulse value to reduce network traffic. If you make frequent changes in the SAM, decrease the Pulse value to keep your BDCs up-to-date.

If you change the length of time between a PDC's SAM database checks, you might need to change the size of the PDC's change log. NT usually needs to synchronize domain controllers only partially, so a PDC replicates to its BDCs only the information that has changed since the PDC's last replication. A partial synchronization requires fewer resources than a full synchronization, which replicates the SAM databases in their entirety. However, if the PDC's SAM databases have more changes between synchronizations than the change log can hold, the PDC can no longer track recent changes, and partial synchronization becomes impossible. When a PDC's change log is full, NT replicates the PDC's SAM databases to its BDCs.

The change log is 64KB by default. Approximately 2000 SAM records can fit in a 64KB buffer, because most change entries are 32 bytes long. If you might make more than 2000 changes in the SAM within the interval at which a PDC checks for database changes, increase the size of the PDC's change log to avert a full synchronization. Conversely, if you never make 2000 changes to the SAM database within the interval of a PDC's database checks, you might want to reduce the change log's size to increase system memory available for other uses. To modify the change log's size, create a new Registry value of type REG_DWORD called ChangeLogSize in the PDC's NetlogonParameters key. Set ChangeLogSize to the size in kilobytes that you want the PDC's change log to be.

Every BDC has a memory buffer in which it stores changes to the SAM databases that it receives from the PDC. If the buffer fills up, the BDC receives only part of the new information and has to wait until the PDC's next synchronization to receive the remaining information. If a BDC regularly receives less data than the PDC sends, the BDC can rapidly get far out of sync with the PDC. The BDC will remain out of sync permanently only if the PDC continuously sends too many changes for the BDC's buffer to absorb. Usually, administrators create, edit, and delete accounts, and users change passwords only during the day, so BDCs can catch up with busy PDCs overnight.

You change the size of a BDC's synchronization buffer by changing the BDC's ReplicationGovernor Registry entry. ReplicationGovernor's value is a percentage; the default value is 100. A BDC with a ReplicationGovernor value of 100 percent has a synchronization buffer space of 100 percent of 128KB (i.e., 128KB), and the BDC accepts SAM synchronization traffic that uses 100 percent of the network's bandwidth if necessary. Reducing the ReplicationGovernor value reduces these percentages. For example, a ReplicationGovernor value of 50 gives a BDC a 64KB buffer and lets synchronization traffic use only up to 50 percent of network bandwidth. If you use a WAN link exclusively for replication traffic, you can leave ReplicationGovernor at 100. However, if you also use the link for activities such as videoconferencing, you need to keep some bandwidth available at all times for those other activities, so you need to reduce the value. Don't decrease the ReplicationGovernor value too much, or you run the risk of making your BDCs' SAM databases always out-of-date. Microsoft recommends that you never use a ReplicationGovernor value lower than 25.

If you have a large network, you can use another entry in the NetlogonParameters Registry key to change the speed with which each synchronization reaches your BDCs. To prevent network bottlenecks, the PDC by default sends its directed messages to only 20 BDCs at a time. Only after the PDC updates the SAM databases on all the BDCs in the first synchronization group does it send a directed message to 20 more BDCs. The PDC sends updates to groups of BDCs until it has updated all the domain's BDCs. You can adjust the number of BDCs in each synchronization group by setting your PDC's PulseConcurrency value to the number of BDCs you want the PDC to simultaneously send updates to. Increasing PulseConcurrency ensures that your BDCs receive database updates more quickly. Decreasing the value reduces the likelihood that BDCs' simultaneous update requests will create network bottlenecks.

Another Registry entry related to domain controller synchronization can affect your network's performance. If a PDC detects no changes to its SAM databases after the interval that the Pulse entry defines, the PDC doesn't send a synchronization message to its BDCs. However, if a PDC hasn't sent a SAM database update for another interval, which the PulseMaximum entry defines, the PDC sends a directed message to all the BDCs in its domain to inform them that it's still operating. The default PulseMaximum value is 7200 seconds (i.e., 2 hours). If your PDC communicates with BDCs across a slow WAN link, you might want to increase the PulseMaximum value to prevent the PDC from generating unnecessary network traffic. Many administrators use this optimization for traffic that crosses ISDN routers.

Browser Service Traffic
According to Microsoft, you can expect NT's Browser service to generate approximately 12 percent of your total client-to-server and server-to-server traffic, so optimizing this service is very important, especially if your network includes a slow WAN link. Every computer that runs a Microsoft server component (e.g., NT's Server service, Windows 9x's File and Print Sharing for Microsoft Networks component) announces itself to its domain's or workgroup's master browser via broadcasts. Servers send these broadcasts when they boot and then periodically at an interval that you can set. If the master browser doesn't hear from a server for three consecutive announcement periods, it assumes that the server is offline and removes the server from its server list.

Broadcast traffic doesn't traverse routers, so if you have multiple subnets on your network, each subnet has a master browser. Each subnet's master browser is responsible for compiling a server list for its subnet and passing the list to the domain master browser. (Each domain has only one domain master browser, regardless of how many subnets it contains.) After the domain master browser receives server lists, the domain master browser compiles a master server list for the domain and passes this list back to each subnet's master browser. The traffic between the master browsers and the domain master browser consists of directed messages. Master browsers and domain master browsers use WINS or LMHOSTS files to discover one another's IP addresses.

Server traffic. By default, servers broadcast their online status to their subnet every 12 minutes. This frequency lets each subnet's master browser maintain a definitive list of all the servers in its subnet. However, this frequency also makes for a lot of broadcast traffic. If you have a reliable network, you can increase the broadcast interval to reduce servers' broadcast frequency. The entry to change on an NT server is Announce. On each NT machine that's running a server component, add a REG_DWORD entry named Announce to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesLanmanServerParameters Registry key. Set Announce to the length of time in seconds that you want to pass between the computer's status broadcasts. I recommend increasing the announcement time to 3600 seconds (i.e., 1 hour) in most environments in which servers are online 24 * 7. An Announce value of 3600 causes problems only on particularly unreliable networks or in environments in which servers are coming online or going offline regularly.

The most obvious other Browser service optimization is removing or disabling server components on computers that don't need the components. This approach reduces the number of servers that send Browser broadcasts; makes your server list more readable for users browsing the network; and makes the server list a smaller file, thus reducing network traffic every time a machine browses the network. Of course, you can't remotely connect to computers that aren't running a server component, so you might not want to perform this optimization even on users' NT workstations if you want to be able to remotely administer those machines.

Master browser traffic. Subnets' master browsers pass their server lists to the domain master browser every 15 minutes by default, and the domain master browser passes its master server list to the subnets' master browsers every 15 minutes. If some of your master browsers connect to the domain master browser via a slow WAN link, you might want to adjust how often those master browsers contact the domain master browser. To make this adjustment, create a REG_DWORD entry called MasterPeriodicity in the HKEY_LOCAL_MACHINE SYSTEMCurrentControlSet ServicesBrowserParameters key on the master browser, and set its value to the number of seconds you want the master browser to wait before contacting the domain master browser. Setting MasterPeriodicity to more than 900 seconds will reduce your WAN traffic but will make your server list less current.

Domain master browser traffic. In addition to compiling a definitive list of all the servers in its domain, a domain master browser is responsible for discovering the names of other domains and workgroups on the network and announcing its domain to other domain master browsers. The domain master browser downloads a list of domains and workgroups called the domain list from its WINS server. The domain master browser sends directed DomainAnnounce messages to the domain master browser of each of the domains and workgroups on the domain list. The master browser uses the DomainAnnounce messages it receives from other domain master browsers to add the names of the network's other domains and workgroups to the master server list, which it passes to its subnets' master browsers. A domain master browser's default domain announcement period is 12 minutes. To change this period, you create and adjust the MasterPeriodicity value on a domain master browser. If you are in the habit of leaving your domain master browser running (this habit is usually a good idea), you can increase your domain master browsers' MasterPeriodicity value to reduce interdomain traffic.

An important optimization is selecting which computers participate in providing the network's browsing service. A process known as election chooses both the domain master browser and master browsers. A domain's PDC automatically assumes the role of domain master browser and master browser for its subnet. By default, if the PDC is offline, NT chooses a master browser based on each computer's OS. A similar process takes place on each subnet to select the master browser. You can rig these elections by setting the IsDomainMaster value in a computer's HKEY_LOCAL_MACHINE SYSTEMCurrentControlSet ServicesBrowserParameters Registry key to YES. If a computer's IsDomainMaster value is YES, that computer becomes the master browser for its subnet. Choosing each subnet's master browser rather than leaving master browser selection to the election process is often a good idea, because the Browser service consumes processing and networking resources on master browsers.

Backup browser traffic. Backup browser traffic is the final part of the Browser service's network traffic. When a client needs to browse the network, it contacts a backup browser on its network segment. Each master browser acts as a backup browser, and master browsers appoint as many as three backup browsers—one for every 32 clients—to provide the server list to clients. After a master browser receives the master server list from its domain master browser, it passes the list to the other backup browsers on its subnet.

Backup browsers periodically contact their master browser to obtain a new server list. By default, each backup browser sends this update message every 15 minutes. If your server list is fairly stable—in other words, if you leave your servers on—you might want to increase this interval by creating a BackupPeriodicity entry (of type REG_DWORD) in the HKEY_LOCAL_MACHINESYSTEM CurrentControlSet ServicesBrowserParameters key on your backup browsers and specifying an interval in seconds.

Just as you can select a network's master browsers, you can choose which servers a master browser makes its backup browsers. Rather than leaving the master browser to its own devices, you can set the MaintainServerList value (of type REG_DWORD) under the BrowserParameters key to YES to make a computer a backup browser. You can set MaintainServerList to NO to ensure that the machine doesn't become a backup browser. The default setting, AUTO, lets the master browser appoint the computer as a backup browser if necessary. Don't make too many computers backup browsers, or you'll create unnecessary synchronization traffic from the master browser.

Unfortunately, you can't control the network traffic between client machines and backup browsers. The first time a client browses, it obtains a list of backup browsers from the master browser of its subnet. The client randomly selects a backup browser from the master browser's list, connects to the backup browser, and requests a copy of the server list. From that moment on, the client goes to that backup browser and downloads the server list whenever the user browses the network. No Registry tweaks can change the frequency of this traffic between clients and backup browsers, because this traffic occurs in realtime whenever the user attempts to browse the network.

Benefit from Reduced Network Traffic
After you make these Registry changes, the background traffic that is essential to every NT network will consume fewer processing and network resources than before. However, don't make these changes without proper planning; make Registry changes only very carefully. In addition, keep in mind that none of the changes I've described take effect until you reboot the system, so you might want to schedule your optimization tasks for a time that minimizes the effect on your network of taking each server offline temporarily. For more detailed information about these Registry changes, see the Microsoft Windows NT Server 4.0 Resource Kit's Windows NT Server Networking Guide and Registry entry documentation or invest in one of the many books about the NT Registry.

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like