Tuning Windows NT Server in Branch Offices at GlobalNet Insurance

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By Matthew Storer, MCS—Great Lakes

Editor's Note This article is excerpted from "Optimizing Network Traffic," which is part of the Microsoft Press Notes From the Field series that outlines the best system management practices and procedures. For more information on this and other Microsoft Press books, go to https://www.microsoft.com/mspress/.

Today, organizations with branch offices connected by a wide area network (WAN) need an inexpensive distributed computing solution to stay competitive. Although Microsoft Windows NT provides branch offices with low-cost file and print services, Internet and intranet connectivity, and electronic messaging, you may still find that supporting WAN functionality increases your costs.

This chapter shows you how to reduce WAN costs associated with Windows NT networking traffic, reviewing ways to optimize the NetLogon service, Network Basic Input/Output System (NetBIOS) name resolution and browsing, printer browsing, server message block (SMB) connections, and the licensing service.

On This Page

In Focus
NetLogon Service Optimization
NetBIOS Name Resolution
NetBIOS Browsing
Printer
Server Message Block (SMB)
License Management
Sample AutoRepl Code
More Information

In Focus

Enterprise

GlobalNet Insurance has branch offices in North America and Europe.

Network

4500 backup domain controllers (BDCs) connected across the WAN using Remote Access Services (RAS).

Challenge

Configuring Windows NT Server for optimal intranet communications in branch offices, reducing the WAN traffic, improving overall WAN throughput, and reducing on-demand line costs such as ISDN and analog.

Solution

To reduce startup costs and the time to deliver a distributed solution based on Windows NT Server, GlobalNet used Windows NT RAS and dial-on-demand routers, connecting branch offices and remote users to the corporate network.

What You'll Find In This Chapter

• Descriptions of registry settings and their parameters.

• Techniques to optimize Windows NT services over the WAN, as implemented by GlobalNet Insurance.

Warning: This chapter makes recommendations for tuning the Windows NT registry using the Registry Editor. Using the Registry Editor incorrectly can cause serious, system-wide problems that require you to reinstall Windows NT. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.

NetLogon Service Optimization

The NetLogon service automatically synchronizes changes in the Windows NT directory database stored on the primary domain controller (PDC) to all backup domain controllers (BDCs). Based on settings in the registry, the PDC sends timed notices that signal the BDCs to request changes at the same time. When a BDC requests changes, it informs the PDC of the last change it received so that the PDC can determine whether a BDC needs updating. If a BDC is up to date, its NetLogon service does not request changes.

Windows NT Domain Directory Synchronization

The NetLogon service synchronizes three domain directory databases: the security accounts manager (SAM) accounts database, the SAM built-in database, and the Local Security Authority (LSA) license database.

Definition of domain directory databases.

Database	What information it contains
SAM accounts	Microsoft domain user and group accounts that you create. Includes all computer accounts added to the domain, such as domain controllers (DCs) and Windows NT computers.
SAM built-in	Local machine built-in user and group accounts, such as Administrator, Domain Admins, and so forth.
LSA	LSA Secrets that are used for trust relationships and DC computer account passwords. Also includes the account policy settings that you configure.

Synchronization occurs:

• When a backup domain controller is initialized or restarted in the domain.

• When "forced" by a network administrator using Server Manager.

• Automatically by the DCs, depending upon Windows NT registry configuration.

Change Log

The change log records changes to the domain-directory databases, including new or modified passwords, user and group and accounts, and group membership and user rights. Its size determines how many changes the log can hold, and for how long. Typically the change log holds about 2,000 changes, keeping only the most recent changes, deleting the oldest ones first. When a BDC requests changes, it receives only changes that occurred since the last synchronization.

The NetLogon service checks for updates every five minutes (default). If a BDC does not request changes in a timely way, the entire domain directory must be copied to that BDC. For example, if a BDC is offline for a time (such as for system repair), more changes could occur during that timeframe than can be stored in the change log.

Partial and Full Synchronization

Partial synchronization consists of the automatic, timed replication of directory database changes to all BDCs since the last synchronization. Full synchronization copies the entire directory database to a BDC; it takes place automatically when changes have been deleted from the change log before replication, or when you add a new BDC to a domain.

Both the NetLogon Service updates and the change log size ensure that full synchronization does not start up under most operating conditions. In the WAN environment, you can control and refine NetLogon activity, using the Windows NT registry entries and methods described below.

One way to reduce the number of full synchronizations is to build BDCs at the corporate network site so that the full directory database can be quickly transferred from a PDC to BDCs. You can then send the new BDC to the branch office and put it into service as soon as possible (within 3-6 days of dispatch). When the new BDC starts up, it contacts the PDC to obtain any directory database changes that occurred while the BDC was offline.

Modifications to Registry Settings

This section describes changes to registry settings that you can make on the BDC that the network promotes in case the PDC becomes unavailable. (These settings are for the PDC and the BDCs targeted for promotion.) The Windows NT registry settings discussed are located in the subkey:

HKEY_LOCAL_MACHINE \Services \NetLogon \Parameters.

You must restart the domain controller for these changes to take effect.

Warning: Using Registry Editor incorrectly can cause serious, system-wide problems that require you to reinstall Windows NT. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.

ChangeLogSize

ChangeLogSize defines the log size (in bytes). Because the change log exists both in memory and on disk (%SystemRoot%\NETLOGON.CHG), increasing its size consumes more disk space and virtual memory, but causes no other problems. Entries into the log represent changes to the SAM and LSA databases, which are maintained with a circular buffer.

In a large organization with many users who frequently change passwords, the change log can quickly reach its limit (default is 64 KB, about 2000 changes, averaging 32 bytes per change), causing new entries to overwrite changes not yet synchronized. This can force a full synchronization to start up, generating excess traffic because more information is copied to BDCs than is necessary.

ChangeLogSize registry parameters.

PDC change	BDC change	Default	Minimum	Maximum
X		65536	65536	4194304

Recommendation:

Set the ChangeLogSize to greater than 65536. For example, setting the ChangeLogSize to 4,194,304 bytes (4 megabytes) supports approximately 131,072 change log entries, and does not degrade DC system performance.

• Increase ChangeLogSize if full synchronization becomes prohibitively expensive.

• Increase ChangeLogSize if you expect that one or more BDCs will not requested a partial synchronization within 2,000 changes.

Pulse

Pulse controls how often a PDC looks for changes to its directory services database and sends synchronization messages to BDCs that need updating. The default value equals five minutes (stored in seconds), which you can increase to a maximum of 17200 (48 hours).

The NetLogon service collects all SAM and LSA changes made within the Pulse period, and sends pulses only to BDCs needing the changes. When the NetLogon service starts up, the PDC sends a pulse to every BDC with a machine account. The PDC also forces a pulse once each period according to the PulseMaximum frequency (default 7200 seconds—see the "PulseMaximum" section below), regardless of any other information the PDC has collected about the status of the BDC.

Pulse registry parameters.

PDC change	BDC change	Default	Minimum	Maximum
X		300	60

Recommendation:

Increase this parameter above 300 to ensure that PDCs do not constantly attempt to contact every BDC. In a branch office environment, such as GlobalNet, you can set the Pulse to its maximum value of 172800 (48 hours).

Issues to consider:

• Increasing the pulse parameter raises the risk of a BDC's machine account password expiring. To resolve this, you can disable the machine account password parameter. See the "DisablePasswordChange" section for more information.

• Setting the value high can result in BDCs that do not synchronize with the PDC for a long period of time, causing a full synchronization to start up or a "gap" in receiving timely security updates.

PulseConcurrency

PulseConcurrency defines the maximum number of simultaneous pulses a PDC sends to BDCs. When the NetLogon service sends pulses to BDCs, each BDC responds asking for any database changes. NetLogon controls the maximum load these responses can place on the PDC by having only the defined number of PulseConcurrency pulses "pending" at one time. You must ensure that PDCs have sufficient power to support concurrent replication remote procedure calls (RPCs) to all BDCs.

PulseConcurrency parameters.

PDC change	BDC change	Default	Minimum	Maximum
X		10	1	500

Recommendation:

Set this parameter to match the maximum number of DCs that can request synchronization at any given time (defined with the directory synchronization tool).

Issues to consider:

• Increasing PulseConcurrency increases the load on the PDC.

• Decreasing PulseConcurrency increases the time it takes for a domain with a large number of BDCs to get SAM and LSA changes to all of the BDCs.

PulseMaximum

PulseMaximum specifies how often a PDC sends a pulse message to BDCs, even if its user accounts database is up-to-date. You can increase the default value of 7200 seconds (two hours) to 86400 (24 hours), reducing the number of pulse messages.

PulseMaximum parameters.

PDC change	BDC change	Default	Minimum	Maximum
X		7200	60	86400

Recommendation:

If your environment has multiple DCs for each domain (as does GlobalNet) increase this parameter to its maximum to ensure the PDC is not constantly contacting every BDC.

Issue to consider:

• Increasing this parameter raises the risk that a BDC's machine account password can expire. To resolve this, you can disable the machine account password parameter. See the "DisablePasswordChange" section for more information.

PulseTimeout1

PulseTimeout1 controls how long a PDC waits for a BDC (default 10 seconds). to respond to the PDC's pulse before it considers them non-responsive. A pulse sent to a non-responsive BDC does not count against the PulseConcurrency limit, allowing the PDC to send a pulse to other BDCs in the domain.

PulseTimeout1 parameters.

PDC change	BDC change	Default	Minimum	Maximum
X		10	1	120

Recommendation:

In a slow-link WAN, increase this parameter to reduce the chance of a PDC evaluating BDCs as non-responsive.

Issues to consider:

• If this number is too large, a domain with a large number of non-responsive BDCs takes a long time to complete synchronization (a partial replication).

• If this number is too small, a PDC falsely evaluates a slow BDC as being non-responsive, so when the BDC finally responds, it starts a partial replication from the PDC, unduly increasing the load on the PDC.

PulseTimeout2

PulseTimeout2 defines how long a PDC waits for a BDC to complete partial replication. After a BDC initially responds to a pulse, it must continue making replication progress, or the PDC evaluates the BDC as non-responsive. Each time the BDC calls the PDC, the BDC receives another PulseTimeout2 pulse, marking a period (default 300 seconds) in which the BDC must respond.

PulseTimeout2 parameters.

PDC change	BDC change	Default	Minimum	Maximum
X		300	60	3600

Recommendation:

Set this parameter to slightly more than the average number of seconds needed to complete a partial directory synchronization to ensure the BDCs retrieve all changes to the SAM and LSA databases. Tuning this setting becomes increasingly important when a single RPC cannot retrieve all changes due to an increased ChangeLogSize.

Issues to consider:

• If this number is too large, a slow BDC (or one that has its replication rate artificially governed) consumes one of the PulseConcurrency slots.

• If this number is too small, the load on the PDC unduly increases because of the large number of BDCs doing a partial synchronization.

ReplicationGovernor

ReplicationGovernor defines the size of the data transferred on calls to the PDC and the frequency of those calls. For example, setting it to 50 percent allocates a 64-KB buffer rather than a 128-KB buffer, and allows BDCs to have outstanding replication calls at only 50 percent of the possible rate. Do not set the ReplicationGovernor too low, or replication may never complete.

You can set different replication rates at different times throughout the day by adjusting the ReplicationGovernor parameter to restart the NetLogon service from within an AT script. However, setting the parameter below 100 percent requires configuring it on each BDC.

ReplicationGovernor parameters.

PDC change	BDC change	Default
	X	100

Recommendation:

Leave this parameter at 100 percent so domain synchronization finishes as quickly as possible and completely replicates SAM and LSA changes. Monitor situations where domain synchronization must work in concert with other WAN application activity and decrease ReplicationGovernor as needed.

DisablePasswordChange

DisablePasswordChange allows a Windows NT computer to maintain its domain membership while being offline for more than six days. A Windows NT workstation is a member of a domain, and it accesses domain resources by using a machine account password. It changes the password automatically every three days, and to do this it must register the new password with the PDC.

If the Windows NT workstation cannot access the PDC, it caches the new password for three more days and continues attempting to register it with the PDC. Eventually, the password on the workstation expires and when the DC tries to authenticate the machine account, the password does not match the one in the security database.

By default, Windows NT does not disable the machine account password. You can disable this security layer that Windows NT uses to protect against computer accounts impersonation through DisablePasswordChange.

DisablePasswordChange parameters.

PDC change	BDC change	Windows NT Workstation	Default
0x01	0x01	0x01

Recommendation:

Do not compromise Windows NT security. Disable machine account password changes only when necessary. Review Windows NT domain design alternatives.

ExpectedDialupDelay

If a dial-up router can take longer (30 to 90 seconds) to make a connection to a remote network than NetLogon can wait by default, NetLogon assumes that no DC is available on the network. NetLogon sends out three broadcast/multicast <1C> frames looking for the DC at 5-second intervals (default). The dial-up router has approximately 15 seconds to make the connection and pass the frame before NetLogon times out and uses cached credentials to validate the user. ExpectedDialupDelay provides a mechanism to modify the broadcast intervals.

ExpectedDialupDelay parameters.

PDC change	BDC change	Windows NT Workstation	Default
	X	X

Recommendation:

Use the following formula to set wait time:

5 seconds + (ExpectedDialupDelay / 3).

Therefore, if you set the ExpectedDialupDelay to 120 seconds, the wait time would be:

5 + (120 / 3) = 45,

that is, a 45-second interval between frames.

Note: For Windows NT 3.51, this modification requires Service Pack 5 (SP5) or later.

Directory Synchronization Tool

The final and most important step of the optimization process is to ensure that BDCs properly request only Windows NT domain directory changes, not a full copy of the SAM database. By default, the BDC replicates directory changes when it is notified by the PDC and when it first boots. In an on-demand WAN environment, configure the PDC's directory synchronization pulses to go out infrequently or not at all.

You can control the directory synchronization pulses by installing NLTEST (a Windows NT 4.0 Resource Kit NetLogon Service tool) that requests the Windows NT directory changes, when appropriate.

Note: Windows NT 3.51 does not have this tool, but if NLTEST is run under Windows NT 4.0, it can request a remote Windows NT 3.51 partial directory synchronization.

NLTEST and Windows NT 3.51

To control the Windows NT domain synchronization process, NLTEST emulates the Windows NT synchronization state from the BDC. Assuming a network connection exists between the PDC and the BDC, the following process takes place:

State 1: Notify NetLogon on the PDC that a new transport has come online.

State 2: Notify NetLogon on the PDC that you wish to replicate.

State 3: Query NetLogon on the PDC to determine if you are still replicating.

A sample of necessary MicrosoftVisual C++ code to perform these NetLogon requests is provided in the "Sample AutoRepl Code" section at the end of this chapter.

NLTEST and Windows NT 4.0

You can create the following command file to call NLTEST. It requires a RAS connection using RASDIAL (also included in the Microsoft Windows NT Server 4.0 Resource Kit) to make the connection, and NLTEST to request SAM and LAS updates.

:RASDIALOUT
 RASDIAL PDCSERVER
 IF ERRORLEVEL == 1 GOTO BADRASDIAL
 NLTEST /TRANSPORT_NOTIFY
 NLTEST /SERVER:BDCLOCAL /REPL
 GOTO END
 :BADRASDIAL
 WAIT 5
 GOTO RASDIALOUT
 :END

Note: You can force a full synchronization of the SAM, LSA, and BUILT-IN security databases by using the command line net accounts /sync. This requires more bandwidth and execution time because the security databases grow in raw size. You can use NLTEST.EXE to force a full synchronization with this command: nltest /sync /server:<BDC_name> . See Knowledge Base article 158148, Title: Domain Secure Channel Utility - NLTEST.EXE for more information.

NetBIOS Name Resolution

NetBIOS defines a software interface and a naming convention, not a protocol. The NetBIOS Enhanced User Interface (NetBEUI) protocol, introduced by IBM in 1985, provides a protocol for NetBIOS applications. However, NetBEUI is a small protocol with no networking layer and because of this it is not a routable protocol suitable for medium to large intranetworks. NetBIOS over TCP/IP (NetBT) provides the NetBIOS programming interface over TCP/IP, extending the reach of NetBIOS client-server programs on the WAN, and allowing interoperability with various other operating systems. NetBT and NetBIOS are illustrated in Figure 4.1.

Figure 4.1: Logical relationship of NetBIOS to TCP/IP.

The Windows NT Workstation, Server, Browser, Messenger, and NetLogon services are all direct NetBT clients that use the Transport Driver Interface (TDI) to communicate with NetBT. The NetBIOS namespace is flat, meaning that all names within a network must be unique. Resources are identified by NetBIOS names that are registered dynamically when computers start, services start, or users log on. A NetBIOS Name Query is used to locate a resource by resolving the name to an IP address.

NetBIOS Node Types

NetBIOS name resolution order depends on the node type and computer configuration. The following node types are supported:

• b-node (represented in registry by 0x1). Uses broadcasts for name registration and resolution. This is the default for all non-WINS Microsoft TCP/IP clients.

• p-node (0x2). Uses only point-to-point name queries to a NetBIOS name server (in this case WINS servers) for name registration and resolution.

• m-node (0x4). Uses broadcasts for name registration. For name resolution, it uses broadcasts first, but switches to p-node if no answer is received.

• h-node (0x8). Uses NetBIOS name server for both registration and resolution. However, if no name server can be located, it switches to b-node. It continues to poll for nameserver, switching back to p-node when one becomes available. By default, WINS clients are configured as h-node.

For more information on these methods, refer to the Microsoft Windows NT Server Networking Guide in the Microsoft Windows NT 4.0 Resource Kit.

Tuning the NodeType Registry Setting

You can find the following Windows NT setting in the registry subkey:

HKEY_LOCAL_MACHINE \CurrentControlSet \Services \NetBt \Parameters.

NodeType parameter setting.

PDC change	BDC change	Windows NT Workstation	Default
	x	x	Ox8 h-node

Recommendation:

When using a domain spanning into multiple sites, set the NetBIOS name resolution mode to m-node (broadcasts followed by nameserver) on all servers and workstations in the remote locations (assuming one network segment per branch office). This ensures that a local network resource, such as the BDC, is always contacted first (that is, before trying to contact the PDC).

NetBIOS Browsing

The Windows NT Browser service maintains a list (called the browse list) of all available domains and servers. Through Windows NT Network Neighborhood or Explorer, users can view this list provided by a NetBIOS "browser" in the local computer's domain. Windows NT assigns browser tasks to specific computers on the network. Because these computers work together to provide a centralized list of shared resources, they eliminate the need for all machines to maintain their own lists. The Windows NT browser system consists of domain master browsers, master browsers, backup browsers, and browser clients.

Domain Master Browser

Domain master browsers (DMBs) span network segments, collecting computer-name information and storing the domain-wide browse list of available resources. The DMB and cooperating master browsers on each WAN segment provide domain browsing across multiple TCP/IP network segments. The DMB resides on the PDC of a domain. Within a domain, each subnet elects a MB that exchanges a browse list with the DMB every 15 minutes.

Master Browser

The master browser collects the information necessary to create and maintain the browse list, including all servers in the master browser's domain or workgroup, and lists of all domains on the network.

When a domain spans multiple network segments, the master browsers for each network segment use a directed datagram called a MasterBrowserAnnouncement to announce themselves to the domain master browser. The datagram notifies the DMB that the sending master browser resides in the same domain, and that the domain master browser needs to copy the master browser's list.

The DMB then sends a request to the network segment's master browser to collect a list of that network segment's servers. The DMB merges its own server list with the master browser's server list every 15 minutes, guaranteeing that the DMB has a complete browse list.

Backup Browser

The backup browser receives a copy of the network-resource browse list from a master browser and distributes the list upon request to computers in the domain or workgroup. All Windows NT DCs are automatically configured as either master or backup browsers. Computers running Windows NT Workstation, Windows for Workgroups, or Windows 9x can serve as backup browsers if fewer than three Windows NT Server computers perform backup-browser functions for the TCP/IP network segment.

Backup browsers call the master every 15 minutes to get the latest copy of the browse list and a list of domains.

Browsing and Windows Internet Name Service

Retrieving a browse list takes approximately six frames: two to determine the list of backup browsers and four to get the list servers and domains in the local domain. On Windows Internet Name Service (WINS)-enabled networks, the Windows NT 3.5x or 4.0 browser periodically connects to a WINS server, scans for systems that have registered any new domain name, and adds the domain name and master browser name to its domain/workgroup list. This allows members of one domain to locate the master browser for another domain even when it is on another subnet and the two domains have no "broadcast area" in common.

Tuning Registry Settings

You can find the following Windows NT settings in the registry subkey:

HKEY_LOCAL_MACHINE \CurrentControlSet \Services \Browser \Parameters.

You do not need to restart Windows NT before changes take effect for MasterPeriodicity, but you will need to do so for BackupPeriodicity.

MasterPeriodicity

MasterPeriodicity specifies how frequently a master browser contacts the domain master browser (default 900 seconds—15 minutes). You can add this parameter as a REG_DWORD, and change it dynamically without restarting the computer.

MasterPeriodicity parameters.

PDC change	BDC change	Windows NT Workstation	Default	Minimum	Maximum
	X	X	900	300	FFFFFFFF

Recommendation:

To optimize your WAN, add this parameter on remote network master browsers. Tune master browsers on subnets within a domain because these master browsers must communicate with the domain master browser. You also want to set this value on remote Windows NT workstations in case one of them becomes the subnet's master browser.

BackupPeriodicity

BackupPeriodicity specifies how frequently a backup browser contacts the master browser (default 720 seconds—12 minutes). You can add the parameter as a REG_DWORD and must restart the computer for changes to take effect.

BackupPeriodicity parameters.

PDC change	BDC change	Windows NT Workstation	Default	Minimum	Maximum
	X	X	720	300	FFFFFFFF

Recommendation:

You can leave this parameter at its default value because tuning it does not affect WAN traffic. This broadcast communication remains within a subnet if the network is routing properly.

Printer

Network printer sharing provides users with a great shared resource, but can consume network bandwidth with printer data streams, as well as browsing advertisements and simple status notifications. Windows NT print registry settings are in this subkey:

HKEY_LOCAL_MACHINE \CurrentControlSet \Control \Print.

You must restart Windows NT in order for your changes to take effect.

DisableServerThread

DisableServerThread calls other print servers to notify them that a (local) printer exists. When you share a printer in Windows NT, the print spooler broadcasts a message on all of the print server's installed protocols to all Windows NT print servers, announcing the new print share. Print servers add the new share name to their local printer browse list, which they rebroadcast to other print servers every 10 minutes, ensuring that other print servers have current browse lists. This can cause extensive network traffic. You can add this parameter as a REG_DWORD.

DisableServerThread parameter.

PDC change	BDC change	Windows NT Workstation	Default
	X		0 (false)

Recommendation:

Disable the printer browse thread by setting it to 1 (true).

Issue to consider:

• Disabling the thread reduces network traffic, but also keeps the print servers from discovering new print shares.

NetPopup

NetPopup notifies users in real-time of their print job status. The registry setting is under the subkey:

HKEY_LOCAL_MACHINE \CurrentControlSet \Control \Print \Providers.

Add this as a REG_DWORD. Setting the entry to 1 enables NetPopup, and 0 disables NetPopup.

NetPopup parameter.

PDC change	BDC change	Windows NT Workstation	Default
	X	X	1 (enabled)

Recommendation:

Disable the printer notification on both the remote server and workstations by setting it to 0.

Issue to consider:

• Disabling NetPopup eliminates "real-time" user notification of print job status.

Server Message Block (SMB)

The Server Message Block (SMB) protocol defines a series of commands used to pass information between networked computers. In a branch office, on-demand WAN environment such as GlobalNet Insurance, a NetBIOS connection should close only when the application or service using the connection completes. Windows NT maintains its SMB connections for 10 minutes before it issues an SMB Tree Disconnect message. If connections do not drop relatively quickly, the on-demand WAN link is brought up for the sole purpose of disconnecting a session.

KeepConn specifies the maximum amount of time that a connection can be left dormant. In a WAN environment, lower this value to approximately 30 seconds on all servers and workstations to prevent establishing a new on-demand connection just to close an SMB connection.

The KeepConn setting is located in the registry subkey:

HKEY_LOCAL_MACHINE \CurrentControlSet \Services \LanmanWorkstation \Parameters.

You do not need to restart Windows NT for these changes to take effect.

KeepConn parameters.

PDC change	BDC change	Windows NT Workstation	Default	Minimum	Maximum
X	X	X	600	1	65535

Recommendation:

Set KeepConn to 30 seconds on the remote server, and also Windows NT workstations (optional).

Issue to consider:

• Changing KeepConn can generate significant SMB overhead. As connections close very quickly, each new connection implies establishing a new SMB connection.

License Management

The Windows NT license service performs licensing replication, moving software license data from BDCs and member servers to the PDCs, and optionally from PDCs to an enterprise server, which maintains licensing information across the whole network. (For more information on enterprise servers, refer to "Keeping an Enterprise Licensing Database" in Chapter 12 of the Windows NT Server Concepts and Planning Manual.)

This replication is performed once every 24 hours by default. If for some reason, the BDC cannot connect to the license service on the PDC, the BDC continues to attempt replication once every 15 minutes until it is successful.

The Start registry setting disables the Windows NT license service. You can find it in the registry subkey:

HKEY_LOCAL_MACHINE \Services \LicenseService.

You do not need to restart Windows NT for these changes to take effect.

Start parameters.

PDC change	BDC change	Windows NT Workstation	Default
X	X	X	0x2

Where: "disable" = 0x4, "automatic" = 0x2, and "manual" = 0x3.

Recommendation:

Disable the service on all Windows NT machines within the branch office domain, eliminating WAN traffic generated by the license service and reducing the PDC workload.

Issue to consider:

• If you disable this service, Windows NT cannot manage standard Microsoft BackOffice product license information.

Sample AutoRepl Code

The sample skeletal C++ code provided below makes NetLogon SAM update requests.

do {
 switch(state) {
 case 0:
 if((rascode = RasDial(...)) != SUCCESS ) {
 RasHangUp(hRasConn);
 else
 state++;
 break;
 	 
 case 1:
 retcode = I_NetLogonControl2(NULL,
 
 NETLOGON_CONTROL_TRANSPORT_NOTIFY, 
 1, 
(LPBYTE)&Dummy, 
&Dummy);
 	
 if(retcode == NO_ERROR)
 NetApiBufferFree(Dummy);
 state++;
 break;
 case 2:
 retcode = I_NetLogonControl(NULL, 
 NETLOGON_CONTROL_REPLICATE, 
 1, 
(LPBYTE *)&Buffer);
 NetApiBufferFree(Buffer);
 if(retcode != NERR_Success) { // LOGON_SERVER not
avail, etc
RasHangUp(hRasConn);
state = 0;	 // start it all over again
 	 	 
} else {
state++;
}
 break;
 
 case 3:
 retcode = I_NetLogonControl(NULL, 
 NETLOGON_CONTROL_QUERY, 
 1, 
 (LPBYTE *)&Buffer);

 if(retcode != NERR_Success) {
 NetApiBufferFree(Buffer);
 RasHangUp(hRasConn);
 state = 0;	 // start it all over again
 } else if((Buffer->netlog1_flags & 
 NETLOGON_REPLICATION_IN_PROGRESS) !=
 NETLOGON_REPLICATION_IN_PROGRESS) {
 NetApiBufferFree(Buffer);
 RasHangUp(hRasConn);
 state = 0;	 // start it all over again
 } else { 
 requery = (Buffer->netlog1_flags & 
 NETLOGON_REPLICATION_NEEDED);
 NetApiBufferFree(Buffer);
 if(!requery)
 state++;
 }
 break;
 	 
 case 4:
 RasHangUp(hRasConn);
 state++;	 // were done!!!
 break;
 }
} while(state < 5);.

More Information

Refer to these Microsoft Knowledge Base articles for more information:

• 120151, Title: Browsing a Wide Area Network with WINS

• 154355, Title: How to Tune Trusts for Dialup Routers in a WAN

• 152719, Title: WAN and Trust: Traffic on the Wire

• 163204, Title: Increase Domain Logon Timeout over Network

• 151259, Title: New Netlogon Registry Entry for Dialup Routers

• 134985, Title: Browsing & Other Traffic Incur High Costs over ISDN Routers

• 150350, Title: NetLogon Maximum Value of Pulse Should Exceed 3600