Optimizing Windows NT Server for a Dial-on-Demand Network

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 Gary Milne, Microsoft Consulting Services

At A Glance

Key Point: Organizations that maintain a dial-on-demand network can optimize Microsoft Windows NT Server configuration to reduce the number of connections and thus reduce telecommunication costs.

Detail: High Task: Implementation, Troubleshooting

Article Section	What's There
Introduction	Configuration of Windows NT Server services affects dial-on-demand network traffic.
Dynamic Host Configuration Protocol Server Renewal Requests	Increasing the DHCP lease time decreases the amount and frequency of DHCP-related traffic.
Windows Internet Name Service (WINS) Client	Increasing the WINS renewal period is the simplest and most effective way to reduce renewal traffic
Windows NT Browser	Administrators can decrease browser update frequency.
Windows NT Server and Workstation Services	Adjust the registry settings to reduce the time before a server or workstation disconnects an idle session.
Messenger Service	Administrators can disable the messenger service for end-users.
License Logging Service (LLS)	Network administrators can disable the LLS.
Windows NT Spooler	Administrators can disable the Spooler that sends out print browser information.
Windows NT Scheduler	By default, Windows NT Scheduler does not create any network traffic.
Directory Replication	Three options in place of Directory Replication.
NETLOGON Service	Administrators should change the default settings, or disable weekly machine account password changes
Implementing Windows NT Dial-on-Demand Optimizations	A Systems Policy file (ADM) and REG file that administrators can use to configure Windows NT Server.
Conclusion
More Information	Pointers to more information on TechNet and the Microsoft web.

Introduction

Many businesses, for example insurance, real estate, travel firms, retail stores, and restaurants, often have a large number of geographically dispersed branch offices connected to a corporate office by telephone lines and routers. In an effort to contain connectivity costs, such businesses often elect not to maintain continuous network connections, but instead establish them as needed—an arrangement known as dial-on-demand connections.

The cost of ISDN or analog lines grows in proportion with their use. For example, 5000 remote sites of an insurance company use a single nightly dial-on-demand connection to the central office. At $0.10/minute, a five-minute auto-disconnect time for each site's router would still cost the company $912,000 dollars annually. By looking at the network demands of different Microsoft Windows NT operating system services, systems administrators can configure Windows NT Server to reduce the number of dial-on-demand events, and thus reduce telecommunications costs.

This paper discusses common Windows NT Server services that can affect a dial-on-demand network over TCP/IP. It provides a brief description of each service, demonstrates the impact of configuration on network traffic, describes strategies to improve the default behavior, and when appropriate, shows how to modify the registry. Although different domain models affect network traffic, this paper does not discuss specific domain planning recommendations.

Other sources of information (Microsoft Knowledge Base and TechNet articles) are cited. This article also provides examples of network traces to illustrate points conveyed in the text:

Frame	Time	Src MAC Address	Dst MAC Address	Protocol	Description
9	57.947	SERVER	PDC	NBT	NS: Refresh req. for TESTLAB <00>
10	57.954	SERVER	PDC	ARP_RARP	ARP: Reply, Target IP: 10.100.1.21 Target Hdwr Addr: 000083228675

Column definitions:

1. **Frame—**Unique number starting from 1 assigned to each frame as the network monitor receives it.

2. **Time—**Elapsed time from the beginning of the trace until the frame was received.

3. **Src MAC Address—**Source Media Access Control (MAC) address of the network card that placed the frame onto the network. These appear in the tables as a mnemonic name associated with that particular MAC address (which is always the same as the computer name).

4. **Dst MAC Address—**Destination MAC address to which the frame is sent. These display in the tables as a mnemonic name associated with that particular MAC address.

5. **Protocol—**Highest level protocol used within the frame.

6. **Description—**Summary of the activity carried by the highest level protocol.

Dynamic Host Configuration Protocol Server Renewal Requests

In a TCP/IP-based network, the Dynamic Host Configuration Protocol (DHCP) server eliminates most of the effort associated with the configuration and management of a large number of static IP addresses that computers use to communicate with one another. A DHCP server "leases" IP addresses to any DHCP client. Windows NT DHCP clients request a lease renewal from a DHCP server at boot time, halfway through the default lease time of three days, and at 87.5% and 100% of the original lease interval if the original DHCP server is unavailable.

The following network trace shows the packets that arise from a successful DHCP renewal request. A single directed request followed by a single acknowledgement (ACK).

Frame	Time	Src MAC Address	Dst MAC Address	Protocol	Description
1	2.307	LAPTOP	LONDON	DHCP	Request (xid=7A074280)
2	2.378	LONDON	SERVER	DHCP	ACK (xid=7A074280)

Increasing the DHCP lease time reduces the amount and frequency of DHCP-related traffic. An office with 10 machines using the default three-day lease produces, on average, a dial-on-demand event every 3.6 hours. The following strategies reduce the number of DHCP renewal requests:

Set DHCP lease period for a longer duration using the Windows NT Server DHCP administration utility, assuming that sufficient IP addresses are available for all machines. Increasing the renewal period lengthens the time to propagate DHCP configuration changes to all DHCP clients because longer leases delay connection with the server.

Implement a DHCP server on the local LAN segment, especially in an environment wherein a high number of clients shutdown or regularly reboot. LAN-based DHCP servers require minimal maintenance after configuration and deployment.

In small organizations, use static IP addresses to eliminate DHCP requests.

Note: For larger organizations, this could increase operational costs and is probably undesirable because of the costs associated with allocating, managing, tracking, and troubleshooting many IP addresses. However, some software or configurations may require static addresses and DHCP may not be an option.

Windows Internet Name Service (WINS) Client

Windows NT Server-based machines connect with one another over the network by obtaining IP addresses of destination computers. Windows NT Server's WINS client requests a computername and the WINS server returns its IP address. Two types of WINS traffic affect a dial-on-demand environment: WINS Queries and WINS Registration\Renewal Requests.

WINS Registration\Renewal Request

Like the DHCP clients, WINS clients must renew their registration with a WINS server. By default the WINS server sets the registration renewal period to four days. WINS clients automatically renew registrations at various intervals: halfway through this set period, when users reboot machines, when services stop or start, or when administrators promote a machine from backup domain controller (BDC) to primary domain controller (PDC).

A WINS registration number has 16 digits: the first 15 identify the computername, and the last indicates a particular type of service running on a machine. In the traces below and throughout this article, SERVERNAME<XX> refers to a server and its registration number as a two digit hexadecimal value. Common values and their significance are listed in the table below.

Frame 9 - TESTLAB <00>.	Name refresh request for the domain name.
Frame 12 - SERVER.	Name refresh request for the SERVER process, equivalent to SERVER <20>.
Frame 14 - SERVER <03>.	Name refresh request for the messenger service for the machine.
Frame 16 - SERVER <00>.	Name refresh request for the workstation process for the machine.

Frame	Time	Src MAC Address	Dst MAC Address	Protocol	Description
9	57.947	SERVER	PDC	NBT	NS: Refresh req. for TESTLAB <00>
10	57.954	SERVER	PDC	ARP_RARP	ARP: Reply, Target IP: 10.100.1.21 Target Hdwr Addr: 000083228675
11	57.954	PDC	SERVER	NBT	NS: Registration (Node Status) resp. for TESTLAB <00>, Success, Owner Addr. 10.100.1.23
12	57.955	SERVER	PDC	NBT	NS: Refresh req. for SERVER
13	57.977	PDC	SERVER	NBT	NS: Registration (Node Status) resp. for SERVER, Success, Owner Addr. 10.100.1.23
14	57.978	SERVER	PDC	NBT	NS: Refresh req. for SERVER <03>
15	58.003	PDC	SERVER	NBT	NS: Registration (Node Status) resp. for SERVER <03>, Success, Owner Addr. 10.100.1.23
16	58.003	SERVER	PDC	NBT	NS: Refresh req. for SERVER <00>
17	58.043	PDC	SERVER	NBT	NS: Registration (Node Status) resp. for SERVER <00>, Success, Owner Addr. 10.100.1.23

The number and type of registrations vary based upon the number and type of services running on a machine. For example, the PDC and the makes more WINS registrations than a member server or workstation. The four registrations shown in the above example are typical for a Windows NT Workstation or Windows NT Server that is a member of a domain.

Strategies to Reduce WINS Registration\Renewal Traffic

To reduce WINS registration and renewal traffic over a dial-on-demand connection, consider these strategies:

1. Increase the WINS renewal period—This is the simplest and most effective way to reduce WINS renewal traffic and still provide WINS services.

   Note: Windows NT Server 4.0-based machines with Remote Access Service (RAS) or that are multi-homed refresh their names with a WINS server every ten minutes, instead of using the time-to-live (TTL) value returned by the WINS server. For more information on how to correct this behavior see Knowledge Base article 164308.

2. Avoid using WINS at remote sites—Use broadcast name resolution to find local resources and an LMHOSTS file to locate remote resources. By using the LMHOSTS #INCLUDE syntax, an administrator updates a single LMHOSTS file at each remote site as needed. The distribution of this file can also be scheduled to piggyback on other business activities.

   Warning: In this scenario the Windows NT-based workstations at the remote site do not register with any WINS server, and other machines cannot locate them on the network without a static entry being created in some kind of name resolution mechanism.

3. Install a local WINS server (small organizations only)—This avoids transmissions of registrations across the WAN.

   Note: Having a large number of WINS servers is not a recommended strategy. If you have a small number of offices (2-10) then this strategy is practical.

Remote offices use WINS frequently, accessing a small percentage of resources at the corporate location. In turn, the corporate helpdesk and operations staff require WINS infrequently but immediately in supporting a large number of field machines. Because an organization needs access to all machines, it cannot eliminate WINS completely, especially when using DHCP. For most branch office environments, the best option is simply to increase the WINS renewal period.

WINS Queries

Whenever a Windows NT-based workstation attempts to locate a resource on the network, it generates a WINS query, a fairly simple process. The workstation directs the WINS server to locate a given machine or resource name, and the server responds by returning the IP address corresponding to the requested name. The following sequence shows a successful lookup on the name VENICE. The lookup query results in two packets on the local network: one request and one response.

Frame	Time	Src MAC Address	Dst MAC Address	Protocol	Description
2	2.549	GARYMIL_PC	GLASGOW	NBT	NS: Query req. for VENICE <00>
3	2.552	GLASGOW	GARYMIL_PC	NBT	NS: Query (Node Status) resp. for VENICE <00>, Success

This next trace shows a failed WINS query on the name SICILY.

Frame	Time	Src MAC Address	Dst MAC Address	Protocol	Description
1	2.446	GARYMIL_PC	GLASGOW	NBT	NS: Query req. for SICILY <00>
2	2.45	GLASGOW	GARYMIL_PC	NBT	NS: Query (Node Status) resp. for SICILY <00>, Requested
3	3.94	GARYMIL_PC	LONDON	NBT	NS: Query req. for SICILY <00>
4	3.948	LONDON	GARYMIL_PC	NBT	NS: Query (Node Status) resp. for SICILY <00>, Requested
5	5.442	GARYMIL_PC	*BROADCAST	NBT	NS: Query req. for SICILY <00>
6	6.193	GARYMIL_PC	*BROADCAST	NBT	NS: Query req. for SICILY <00>
7	6.945	GARYMIL_PC	*BROADCAST	NBT	NS: Query req. for SICILY <00>

Notice that the workstation contacts both WINS servers in turn in an attempt to resolve the name. This is followed by three broadcasts onto the local network segment at 0.75-second intervals. The total time that it takes for this name lookup to fail is 4.5 seconds.

Strategies to Reduce WINS Queries

As shown in the successful query above, WINS provides an effective and efficient method for name resolution. In most cases, attempting to modify default behavior yields no benefit because a WINS lookup precedes a network connection attempt.

In small branch offices, however, it is possible to make some efficient changes. Small offices usually have local shared resources (such as file and print shares) and no local WINS server. It is possible to save money in this situation by using the DHCP Administrator to specify a scope or global option of type 046, "WINS/NBT Node Type," an M-node (0x4) model. This ensures that machines broadcast locally for name resolution before sending a directed query to a WINS server that invokes the dial-on-demand connection. See Knowledge Base article 139270 for details on how to configure name resolution order when DHCP is not used.

To maintain name resolution performance while reducing dial-on-demand traffic, consider reducing the number and timing of the NetBIOS broadcast traffic by making the following changes.

1. To reduce the amount of time between successive NetBIOS broadcasts change the following registry key.

Registry Path	HKLM\System\CurrentControlSet\Services\NetNT\Parameters
Parameter	BcastQueryTimeout
Type	REG_DWORD
Default Value	750 (milliseconds)
Suggested Value	250 (milliseconds)

2. To reduce the number of NetBIOS broadcasts before attempting P-node change the following registry key.

Registry Path	HKLM\System\CurrentControlSet\Services\NetNT\Parameters
Parameter	BcastNameQueryCount
Type	REG_DWORD
Default Value	3
Suggested Value	2

Using the default parameters to locate a remote resource would result in a 2.25-second delay before a name query is sent to the WINS server. Using the suggested values reduces this to 0.5 seconds.

Depending upon the connect time of the dial-on-demand link, administrators can increase the timeout and retry values for the WINS server lookup, which defaults to 1.5 seconds and three retries and can timeout before the dial-on-demand connection completes. See Knowledge Base article 120642 for more information on how to implement this.

Windows NT Browser

The Windows NT Browser service provides administrators with an enterprise-wide view of available network resources. The browser service establishes a hierarchy of machines starting with the PDC as domain master browser followed by a distribution of master and backup browsers throughout the network. These browser services regularly pass data that provides a list of available domains and machines on the network.

Updating Browser Information

In a TCP/IP–based network, each segment (subnet) automatically elects one machine to function as the master browser, with several other machines operating as backup browsers. By default, each master browser attempts to contact the domain master browser every twelve minutes using a remote procedure call (RPC) over a named pipe to request a new browser list. If the domain master browser recognizes that the master browser is connecting from a remote subnet (a subnet other than one to which the domain master browser is directly connected) it will in turn establish a named pipe connection to the calling master browser, request its browse list, and use that information to update its own master browse list. Because the browser uses named pipes to establish a connection and pass information, the default workstation idle timeout period applies (see the "Windows NT Server and Workstation Services" section below for more information).

Strategies to Reduce Browser Traffic

Establishing a connection every twelve minutes, 365 days per year is a very expensive proposition for any dial-on-demand environment. Fortunately, there are several ways to reduce the impact of the Windows NT browser service:

1. Reduce browser update frequency—Change the default of 720 seconds to a more reasonable number for a dial-on-demand network. To reduce the frequency at which the master browser attempts to connect to the domain master browser change the following registry key on all machines that serve as a master browser. For more information on browser services, see Knowledge Base articles 102878 and 134985.

Registry Path	HKLM\System\CurrentControlSet\Services\Browser\Parameters
Parameter	MasterPeriodicity
Type	REG_DWORD
Default Value	720 (seconds)
Suggested Value	86400 (seconds) – i.e. Daily.

Note: This value of 86400 seconds is a suggestion. Systems administrators must evaluate the cost of this dial-on-demand connection for their organizations.

2. Disable the browser after business hours—Administrators can easily stop and start browser service using the command prompt line NET STOP BROWSER, and stop browser service after working hours with the Windows NT Scheduler.

3. Disable the browser completely—If a network doesn't require browser service, administrators can disable the service, which requires disabling the service on all machines in a subnet.

Warning: Programs such as Server Manager that provide a "Select Computer" menu option do so by using the browse list. If the browser service is disabled, users must type in a computer name and they cannot browse all domains.

Windows NT Server and Workstation Services

These services support the client and server connections between two Windows NT-based systems. Both of these services exist on Windows NT Workstation and Server and under normal conditions run at all times.

Server Service

This networking service maintains incoming connections to a machine. Without it, a machine can not receive connections from other machines. The server service generates only low level browser traffic that announces the presence of the server service on the network. The most important element of this service for a dial-on-demand network is the idle disconnect timeout value that specifies how long a connection to the server can remain idle before disconnecting. To reduce the time before an idle session disconnects from the server, administrators can change or add the following registry key. See Knowledge Base articles 138365 and 105134 for more information on this setting.

Registry Path	HKLM\System\CurrentControlSet\Services\LanManServer\Parameters
Parameter	AutoDisconnect
Type	REG_DWORD
Default Value	15 (minutes)
Suggested Value	2 (minutes)

Workstation Service

This service parallels the Server service described in the section above. Without it, a machine cannot connect to a remote server. The workstation service creates only low level browser traffic that announces the presence of the workstation service on the network.

Like the server service, the workstation service also controls an idle disconnect parameter. The following trace shows a named pipe connection between two machines for the transfer of browser information. In this trace the workstation idle disconnect time was reduced to 60 seconds.

Frame	Time	Src MAC Address	Dst MAC Address	Protocol	Description
1	6.553	GLASGOW	LONDON	TCP	....S., len: 4, seq: 9483601-9483604, ack: 0, win: 8
2	6.554	LONDON	GLASGOW	TCP	.A..S., len: 4, seq: 9537563-9537566, ack: 9483602, win: 8
3	6.555	GLASGOW	LONDON	TCP	.A...., len: 0, seq: 9483602-9483602, ack: 9537564, win: 8
4	6.556	GLASGOW	LONDON	NBT	SS: Session Request, Dest: LONDON , Source: GLASGOW
5	6.558	LONDON	GLASGOW	NBT	SS: Positive Session Response, Len: 0
6	6.56	GLASGOW	LONDON	SMB	C negotiate, Dialect = NT LM 0.12
7	6.563	LONDON	GLASGOW	SMB	R negotiate, Dialect # = 7
8	6.567	GLASGOW	LONDON	SMB	C session setup & X, Username = , and C tree connect & X, Share =
9	6.584	LONDON	GLASGOW	SMB	R session setup & X, and R tree connect & X, Type = IPC
10	6.588	GLASGOW	LONDON	SMB	C transact, Remote API
11	6.609	LONDON	GLASGOW	SMB	R transact, Remote API (response to Frame 10)
12	6.616	GLASGOW	LONDON	SMB	C transact, Remote API
13	6.632	LONDON	GLASGOW	SMB	R transact, Remote API (response to Frame 12)
14	6.75	GLASGOW	LONDON	TCP	.A...., len: 0, seq: 9484272-9484272, ack: 9538051, win: 8
15	67.615	GLASGOW	LONDON	SMB	C tree disconnect
16	67.621	LONDON	GLASGOW	SMB	R tree disconnect
17	67.622	GLASGOW	LONDON	SMB	C logoff & X
18	67.624	LONDON	GLASGOW	SMB	R logoff & X
19	67.625	GLASGOW	LONDON	TCP	.A...F, len: 0, seq: 9484354-9484354, ack: 9538133, win: 8
20	67.627	LONDON	GLASGOW	TCP	.A...F, len: 0, seq: 9538133-9538133, ack: 9484355, win: 8
21	67.628	GLASGOW	LONDON	TCP	.A...., len: 0, seq: 9484355-9484355, ack: 9538134, win: 8

Frame 8 shows the named pipe connection being initiated; data transfer is finished by Frame 13. Notice however that the connection remains intact until the idle disconnect timeout is reached—an additional 60 seconds. In Frame 15, approximately 60 seconds later, the workstation initiates a disconnect from the server.

To reduce the time before a workstation disconnects an idle session, add or change the following registry key. See Knowledge Base article 102981 for more information on this setting.

Registry Path	HKLM\System\CurrentControlSet\Services\LanManServer\Parameters
Parameter	KeepConn
Type	REG_DWORD
Default Value	600 (seconds)
Suggested Value	90 (seconds)

Administrators should make sure that the idle disconnect parameters for both the server and workstation services fall within the auto-disconnect value configured on the dial-on-demand routers. The AutoDisconnect time for the server service should remain higher than that for the workstation service so that the workstation initiates the disconnect process.

Messenger Service

The messenger service receives network messages and displays them to the logged in user through a popup dialog box, for example print notification or administrative alerts. The messenger service is not required in order to send messages, only to receive them.

The following trace demonstrates network activity when starting the Windows NT messenger service.

Frame	Time	Src MAC Address	Dst MAC Address	Protocol	Description
16	3.223	SERVER	PDC	NBT	NS: Registration req. for SERVER <03>
17	3.231	PDC	SERVER	NBT	NS: Registration (Node Status) resp. for SERVER <03>, Success
18	3.484	SERVER	PDC	NBT	NS: Registration req. for GARYMIL <03>
19	3.489	PDC	SERVER	NBT	NS: Registration (Node Status) resp. for GARYMIL <03>, Success

The messenger service makes two "<03>" type WINS registrations, the first one for the machine name and the second for the logged on user. A typical startup sequence shows only the entry for the machine registration when the messenger service starts, and the second WINS registration entry when a user logs on.

Whenever users shut down machines, messenger service stops, and the machine releases its WINS name (Frame17 below). When users log off machines, WINS releases usernames (Frame 18).

Frame	Time	Src MAC Address	Dst MAC Address	Protocol	Description
17	4.071	SERVER	PDC	NBT	NS: Release req. for WS001048 <03>
18	4.072	SERVER	PDC	NBT	NS: Release req. for HXGJM0 <03>
19	4.074	PDC	SERVER	NBT	NS: Release (Node Status) resp. for WS001048 <03>, Success
20	4.076	PDC	SERVER	NBT	NS: Release (Node Status) resp. for HXGJM0 <03>, Success

Sending Messages via the Messenger Service

The following trace shows the network traffic that results from a simple NET SEND command.

Frame	Time	Src MAC Address	Dst MAC Address	Protocol	Description
4	1.953	SERVER	PDC	NBT	NS: Query req. for EINSTEIN <03>
5	1.964	PDC	SERVER	NBT	NS: Query (Node Status) resp. for EINSTEIN <03>, Success
6	1.965	SERVER	*BROADCAST	ARP_RARP	ARP: Request, Target IP: 10.169.105.34
7	1.966	WKS01	SERVER	ARP_RARP	ARP: Reply, Target IP: 10.169.105.20 Target Hdwr Addr: 0000832B8A77
8	1.966	SERVER	WKS01	TCP	....S., len: 4, seq: 511560177, ack: 0, win: 8192, src: 1590 dst: 139
9	1.967	WKS01	SERVER	TCP	.A..S., len: 4, seq: 4010727, ack: 511560178, win:16064, src: 139 dst: 159
10	1.968	SERVER	WKS01	TCP	.A...., len: 0, seq: 511560178, ack: 4010728, win:16064, src: 1590 dst: 139
11	1.968	SERVER	WKS01	NBT	SS: Session Request, Dest: EINSTEIN <03>, Source: SERVER <01>, Len: 68
12	1.969	WKS01	SERVER	NBT	SS: Positive Session Response, Len: 0
13	1.97	SERVER	WKS01	SMB	C send message, from SERVER to EINSTEIN
14	2.085	WKS01	SERVER	TCP	.A...., len: 0, seq: 4010732, ack: 511560339, win:15903, src: 139 …
15	2.112	WKS01	SERVER	SMB	C send message, reply
16	2.113	SERVER	WKS01	TCP	.A...F, len: 0, seq: 511560339, ack: 4010771, win:16021, src: 1590 dst: 139
17	2.114	WKS01	SERVER	TCP	.A...F, len: 0, seq: 4010771, ack: 511560340, win:15903, src: 139 dst: 159
18	2.115	SERVER	WKS01	TCP	.A...., len: 0, seq: 511560340, ack: 4010772, win:16021, src: 1590 dst: 139

It begins with a name query and response in Frames 4 and 5. After receiving the target address the server performs a Reverse Address Resolution Protocol (RARP) to retrieve the MAC address for the destination node. A TCP/IP session is established in Frames 8-10. A NetBIOS session is established in Frames 11 and 12. Finally in Frame 13, a workstation sends a message and the server returns a success code (Frame 15).

Messenger Service Strategy

With the exception of receiving print notifications and system alerts, the messenger service provides little benefit to end-users. Administrators can disable it. The messenger service adds minimal network traffic, but has some drawbacks:

• If a LAN has a local WINS server, user logon/logoff a Windows NT-based machine with messenger service creates minimal network traffic with WINS registration. If the LAN does not have a local WINS server and a local BDC validates user accounts, the messenger service unnecessarily uses the router.

• The messenger service makes two WINS registrations, one for the machine and one for the user. A network that replicates WINS information across a large number of remote sites effectively doubles the amount of the WINS data that it transfers.

• Use of the NET SEND "Message" /DOMAIN:NAME command can tax the dial-on-demand connection very quickly by tying up all of the available lines.

License Logging Service (LLS)

The LLS allows a LAN administrator to track the usage of Microsoft BackOffice licenses throughout the enterprise. If the LLS is enabled, it will store license usage information locally and periodically roll it up to a central license-logging server. By default the central license-logging server is the PDC for the domain although a separate server can be specified using the license manager application. The LLS is present only on Windows NT-based servers.

License Logging Service Traffic

The LLS creates three types of network traffic identified in the following traces.

1. At service start time, the LLS sends its license information to the PDC as shown in the example below, it queries for the domain name (Frames 3-4) and then queries the NETLOGON service for the PDC name. If the LLS reports to an enterprise server, a WINS query resolves the name of that particular machine.

Frame	Time	Src MAC Address	Dst MAC Address	Protocol	Description
2	3.54	SERVER	*BROADCAST	ARP_RARP	ARP: Request, Target IP: 10.100.1.21
3	3.54	PDC	SERVER	ARP_RARP	ARP: Reply, Target IP: 10.100.1.23 Target Hdwr Addr: 0000F6181D73
4	3.541	SERVER	PDC	NBT	SERVER NS: Query req. for TESTLAB <1B>
5	3.548	PDC	SERVER	NBT	PDC NS: Query (Node Status) resp. for TESTLAB <1B>, Success
6	3.561	SERVER	PDC	NETLOGON	SERVER Query for Primary DC
7	3.564	PDC	SERVER	NETLOGON	PDC Response to Primary Query

2. If the Windows NT Server cannot communicate with the central LLS, it attempts to reconnect every 15 minutes. If an enterprise server regularly receives license information, the server must be available at all times.

Note: Because the LLS uses a redirector connection to pass LLS information, the workstation service idle disconnect timeout period applies to the use of this service. Refer to the "Windows NT Server and Workstation Services" section above for more information.

3. The LLS replicates license information to the PDC or enterprise server every 24 hours by default. With the License Manager administrators can configure this interval (from 1-72 hours) and the start time. By default Windows NT Server automatically staggers submission of license information to the PDC to avoid overloading the server.

License Logging Service Strategy

Network administrators can disable the LLS, and not adversely affect the operation of Windows NT in any way. If the network uses the service, administrators should configure the replication interval and start time according to specific needs. In a LAN environment the LLS replication usually occurs at night. In a dial-on-demand environment, administrators should configure this time to maximize a connection that has already been established. For example, if there is dial-on-demand connection every night between 4:00AM and 6:00 AM for backups, LLS replication can occur during that window.

Windows NT Spooler

There are several conditions under which Windows NT printing services access the network: connecting to printers, printing, and checking printer and job status. Usually client machines are close to their printers and do not generate WAN traffic.

The Windows NT Spooler can cause excess dialing in the process of distributing information on available printers throughout the enterprise. Windows NT Spooler sends out print browser information every 777 seconds as shown in the trace below. Frame 13 shows the initial connection to the SPOOLSS named pipe on the remote server. This same connection pattern is then repeated in Frames 98, 175 and 749 at 777-second intervals. Some frames have been omitted for clarity.

Frame	Time	Src MAC Address	Dst MAC Address	Protocol	Description
7	7.373	LONDON	GLASGOW	NBT	SS: Session Request, Dest: GLASGOW , Source: LONDON
8	7.373	GLASGOW	LONDON	NBT	SS: Positive Session Response, Len: 0
9	7.377	LONDON	GLASGOW	SMB	C negotiate, Dialect = NT LM 0.12
10	7.378	GLASGOW	LONDON	SMB	R negotiate, Dialect # = 7
11	7.401	LONDON	GLASGOW	SMB	C session setup & X, Username = , and C tree connect & X, Share =
12	7.406	GLASGOW	LONDON	SMB	R session setup & X, and R tree connect & X, Type = IPC
13	7.411	LONDON	GLASGOW	SMB	C NT create & X, File = \spoolss
14	7.418	GLASGOW	LONDON	SMB	R NT create & X, FID = 0x801
15	7.422	LONDON	GLASGOW	MSRPC	c/o RPC Bind: UUID 12345678-1234-ABCD-EF00-0123456789AB
16	7.428	GLASGOW	LONDON	MSRPC	c/o RPC Bind Ack: call 0x44005C assoc grp 0x394C7A xmit 0x1
17	7.432	LONDON	GLASGOW	R_WINSPOO	Error: Bad Opcode (Function does not exist)
18	7.438	GLASGOW	LONDON	R_WINSPOO	Error: Bad Opcode (Function does not exist)
19	7.441	LONDON	GLASGOW	SMB	C close file, FID = 0x801
20	7.445	GLASGOW	LONDON	SMB	R close file
98	784.562	GLASGOW	LONDON	SMB	C NT create & X, File = \spoolss
175	1807.79	LONDON	GLASGOW	SMB	C NT create & X, File = \spoolss
749	2584.88	GLASGOW	LONDON	SMB	C NT create & X, File = \spoolss

Network administrators should modify the default print browser parameter described in the table below to the suggested value using REGEDIT.EXE. Disabling the thread reduces network traffic, but prevents the print servers knowing about other print shares on the network. See Knowledge Base article 131902 for more information.

Registry Path	HKLM\System\CurrentControlSet\Control\Print
Parameter	DisableServerThread
Type	REG_DWORD
Default Value	0 (enabled)
Suggested Value	1 (disabled)

Windows NT Scheduler

By default the Windows NT Scheduler service runs under the "LocalSystem" account on a Windows NT machine. This account is part of the local security accounts manager (SAM) database and does not have access to the network. Under these conditions stopping and starting the Windows NT Scheduler does not create any network traffic. However, if the scheduler runs under a domain account, authentication takes place when the service starts, and if the scheduler account has a central profile, it is copied to the local machine. The scheduler causes network traffic when a scheduled job uses network facilities for WINS lookups, file copying, and so forth.

Directory Replication

The Directory Replication service synchronizes a directory structure between machines in the domain, primarily the NETLOGON shares between the PDC and all BDCs. The NETLOGON share typically contains all of the scripts associated with the logon process. Although this Directory Replication works well in a LAN environment it can severely tax a dial-on-demand connection.

The default interval for directory replication is five minutes. Administrators can modify this interval using the registry information shown below. However, the Directory Replication service accepts a maximum interval of 60 minutes.

Registry Path	HKLM\System\CurrentControlSet\Replicator\Parameters\Interval
Parameter	Interval
Type	REG_DWORD
Default Value	5 (minutes) Range 1-60
Suggested Value	60 (minutes)

This interval controls the frequency at which the export computer checks its export file system for changes. The export computer then contacts its partners and notifies them of an update. The replicator service on the export server will still attempt to communicate with the replicator service on the import server even if there are no changes in the file system just to ensure that it is still available. Import computers then contact the export server and copy any directories in which changes are found. If the export server fails to contact the import server within a defined period (Interval x Pulse) then the import server initiates communication.

Replication Characteristics

When the Directory Replication service detects a change in the file system, it replicates all of the contents for the directory, including any sub-directories. When there are many files or change is frequent, replication can be time consuming. The Directory Replication service uses the redirector to establish a connection and transfer the files. The idle disconnect parameters described in "Windows NT Server and Workstation Services" section above apply to directory replication.

Directory Replication Strategy

Because Directory Replication service severely impacts a dial-on-demand network, network administrators should consider disabling the service and using one of the following options:

1. Use the Windows NT Scheduler service to run a batch job on a regular basis that copies any changed files. The Windows NT Server Resource Kit ROBOCOPY.EXE utility provides the ability to synchronize source and destination directories by copying only differences. This method does have some implications.

   The Windows NT Scheduler account must run under a domain account. In a network with standalone domains, without trusts or individual Windows NT-based machines with local logon files, administrators should use the LocalSystem account for the replicator service. Configure a Null Session Share on the servers hosting the master copy of the logon scripts and give everyone READ access to the share. (See Knowledge Base article 124184.) The Windows NT Scheduler service on the remote machines should now be able to access all of the files on that share.

2. Use the Microsoft Content Replication server.

3. Distribute LOGON files with routine business activities.

NETLOGON Service

The NETLOGON service provides three primary functions within Windows NT domains:

1. On the PDC, the NETLOGON service ensures that all of the BDCs regularly receive copies of all changes made to the domain SAM database.

2. On domain controllers, the NETLOGON service authenticates domain logon requests against the local copy of the domain SAM database.

3. The NETLOGON service supports pass-through authentication to other domains.

Of these functions, the first affects dial-on-demand environments. By default the NETLOGON service sends an update pulse every five minutes to all BDCs. A systems administrator can configure a number of parameters to reduce this NETLOGON activity. TechNet Article "B.4.7 NETLOGON Service Entries" documents this configuration.

The following trace illustrates the sequence for providing NETLOGON updates between the PDC (LONDON) and BDC (GLASGOW) within a domain. The domain had been previously synchronized to ensure that only a single change is represented. The changed data is carried in Frame 7.

Frame	Time	Src MAC Address	Dst MAC Address	Protocol	Description
1	157.360	LONDON	GLASGOW	NETLOGON	Announce Change to UAS or SAM
2	158.036	GLASGOW	LONDON	SMB	C NT create & X, File = \NETLOGON
3	158.073	LONDON	GLASGOW	SMB	R NT create & X, FID = 0x800a
4	158.076	GLASGOW	LONDON	MSRPC	c/o RPC Bind: UUID 12345678-1234-ABCD-EF00-01234567CFFB
5	158.092	LONDON	GLASGOW	MSRPC	c/o RPC Bind Ack: call 0x0 assoc grp 0x8159 xmit 0x1630 re
6	158.095	GLASGOW	LONDON	R_LOGON	RPC Client call logon:NetrDatabaseDeltas(..)
7	158.165	LONDON	GLASGOW	R_LOGON	RPC Server response logon:NetrDatabaseDeltas(..)
8	158.288	GLASGOW	LONDON	TCP	.A...., len: 0, seq: 876161-876161, ack: 1823715, win: 87

Other NETLOGON Traffic

In addition to the NETLOGON functions listed above, other functions can affect a dial-on-demand environment:

1. Establishing a Secure Channel to other Domains—When a NETLOGON Service starts on a domain controller it immediately attempts to contact a domain controller in each of the trusted domains. The communication establishes a secure channel that allows pass-through authentication to the SAM database with the trusted domains.

In the domain environment represented in the trace below, the resource domain trusts the account domain, therefore the domain controllers (DCs) in the resource domain must establish a secure channel to a DC in the account domain.

Account Domain – USA	Resource Domain – EUROPE
NEWYORK – PDC	LONDON – PDC
SEATTLE – BDC	PARIS – BDC
CHICAGO – BDC

When the NETLOGON service on the PARIS BDC. starts, it locates the PDC for its own domain and establishes a connection to the NETLOGON named pipe. PARIS then authenticates itself against the PDC (Frames 7-10) so that it can begin to receive SAM updates. PARIS then attempts to locate a domain controller in the trusted domain USA by sending out SAM LOGON requests in Frames 11-13. On a system reboot the machine would typically use WINS to obtain a list of DCs in the trusted domain. The first DC from the account domain to respond is CHICAGO in Frame 14. This machine will be used to process any pass-through authentication requests. (To check the status of pass-through authentication use the Windows NT Resource Kit utility DOMMON.EXE.) The BDC then synchronizes the SAM with the PDC by requesting any outstanding changes in Frames 15-18.

Frame	Time	Src MAC Address	Dst MAC Address	Protocol	Description
1	9.276	PARIS	LONDON	NETLOGON	Query for Primary DC
2	9.278	LONDON	PARIS	NETLOGON	Response to Primary Query
3	9.29	PARIS	LONDON	SMB	C NT create & X, File = \NETLOGON
4	9.292	LONDON	PARIS	SMB	R NT create & X, FID = 0x5001
5	9.292	PARIS	LONDON	MSRPC	c/o RPC Bind: UUID 12345678-1234-ABCD …
6	9.293	LONDON	PARIS	MSRPC	c/o RPC Bind Ack: call 0x1 assoc grp 0x9B50 xmit 0
7	9.294	PARIS	LONDON	R_LOGON	RPC Client call logon:NetrServerReqChallenge(..)
8	9.295	LONDON	PARIS	R_LOGON	RPC Server response logon:NetrServerReqChallenge(..)
9	9.296	PARIS	LONDON	R_LOGON	RPC Client call logon:NetrServerAuthenticate2(..)
10	9.301	LONDON	PARIS	R_LOGON	RPC Server response logon:NetrServerAuthenticate2(..)
11	9.303	PARIS	*BROADCAST	NETLOGON	SAM LOGON request from client
12	9.303	PARIS	NEWYORK	NETLOGON	SAM LOGON request from client
13	9.304	PARIS	NEWYORK	NETLOGON	SAM LOGON request from client
14	9.305	CHICAGO	PARIS	NETLOGON	SAM Response to SAM LOGON request
15	9.33	PARIS	LONDON	R_LOGON	RPC Client call logon:NetrDatabaseDeltas(..)
16	9.332	LONDON	PARIS	R_LOGON	RPC Server response logon:NetrDatabaseDeltas(..)
17	9.333	PARIS	LONDON	R_LOGON	RPC Client call logon:NetrDatabaseDeltas(..)
18	9.334	LONDON	PARIS	R_LOGON	RPC Server response logon:NetrDatabaseDeltas(..)
19	9.334	SEATTLE	PARIS	NETLOGON	SAM Response to SAM LOGON request
20	9.336	PARIS	LONDON	R_LOGON	RPC Client call logon:NetrDatabaseDeltas(..)
21	9.337	LONDON	PARIS	R_LOGON	RPC Server response logon:NetrDatabaseDeltas(..)

In most cases this sequence poses no problem, but stopping and starting DCs or the NETLOGON service initiates in a dial-on-demand event in order to establish a secure channel to a trusted domain. In some domain designs this behavior could result in numerous dial-on-demand events occurring for every DC that is restarted.

2. NETLOGON Service—Changing Machine and Trust Relationship Passwords—When administrators configure a trust relationship for the first time, they enter an initial password on both sides to enable the domains to communicate securely. Once established, each PDC establishes a secret account and password with their counterpart. On a weekly basis this password is changed automatically as shown in the trace below. The actual passwords are set in Frames 24 and 26 respectively. Because this information is part of Local Security Authority (LSA) secrets the domain immediately attempt to synchronize the SAM with all backup domain controllers.

Frame	Time	Src MAC Address	Dst MAC Address	Protocol	Description
1	33.634	LONDON	*BROADCAST	NBT	NS: Query req. for NEWYORK
2	33.639	NEWYORK	*BROADCAST	ARP_RARP	ARP: Request, Target IP: 89.0.0.3
3	33.640	LONDON	NEWYORK	ARP_RARP	ARP: Reply, Target IP: 89.0.0.2 Target Hdwr Addr: 0080C7E2168A
4	33.640	NEWYORK	LONDON	NBT	NS: Query (Node Status) resp. for NEWYORK, Success
5	33.642	LONDON	NEWYORK	TCP	....S., len: 4, seq: 604893393-604893396, ack: 0, win:
6	33.643	NEWYORK	LONDON	TCP	.A..S., len: 4, seq: 391927223-391927226, ack: 604893394, win:
7	33.645	LONDON	NEWYORK	TCP	.A...., len: 0, seq: 604893394-604893394, ack: 391927224, win:
8	33.645	LONDON	NEWYORK	NBT	SS: Session Request, Dest: NEWYORK , Source: LONDON
9	33.646	NEWYORK	LONDON	NBT	SS: Positive Session Response, Len: 0
10	33.656	LONDON	NEWYORK	SMB	C negotiate, Dialect = NT LM 0.12
11	33.658	NEWYORK	LONDON	SMB	R negotiate, Dialect # = 7
12	33.717	LONDON	NEWYORK	SMB	C session setup & X, Username = , and C tree connect & X, Share =
13	33.721	NEWYORK	LONDON	SMB	R session setup & X, and R tree connect & X, Type = IPC
14	33.734	LONDON	NEWYORK	SMB	C NT create & X, File = \NETLOGON
15	33.742	NEWYORK	LONDON	SMB	R NT create & X, FID = 0x800
16	33.755	LONDON	NEWYORK	MSRPC	c/o RPC Bind: UUID 12345678-1234-ABCD-EF00-01234567CFFB
17	33.762	NEWYORK	LONDON	MSRPC	c/o RPC Bind Ack: call 0x3 assoc grp 0xE6F8 xmit 0x1630 re
18	33.809	LONDON	NEWYORK	R_LOGON	RPC Client call logon:NetrServerReqChallenge(..)
19	33.815	NEWYORK	LONDON	R_LOGON	RPC Server response logon:NetrServerReqChallenge(..)
20	33.850	LONDON	NEWYORK	R_LOGON	RPC Client call logon:NetrServerAuthenticate2(..)
21	34.009	NEWYORK	LONDON	TCP	.A...., len: 0, seq: 391927786-391927786, ack: 604894484, win:
22	34.124	NEWYORK	LONDON	R_LOGON	RPC Server response logon:NetrServerAuthenticate2(..)
23	34.291	LONDON	NEWYORK	TCP	.A...., len: 0, seq: 604894484-604894484, ack: 391927886, win:
24	34.650	LONDON	NEWYORK	R_LOGON	RPC Client call logon:NetrServerPasswordSet(..)
25	34.811	NEWYORK	LONDON	TCP	.A...., len: 0, seq: 391927886-391927886, ack: 604894712, win:
26	34.886	NEWYORK	LONDON	R_LOGON	RPC Server response logon:NetrServerPasswordSet(..)
27	34.992	LONDON	NEWYORK	TCP	.A...., len: 0, seq: 604894712-604894712, ack: 391927986, win:

In the case of a Windows NT Server or Workstation that is a member of the domain there is an activity to that described above but only in a single direction. The Windows NT-based machine will receive a password that it can use in conjunction with its machine account to provide pass-through authentication to the domain NETLOGON services. Like the trust password the machine password also gets changed on a weekly basis.

Note: In Windows NT Server domains all changes to the SAM, including machine account information, occur at the PDC.

3. Disabling Machine Account Password Changes—In an organization with 5000 copies of Windows NT Workstation installed into a large dial-on-demand network the annual cost of this type of traffic alone could be as high as $130,000 (5000 nodes x 52 weeks x 5 minutes per call x $0.10 per minute). To disable the machine account password change on a Windows NT Workstation or Server, edit the following registry key. (Refer to Knowledge Base article 154501 for more information on disabling machine account passwords.)

Registry Path	HKLM\System\CurrentControlSet\Service\NETLOGON\Parameters
Parameter	DisablePasswordChange
Type	REG_DWORD
Default Value	0 (enabled)
Suggested Value	1 (disabled)

4. Replicating LSA Secrets—One class of security information, LSA secrets, requires that the SAM be synchronized without waiting for the next NETLOGON pulse period. Although administrators have correctly configured the NETLOGON parameters of "ChangeLogSize" and "Pulse," LSA Secrets replication can increase NETLOGON traffic with:

• Addition of machine accounts to the domain (but not deletion).

• Changes in machine account passwords.

• Changes in account policies.

• Changes in trust relationships including trust password changes.

The synchronization of LSA Secrets uses the same transmission mechanism as all other NETLOGON data except that it happens immediately instead of being deferred until the next NETLOGON pulse. Although administrators can not alter the behavior of LSA Secrets replication, simple measures such as creating machine accounts in batch mode instead of sporadically throughout the day can reduce unwanted connections.

Strategies for Reducing NETLOGON Traffic

1. The NETLOGON service, unlike some other Windows NT Server services, cannot be disabled. Whether the domain design has a BDC at each remote location or BDCs located centrally, here are two ways to reduce traffic: Change the default parameters for NETLOGON replication.

2. Disable weekly machine account password changes.

Implementing Windows NT Dial-on-Demand Optimizations

Administrators can configure all Windows NT Server-based machines optimally for a dial-on-demand network during a deployment. However, administrators face a greater challenge implementing the recommended changes to an existing network because machines may not follow a standard configuration. This section includes a Windows NT policy file that allows administrators to configure Windows NT 4.0-based machines with a set of parameters.

Implementing Dial-on-Demand Policies in an Windows NT 4.0 Domain

Save the embedded policy file (DOD.ADM) below to a local filesystem on a server and name it DOD.ADM. Start the Windows NT Policy Editor and select Options-Policy Template, and add the DOD.ADM file. Make the selections that you require and save the file as NTCONFIG.POL. Windows NT Server adds this new policy and automatically applies it to all machines in the domain, guaranteeing that both existing and new machines are optimized with the appropriate dial-on-demand policies. For information on the use and deployment of system policies see the Window NT Server 4.0 documentation.

https://www.microsoft.com

Implementing Dial-on-Demand Policies on Standalone Windows NT 4.0 Workstations or Servers

In an environment where Windows NT-based machines are not members of a domain, administrators can still implement local policies. However, this requires a one-time modification to every machine. To implement local policies open the registry editor and edit or create the following registry values.

Registry Path	HKEY_LOCAL_MACHINE \System \CurrentControlSet \Control \Update
Parameter	UpdateMode
Type	REG_DWORD
Value	2 (manual updates)

Registry Path	HKEY_LOCAL_MACHINE \System \CurrentControlSet \Control \Update
Parameter	NetworkPath
Type	REG_SZ
Value	C:\WINNT\POLICY\NTCONFIG.POL (example only)

To implement this registry or editing step on a large number of machines, export this registry key to a .REG file using REGEDIT.EXE. Then merge this key on remote machines by using Windows NT Scheduler, Microsoft Systems Management Server, or some other method. Create the NTCONFIG.POL file and save to a directory. Reboot each machine twice to make sure policies have installed completely. The first reboot applies the policy and changes the registry to reflect the new value. The second reboot makes changes to services that users started prior to applying the policies.

Implementing Dial-on-Demand Policies using a REG File

If administrators prefer not use System Polices in their environments, they can apply the template .REG file (included below) with Windows NT Scheduler or other software distribution tools. To perform a silent installation of a .REG file, use REGEDIT /S DOD.REG. The settings in the .REG file are the same as the suggested values found throughout this paper. The .REG file states values in hexadecimal, not decimal. The Windows calculator provides a conversion equation.

This sample file is only available from the TechNet CD product.

Conclusion

The Windows NT Server default parameters operate effectively over a permanently connected network. Applying them to a dial-on-demand network will likely result in unnecessarily high telecommunications costs and the need for excessive peak capacity. IT professionals should consider these recommendations in the context of their own environment, and the potential impact on the usability and maintenance of the network.

More Information

On TechNet:

MS Windows NT Server 4.0 Networking Guide	Presents detailed information that is specific mainly to using Windows NT Server on or with a network.
Chapter 24 - Registry Editor and Registry Administration	Details how to use the Registry editors, with an emphasis on protecting the Registry contents.

On the Microsoft Web:

Windows NT Server Product Page

https://www.microsoft.com/ntserver/

Microsoft TechNet
November 1997
Volume 5, Issue 11