Microsoft Corporation
February 24, 1997
Microsoft® Windows NT® systems automatically generate traffic to perform various tasks, for example synchronizing a back domain controller (BDC) with a primary domain controller (PDC). Also, many types of client actions generate network activity. On networks interconnected via wide area network (WAN) links, this communication can cause significant and unwanted phone charges. Therefore, this article has three purposes:
This article doesn't cover all traffic that occurs in a network. Rather, this article deals with traffic encountered by default installations or most common installations and tries to address those areas of traffic that are most configurable.
It is important to note that this paper does not discuss WAN traffic that would normally be spoofed by routers, for example TCP and NetBIOS keepalives.
Most of this information is extracted directly from the Microsoft Official Curriculum (MOC) course number 689, "Supporting Microsoft Windows NT Server 4.0 Enterprise Technologies."
For a connection between two Windows NT Servers, the following will be explored:
Given the following assumptions:
the approximate percentage breakdown of types of traffic with Windows NT Server to Windows NT Server communication on a network is listed in the following table.
| Activity | Percentage of Traffic |
| Browser | 51% |
| Directory Services | 31% |
| WINS Replication | 8% |
| Trust Relationships | 5% |
| Directory Replication | 4% |
| DNS | 1% |
User logon validation requests are processed by either the PDC or a BDC. Changes to the accounts database are made only at the PDC. To ensure that each BDC properly validates logon requests, it is important that each BDC has an exact copy of the directory services database maintained on the PDC.
User accounts database synchronization occurs on three databases maintained by the system: the security accounts manager (SAM) accounts database, the SAM built-in database, and the local security authority (LSA) database. Synchronization occurs:
This article is concerned with traffic caused by the last instance. The amount of traffic depends on the configuration of the NetLogon service, which is responsible for carrying out synchronization.
By default, the PDC verifies its databases every five minutes, looking for changes to any of the three previously mentioned databases. When a change is detected, the PDC sends a message to all BDCs that need the notification. The PDC maintains a table of each BDC and the version ID of their databases—if a BDC has an up-to-date database, it is not notified of the update. By default, Windows NT Server 4.0 will send the announcement to a maximum of ten BDCs at one time. After each of the ten BDCs complete synchronization, another BDC will be notified. This process continues until all BDCs have been informed.
The domain controller synchronization traffic parameters for the NetLogon service are found in the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters. The following NetLogon service registry parameters can be adjusted:
ReplicationGovernor
Controls the percentage of network bandwidth the Net Logon service can use while performing user accounts synchronization. The default value for this parameter is 100. This means that during a synchronization event, 100 percent of the network bandwidth can be used by the NetLogon service while the primary domain controller is buffering 128K of data at a time. This can be very disastrous in a WAN environment, where users are also competing for bandwidth. By adding this parameter to the NetLogon key, and configuring it to a value of 50, the NetLogon service will only buffer 50 percent as much data (64K) for transmission, and only have synchronization messages on the network 50 percent of the time.
If this is set too low, synchronization will tie up WAN connections longer and take longer to complete. It is generally recommended that ReplicationGovernor never be set lower than 25.
Pulse (in seconds)
Controls how often the primary domain controller looks for changes to its directory services database, and sends synchronization messages to the backup domain controllers that need updating. The value is set by default to five minutes; it can be increased to a maximum of 48 hours. Use caution when setting this value high, as it can result in backup domain controllers that are not synchronized with the primary domain controller for a long period of time. This could cause a full synchronization event to occur.
PulseMaximum (in seconds)
Controls how often the primary domain controller will send a pulse message to each backup domain controller, even if its user accounts database is up-to-date. The value is set by default to two hours; it can be increased to 48 hours, reducing the number of pulse messages.
ChangeLogSize
Controls the size of the change log, which controls the number of changes that can be made to the user accounts database before a full synchronization event occurs. The default value is 64K, which equates to about 2,000 changes (changes average 32 bytes each). In an environment with a large number of users that are frequently changing passwords, it is possible for this limit to be met, causing entries in the file to be overwritten. This may force a full synchronization to occur, generating excess traffic as more information is sent to the backup domain controllers than is really necessary.
PulseConcurrency
Controls the number of BDCs that the PDC simultaneously sends announcements to when a synchronization event occurs. The default number in Windows NT Server 4.0 is 10. Increasing this number will increase the amount of network bandwidth that user accounts database synchronization requires. A lower number spreads the synchronization out over a longer period of time.
ExpectedDialupDelay (in seconds)
This parameter specifies the time it takes for a dialup router to dial when sending a message from this client machine to a domain trusted by this client machine. By default, NetLogon assumes a domain controller connection can be established in 15 seconds. Setting ExpectedDialupDelay informs NetLogon to expect a delay in addition to this 15 seconds.
This parameter should remain zero unless a dialup router exists between this machine and its trusted domain.
If this parameter is set too high, legitimate cases where no domain controller is available in a trusted domain will take an extraordinary amount of time to detect.
Based on the ExpectedDialupDelay, NetLogon adjusts the following two times:
ScavengeInterval (in seconds)
Adjusts the interval at which NetLogon performs the following scavenging operations:
None of these operations is critical. Setting ScavengeInterval for 15 minutes is optimal in all but extreme cases. For instance, if a domain controller is separated from a trusted domain by an expensive line such as an Integrated Services Digital Network (ISDN). this parameter might be adjusted upward to avoid frequent automatic discovery of domain controllers in a trusted domain.
This parameter can be set as high as 2 days.
In an environment where there is centralized administration and individual control of distributed resources, establishing a master accounts domain with multiple resource domains is a good solution. Trust relationships are a necessary component of this solution as they allow user accounts from the accounts domain to have access to resources in the resource domains.
To establish a trust, one domain must permit a second domain to trust it. Then the second domain adds the first domain as a trusted domain. Once this is accomplished, the administrator of a trusting domain can assign permissions for local resources to accounts that reside in the trusted domain.
Whenever a user in the trusted domain attempts to access resources in a trusting domain, the trusting domain passes account authentication on to the trusted domain.
Trust relationships generate network traffic in three ways:
Establishing a relationship. The process of establishing a trust relationship generates about 110 frames and 16,000 bytes of network traffic. This process is only performed one time per trust relationship established.
Trusted accounts. Using trusted accounts also generates a lot of traffic. This traffic occurs whenever the trusting domain's administrator needs to assign permissions to a trusted account for a local resource or add a trusted account to a local group.
Pass-through authentication. This is the most frequent type of trust relationship traffic. There are two different types of pass-through authentication: when a user in a trusted domain attempts to access a resource in a trusting domain and when a user at a Windows NT Workstation computer that is a member of a trusting domain attempts to log on using a trusted account.
Although trust relationships do not produce a high percentage of traffic, there are two ways to reduce trust-related traffic.
Reduce the number of trusts
The obvious means of reducing trust relationship traffic is to reduce the number of trusts. This means giving up the benefits of the master domain/resource domain model. However, it may be worth reviewing existing or planned resource domains to ensure that each one is appropriate and necessary.
Verify that each one-way trust is appropriate. For example, in an environment where two domains trust each other, are both trusts really required? If not, break the non-essential trust.
There is very little maintenance traffic related to trust relationships. Once the trust has been established, most of the traffic is generated by importing and verifying trusted accounts and by pass-through authentication.
Use group accounts
To reduce the traffic associated with the verification of trusted accounts:
By adding a set of users from a global group, as opposed to adding the users individually to a local group or resource, the traffic required to verify the Security ID (SIDs) and associate names with the SIDs can be reduced. In a simple test, the lookup of a single SID for a global group took 552 bytes, whereas the same lookup for SIDs for two trusted user accounts took 636 bytes. While this is not that much extra traffic, it is only for two users. Often, many users from a trusted domain are allowed access to a resource in a trusting domain. By using a global group, the traffic required to look up those accounts can be reduced, which could be substantial over a period of time.
In order to locate network resources effectively, browsing is implemented by default on a Microsoft Windows NT Server network.
The Windows NT domain master browser (DMB) exchanges computer browse lists with BDCs several times per hour. Since Microsoft recommends at least one BDC at each site, a company's domain will often span multiple sites, thereby causing browser network traffic across any intermittent ISDN routers.
Twelve minutes after an Master Browser (MBR) boots and every twelve minutes thereafter, the MBR connects to the DMB that is also the Primary Domain Controller (PDC). This is done by sending a request to the NetBIOS name (domainname<0x1B>) that is owned by the DMB. The MBR then sends the local browse list to, and receives the global browse list from, the DMB. This causes the first connection over the WAN and usually lasts several seconds.
Browsing communication uses Remote Procedure Call (RPC) over a named-pipe connection. After the named-pipe connection is closed, the logical network connection is entertained by the redirector for ten more minutes—when the MBR redirector's KeepConn parameter expires by default. Although this logical connection does not incur ISDN router costs, frames sent to disconnect after the ten minute period cause another ISDN connection to be established, which incurs costs.
Two minutes later—24 minutes after booting—the MBR connects again to the DMB for a browse list exchange. This occurs every 12 minutes.
In addition to the client-to-server browser traffic, there are several additional types of browser traffic generated between servers that account for many frames on the network. The basics of the server browsing process are:
All computers with server components (that is, the ability to share network resources) announce themselves to the master browser in their local domain. Servers that operate in any capacity as a potential browser, backup browser, or master browser become involved in several other communications as well:
Browsing certainly produces a large share of the server-to-server traffic on the network. Optimizing browser traffic may mean reducing the traffic to allow the user more bandwidth, or it may mean increasing the traffic to provide for more up-to-date browse lists to the user when requested.
Most of the traffic generated by browsing is initiated automatically by the appropriate browsing computers. These are the domain master browser, the master browsers, and the backup browsers. There are three general methods to reduce traffic: reduce the network protocols used, reduce the number of browser entries, or increase the amount of time between browser updates.
Reduce network protocols
The browsing process operates separately on each installed and bound protocol. So, if TCP/IP, NWLink IPX/SPX, and NetBEUI are all active on the network, each set of browser traffic, elections, host announcements, workgroup announcements, and so on occur on each protocol independently. This triples the amount of network traffic related to browsing with the only product being a browse list for three independent protocols. Eliminating one or two of these protocols will greatly reduce the traffic generated for browsing.
Reduce browser entries
Disable the server component on computers that do not require sharing of resources. This will reduce the size of the browse lists and, therefore, the traffic passing between browser servers. Each type of client, whether it's Microsoft Windows® for Workgroups, Microsoft Windows 95, or Microsoft Windows NT, has a method for disabling the server service. Every server requires 27 bytes in the browse list, plus additional space for the server comment, if needed. Consider reducing server comments.
Optimization parameters
Browsing parameters are found in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Parameters. The following two parameters can be configured to control the amount of network traffic generated by the browser:
In many large organizations, it is likely that one WINS server will not be sufficient to offer the required level of fault tolerance and performance. Even though a single WINS server can support 10,000 WINS clients, it is recommended to have a backup server. WINS supports the ability of having multiple WINS servers for clients to register and query, while allowing these servers to replicate, or share, their databases with each other. The benefit of this database sharing is that eventually each WINS server will know about all of the other WINS clients that have registered with its WINS partners. This offers faster name resolution for clients.
There are three distinct portions to the WINS replication process:
WINS Record Sizes
The size of each entry in the WINS database will vary, depending on the type of entry being added.
The amount of data stored for a normal (unique) client computer with a single network adapter card is between 40 and 280 bytes, depending on whether the client has configured a scope ID (which can be up to 240 characters). A client without a configured scope ID would require 40 bytes in the database for each name registered.
If the client is multihomed (having multiple network adapters configured for TCP/IP), the amount of data stored will vary depending upon the number of IP addresses configured for the computer. It will range from 40 bytes to 280 bytes per host.
If the name registered is an Internet group name, such as domainname<1C>, the entry can be up to 480 bytes if it contains the maximum number of registered hosts (which is 25).
Knowing an average record size will help in determining how much traffic will be generated during WINS replication events.
WINS database replication is especially a concern in WANs with slow link speeds. When replicating database entries between WINS servers, these entries are accumulated and delivered in the fewest number of frames possible.
WINS replication partners can be configured as either push or pull partners. Push partners send announcements to their configured partners when a specific number of database entries have changed. Pull partners request updates when notified by the push partner and at configured intervals. A relationship in which each partner replicates its database with the other would require each server to be both a pull partner and push partner.
Push partners
Via WINS manager, configure WINS to initiate the push notification after a specific number of record updates have been accumulated. The default value is 20. There is no designated time interval for initiating push notifications and replications. Increasing the number of database updates required before sending a push notification will reduce the frequency of WINS replication and batch more updated records in a single transfer operation.
Often, this value is set to a percentage of the total names in the database. For example, the record update count might be set to 25 percent of records in the database. This allows for more control over the replication.
Pull partners
The pull partner requests changes that have occurred since a specific version number. When using WINS Manager to add a WINS server as a pull partner, you can configure replication to occur at a specific time interval. For example, you might configure WINS to send pull requests every 30 minutes for local WINS servers, every hour for remote WINS servers connected by high-speed links (T1 or higher), and every six hours for remote WINS servers connected by means of slow links (56K). This allows more control over the timing of how frequently data is transferred.
The Directory Replicator service for Windows NT Server allows automatic replication, or duplication, of a directory tree between multiple computers, without the intervention of a network administrator. It is most commonly used for replicating user logon scripts from the primary domain controller of a domain to backup domain controllers, ensuring that no matter which domain controller a user is validated by, the user can run its logon script.
Relative impact on the network
Replication of logon scripts should be fairly simple and infrequent, as they generally are not very large in size, often less than 4K, and don't change frequently. But, if the Directory Replication service needs to replicate other files, logon scripts can be larger in size, and change more frequently, thus requiring more network traffic for replication.
The Directory Replicator service on Windows NT Server provides the ability to automatically duplicate a source tree to multiple other computers. This process can involve a number of frames, depending on the amount of data to be replicated. By default, the export server checks every five minutes for data to be replicated. This frequency interval can be configured in the registry. This process generates very little network activity unless data on the export server has changed.
A sample directory containing 16 files and 426,000 bytes of data took 1,425 frames and approximately 42 seconds to replicate, whereas deleting one file from that same export list took only 251 frames and 48 seconds to verify and update.
Additionally, every five minutes (default configuration) the export server will notify each import computer or domain with a list of its first level directories.
Directory structure
The best way to reduce the amount of traffic generated by the Directory Replicator service is to use a flat, shallow directory structure. Having very large, or deep, and frequently changing top-level replicated directories is very taxing on the Directory Replicator service. The Directory Replicator service checks and then copies an entire top-level directory if any file in that directory has changed. Because some file is likely to change in large directories, the Directory Replicator is constantly rechecking and recopying these directories. It would generate far less traffic if multiple, shallower top-level directories were used in place of a smaller number of deep directory structures. This would put as many of the files as possible in directories where changes are very infrequent.
Using server manager to control replication
It can be beneficial to prevent the Directory Replicator service from exporting specific directories during certain periods of the day. To prevent the export server from replicating directories during heavy network usage times, a lock can be added to the export server. This can be done using Server Manager, or the Server option in Control Panel.
To prevent the export server from replicating directories:
This can be used to help limit the traffic to times when there is less user-generated network traffic.
Also in the Directory Replication dialog box is the Wait Until Stabilized option for each exported directory. When the Wait Until Stabilized option is selected, it causes the import computer to recopy the entire subtree whenever any file in that subtree changes. With this option disabled, the import computer will check the time, date, name, attributes, and size of each file individually and copy only those files which have changed.
Registry parameters
Controlling the amount of data transferred in a replication process often involves updating the registry with new values. Directory replication entries are found in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Replicator\Parameters. The following are the two most common parameters to modify to control the Directory Replicator service:
Interval. This determines how often the originating server (called the export server) checks for updates to its specified directory structure and how often it sends notifications to its target computers (called import computers) to retrieve the new data. The default value for Interval is 5 minutes. This can be increased to 60 minutes or more (on the export server) to reduce the frequency of replication. Of course, this will also increase the replication delay for each individual change.
Pulse. This acts as a counter to control how often an import computer contacts an export server. If an import computer fails to hear from the export server after [Pulse x Interval] minutes, it will contact the export server for an update. The default value of Interval is 5 minutes (as described above), while the default value of Pulse is 2 minutes. With these parameters, if the import computer has not heard from the export server after 10 minutes, it will initiate communications with the export server. Increasing the Pulse parameter will increase the time intervals for the import computer to contact the export server, allowing more time for the export server to contact the import computer.
In larger organizations, a single DNS name server may not be sufficient to provide name resolution services for the clients. In this environment, it may be necessary to implement primary and secondary servers for a zone. A zone is a database file that contains records for a particular domain.
DNS server-to-server traffic is comprised of zone transfers. This traffic does not occur by default, but must be configured by the administrator. A primary name server is the server that maintains the database file for a particular zone. A secondary zone server does not maintain the database, but receives a copy of the database from the primary name server for the zone. This is very similar to the relationship between a PDC and a BDC for a Windows NT domain.
The replication of zone information produces network traffic. When a secondary name server starts up, it contacts its primary name server and initiates replication of the zone. This is called a zone transfer.
DNS server-to-server traffic consists of zone replication. It is possible to control the replication of the zone between the primary and secondary name servers. To do so, select the SOA Record tab from the Zone Properties dialog box in DNS Manager.
The following values can be configured. The most important value is the refresh interval. The smaller it is, the more frequent zone transfers will occur. This provides a more up-to-date zone file at the secondary name server at the expense of increased network traffic.
Refresh Interval. Designates the amount of time the secondary name server will wait before querying the primary name server, to see whether the database file has changed, and initiating a zone transfer. The default value is 60 minutes.
Retry Interval. Designates the amount of time the secondary name server will wait, after a failed zone transfer, before re-attempting the zone transfer. The default value is 10 minutes.
Expire Time. Designates the amount of time that the secondary name server will continue to respond to name queries even though it cannot connect to the primary name server for an update.
Client to server traffic is generated by a client computer communicating with a server computer. Types of client-to-server traffic that this section will analyze include:
Given the following assumptions:
the approximate percentage breakdown of types of traffic using Windows NT Workstation to Windows NT Server communication on a network is listed in the following table.
| Activity | Percentage of Traffic |
| Internet Explorer | 48% |
| Browser | 31% |
| File Session | 12% |
| Logon Validation | 6% |
| DHCP | 1% |
| WINS | 1% |
| DNS | 1% |
After users have successfully logged on to the network, accessing network resources is generally their next step. To assist users in the process of locating network resources, Microsoft networking implements a network service called the Browser. The client browsing process is as follows:
Each of these steps produces network traffic.
Because a lot of the automatic browser traffic is broadcast-based, browsing a subnet is a simple process. However, most routers are not configured to forward browser broadcasts, and as such, browsing servers on remote subnets is not as simple. Fortunately, it is possible to browse network resources throughout the enterprise, and still not forward the browser broadcasts, by implementing WINS.
The process of browsing can have a relatively large impact on the network traffic that a client generates. To some extent, browsing happens automatically. Other aspects of browsing, such as the retrieval of a browse list, is initiated by the user.
The portion of the browsing process that uses Browser frames is based almost entirely on broadcast packets, the majority of which are very similar. Properties include:
To provide for efficient resource location throughout the enterprise, the Computer Browser service is implemented. This network resource browsing comes at the expense of increased network traffic.
Disabling unnecessary server components
One method of reducing client-related browsing traffic is to disable the server component on computers that are not required to provide shared resources on the network. If a computer rarely shares network resources, consider disabling its server component. This will remove the announcements, and reduce the size of the browse list that must be maintained and transferred upon request.
Every server requires 27 bytes in the browse list, plus additional space for the comment, if assigned. Consider limiting or reducing the size of computer comments.
Controlling the number of potential browsers
The number of backup browsers in a network is automatically determined by the browsing software. When another backup browser is needed, a potential browser is notified by the master browser that it should become a backup browser. You can configure a computer to never become a browser server as follows:
This will reduce the registration, renewal and release of the <1E> NetBIOS names with WINS or b-node broadcasts.
Eliminating unnecessary network protocols
The browsing system is protocol dependent, meaning that browsing occurs on a protocol-by-protocol basis. If a network uses three protocols, all browser announcements and elections will be repeated three times, one for each protocol. Reducing the number of protocols, if possible, will have a large impact on reducing browser related network traffic.
When users want to access a computer using standard Windows networking commands and utilities, such as Network Neighborhood, or the net command, the NetBIOS name of the target computer must be resolved into an IP address. This is often accomplished by WINS. When users want to access a computer using TCP/IP utilities, such as Internet Explorer or Ping, the IP host name of the target computer must be resolved into an IP address. This process, called host name resolution, can be accomplished using the DNS.
DNS traffic generated from a client computer consists of a query request and response. As such, there is not a lot of traffic for a single request. The impact that client-based DNS traffic has on the network is a result of how often names need to be resolved. That is, the number of query requests that are issued determines the impact that client DNS queries have on network traffic.
Another factor that impacts the traffic on the network is the need for DNS servers to perform recursive lookups. DNS servers have the ability to pass a query request to another DNS server, or to a WINS server, when it cannot resolve the name. Thus, a single query request from a client computer might actually generate more than the simple query and response frame.
A simple address lookup takes only two directed frames. Optimization efforts should be focused on reducing recursion traffic that may result if a client's DNS server does not have the requested address. There are three methods for reducing recursion traffic:
To configure the TTL for all records of a zone:
This configures the default TTL for all records in the zone. It is also possible to configure the TTL of individual records so that the most commonly accessed records can be cached for a longer time.
To configure the TTL for an individual record:
Now, whenever you create or edit a record, the TTL box is displayed in the Properties dialog box for the record. Configure it as desired on a record-by-record basis.
To configure the TTL for WINS records:
By increasing the TTL of resolved names, the amount of network traffic can be reduced by eliminating the need to recursively query a second attempt for a recently resolved name.
More and more, users are going to Web sites to retrieve static information rather than establishing file connections. One appeal of this process is the graphical interface and the ability to browse information in a quick and easy manner. Another benefit to using Web sites is the ability to share information with users outside the corporate network.
Intranet browsing can generate a very large percentage of the network traffic that is initiated by a client computer. The process of finding and connecting to a Web site creates a very small amount of traffic, but the amount of information that is downloaded, which often includes graphics, can be quite large.
The most effective optimization of intranet browsing traffic is during the creation of Web pages because the majority of Web traffic is caused by the size of the files being copied across the network.
Because intranet browsing can generate very significant amounts of network traffic, anything that can be done to reduce the traffic generated can be beneficial in the overall scheme of network usage.
Keep Web site pages small. As a general rule, it is good HTML design to limit scrolling of pages. Keeping them small will assist in the downloading of a single page, but make sure necessary information is available on other pages that can be loaded.
Limit the size of graphics or .avi files used. Each file must be downloaded to the client computer. The larger the files (especially graphics), the more network traffic generated to download the file. Reuse common graphics throughout the intranet.
Increase the client's local cache. When browsing an intranet, pages are downloaded to the client and placed in a directory called the cache. When the designated amount of disk space for the cache is used and more files are required, the cache must be emptied (deleted). Thus, a previously loaded file must be copied over the network again, instead of loading it from the local hard disk cache.
Consider whether security is a big concern at your site. With security enabled, additional authentication traffic is required for each session that is established. Allowing anonymous connections will prevent the authentication traffic from occurring on the network.