Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

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.

http://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

http://www.microsoft.com/ntserver/

Microsoft TechNet
November 1997
Volume 5, Issue 11

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.