Export (0) Print
Expand All

Optimizing for a Dial-on-Demand Network at FoodCo

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, MCSMinnesota

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

Maintaining continuous connection over ISDN or analog lines can be expensive, and dial-on-demand networks, which establish connections only when needed, can help reduce communications costs. To maximize these savings with Windows NT, you should specially configure some system services for dial-on-demand configuration to make sure that you minimize unnecessary connectiona seemingly minor problem that can become significant in large networks.

For instance, suppose an average long-distance cost of $0.10/minute. If each of the 3,000 servers in the FoodCo network (on which this chapter is based) initiates one unnecessary dial-up session per day, the cost, even with a five-minute AutoDisconnect setting, would be more than one-half million dollars per year.

On This Page

In Focus
Customer Profile
Focusing on Windows NT Services
Dynamic Host Configuration Protocol Server Renewal Requests
Windows Internet Name Service (WINS) Client
Windows NT Browser
Windows NT Server and Workstation Services
Messenger Service
License Logging Service (LLS)
Windows NT Spooler
Windows NT Scheduler
Directory Replication
NETLOGON Service
Other NETLOGON Traffic
Implementing Windows NT Dial-on-Demand Optimizations

In Focus

Enterprise

FoodCo, a large food retailer and wholesaler recently integrated a variety of proprietary systems through growth and acquisition.

Network

The only form of communication and network infrastructure for FoodCo's rural locations is via modem over a PSTN connection.

Challenge

Configuring Windows NT Server for a dial-on-demand network.

Solution

Of the methods researched, only Windows NT Server with the Routing and Remote Access Service (RRAS) update met all of the networking requirements and provided a suitable application platform.

What You'll Find In This Chapter

  • Description of Windows NT Server services that affect dial-up networks.

  • In-depth look at network communication traces.

  • Best practices for configuring services for a dial-on-demand network.

  • Other tips and strategies for tuning network services.

  • Sample files to implement dial-on-demand policies.

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

Customer Profile

FoodCo is a large food retailer and wholesaler with over 3000 distribution and retail centers. Due to its steady growth and competitive acquisitions, it ended up with a mainframe-based environment and a variety of aging proprietary systems that did not meet administrative or customer needs.

Business Need

Initially, sales and inventory reports were delivered to stores in hardcopya difficult, costly, and unreliable method, with data sometimes superseded before it could be delivered. FoodCo needed real-time distribution of various electronic reports (most notably invoices), e-mail, corporate information Internet and intranet access, and expandability. This required building a standards-based push/pull infrastructure that allowed headquarters to push urgent information to the stores, and stores to pull information from headquarters regularly. Established applications for report distribution, e-mail, online ordering, etc. were layered on top of the infrastructure. Networking had to be transparent and fully routed so that new applications could be added without changing the network infrastructure.

The solution had to:

  • Support push/pull information exchange.

  • Be transparent to users, and dial automatically when needed.

  • Be cost-effective, minimizing phone and support charges.

  • Support connection for rural customers via modem over a public switched telephone network (PSTN) connection, which limits capacity and requires time to establish a modem connection.

  • Control per-unit costs by offering a single-box solution because of the large number of sites.

  • Support addition of workstations.

The Challenge

Although Windows NT Server 4.0 met all of FoodCo's networking requirements, it had to be specially configured for a dial-on-demand network so that servers at branch offices would not unnecessarily activate the dial-on-demand link. The high cost of telecommunication was the most important factor influencing the design: it represented considerable risk in the early design stages and later influenced decisions such as domain design and the name resolution model.

Focusing on Windows NT Services

By studying, understanding, and minimizing the Windows NT operating system services that can cause a dial-on-demand event, you can determine and reduce telecommunication costs as highlighted in the "Custormer Profile" section. This chapter discusses common Windows NT Server services that can affect a dial-on-demand network over Transmission Control Protocol/Internet Protocol (TCP/IP). It briefly describes each service, explains how its configuration affects 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, the discussion does not include domain planning recommendations. It does, however, cite other sources of information (Microsoft Knowledge Base articles listed at the end of the chapter) and provide illustrative examples of network traces such as the example below:

Network trace example.

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 (unique address) of the network card that placed the frame onto the network. This appears in the table as a mnemonic name associated with the particular MAC address (which is always the same as the computername).

  4. Dst MAC Address. Destination MAC address to which the frame is sent. This appears in the table 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 Internet protocol (IP) addresses that computers use to communicate. A DHCP server leases IP addresses to any DHCP client. Windows NT DHCP clients request a lease renewal from a DHCP server at specific intervals: boot time, 50% of the lease duration (default 3 days), 87.5%, and 100% of the original lease duration until the original DHCP server responds.

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

A successful DHCP renewal request.

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)

If DHCP client systems are not powered-off each night, increasing the DHCP lease time reduces the amount and frequency of DHCP-related traffic. An office with 10 computers using the default three-day lease produces, on average, a dial-on-demand event every 3.6 hours.

To reduce the number of DHCP renewal requests:

  1. Set the DHCP lease period for a longer duration using the Windows NT Server DHCP administration utility, if there are IP addresses available for all computers. Increasing the renewal period lengthens the time to propagate DHCP configuration changes to all DHCP clients (because longer leases delay connection with the server).

  2. Implement a DHCP server on the local area network (LAN) segment, especially in environments where many clients shut down or regularly reboot. LAN-based DHCP servers require minimal maintenance after configuration and deployment.

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

    Note: For larger organizations, using static IP addresses is often undesirable because it can increase costs associated with manually allocating, managing, tracking, and troubleshooting many IP addresses. If software or configurations require static addresses, DHCP may not be an option.

Windows Internet Name Service (WINS) Client

Windows NT Server-based computers connect with one another over the network by obtaining IP addresses of destination computers. A 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 Registration\Renewal Requests and WINS Queries.

WINS Registration\Renewal Requests

Like 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 computers, when services stop or start, or when administrators promote a computer 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 computer. In the traces below and throughout this chapter, SERVER<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.

Common trace values and their significance.

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 computer.

Frame 16 - SERVER <00>.

Name refresh request for the workstation process for the computer.

WINS registration requests.

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 on the number and type of services running on a computer. For example, the PDC makes more WINS registrations than a member server or workstation. The four registrations shown in the trace above (frames 11, 13, 15, 17) are typical for a Windows NT Workstation or Windows NT Server that is a member of a domain.

To reduce WINS registration\renewal traffic:

  • 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 computers that are multi-homed or that use RAS, 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, Title: Windows NT 4.0 Clients May Refresh WINS Entries Frequently.

  • 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, you can update a single LMHOSTS file at each remote site as needed; the file distribution can 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 computers cannot locate them on the network without a static entry being created in some type of name resolution mechanism.

  • Install a local WINS server (small organizations only). This avoids transmissions of registrations across the wide area network (WAN).

    Note: This strategy is recommended only for small networks (2-10 offices). Installing a local WINS server means that WINS replication must be configured between the local WINS server and the headquarters location, which can generate a large amount of network traffic. Typically, Microsoft Technical Support recommends installing fewer, not more, WINS servers to simplify the WINs replication topology.

FoodCo's remote offices use WINS frequently, accessing a small percentage of resources at the headquarters. In turn, the corporate helpdesk and operations staff require WINS infrequently, but immediately, in supporting a large number of field computers. Because an organization needs access to all computers, 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 WINS-capable system attempts to locate a resource on the network, it generates a WINS querya fairly simple process. The workstation directs the WINS server to locate a given computer 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.

Successful WINS query (VENICE).

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.

Failed WINS query (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. It takes 4.5 seconds for this name lookup to fail, and it introduces broadcast traffic onto the network.

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, you can boost efficiency because there usually are local shared resources (such as file and print shares) and no local WINS server. You can 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 computers broadcast locally for name resolution before sending a directed query to a WINS server that invokes the dial-on-demand connection.

For details on how to configure name resolution order when DHCP is not used, see Knowledge Base article 139270, Title: How to Change Name Resolution Order on Windows 95 and Windows NT.

To reduce dial-on-demand traffic and maintain name resolution performance, you can reduce NetBIOS broadcast traffic (amount and timing) by making the following changes.

Reduce the time between successive NetBIOS broadcasts by changing this registry key.

Reduce the time between successive NetBIOS broadcasts.

Registry Path

HKEY_LOCAL_MACHINE \System \CurrentControlSet
Services\NetBT\Parameters

Parameter

BcastQueryTimeout

Type

REG_DWORD

Default Value

750 (milliseconds)

Suggested Value

250 (milliseconds)

Reduce the number of NetBIOS broadcasts before attempting p-node. To do so, change this registry key:

Reduce the number of NetBIOS broadcasts before p-node.

Registry Path

HKEY_LOCAL_MACHINE \System \CurrentControlSet
Services\NetBT\Parameters

Parameter

BcastNameQueryCount

Type

REG_DWORD

Default Value

3

Suggested Value

2

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

Depending on the connect time of the dial-on-demand link, you 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. For more information on how to implement this see Knowledge Base article 120642, Title: TCP/IP & NBT Configuration Parameters for Windows NT.

Windows NT Browser

The Windows NT Browser service provides administrators with an enterprise-wide view of available network resources. It establishes a hierarchy of computers 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 computers on the network.

Updating Browser Information

In a TCP/IP-based network, each segment (subnet) automatically elects one compuer to function as the master browser, with several other computers 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 the 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).

Reducing 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:

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 registry key below on all computers that serve as a master browser. For more information on browser services, see Knowledge Base article 102878, Title: Information on Browser Operation, and 134985, Title: Browsing & Other Traffic Incur High Costs over ISDN Routers.

Reduce a master browser's update frequency.

Registry Path

HKEY_LOCAL_MACHINE \System \CurrentControlSet
Services\Browser\Parameters

Parameter

MasterPeriodicity

Type

REG_DWORD

Default Value

720 (seconds)

Suggested Value

86400 (secondsdaily)

Note: Daily (86400 seconds) is only a suggestion. As with any other decision, you have to evaluate cost against need.

Disable the browser after business hours. You can easily stop and start browser service using the command prompt line NET STOP BROWSER. Use the Windows NT Scheduler to stop browser service after working hours.

Disable the browser completely. If a network doesn't require browser service, you can disable the service, which requires disabling the service on all computers 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 computername, and they will not be able to browse all domains.

Windows NT Server and Workstation Services

These services support the client and server connections between two Windows NT-based systems and, under normal conditions, run at all times.

Server Service

This networking service maintains incoming connections for a computer so that it can receive connections from other computers. It generates only low-level browser traffic that announces the presence of the server service on the network.

To tune a dial-on-demand network you can adjust the idle disconnect timeout value (how long a connection to the server can remain idle before disconnecting) by changing or adding the registry key below. For more information on this setting, see Knowledge Base article 138365, Title: How the Autodisconnect Works in Windows NT, and 105134, Title: AutoDisconnect Default Incorrect in Online Help.

Reduce the server idle disconnect time.

Registry Path

HKEY_LOCAL_MACHINE \System \CurrentControlSet
Services\LanManServer\Parameters

Parameter

AutoDisconnect

Type

REG_DWORD

Default Value

15 (minutes)

Suggested Value

2 (minutes)

Workstation Service

This service is the outgoing counterpart to the Server service. It allows a computer to connect to a remote server. It creates only low-level browser traffic that announces the presence of the workstation service on the network.

Also like the server service, the workstation service has an idle disconnect parameter. The following trace shows a named pipe connection between two computers for the transfer of browser information. Idle disconnect time was reduced to 60 seconds.

Workstation service traffic trace.

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)

Workstation service traffic trace. (continued)

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

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 reachedan additional 60 seconds. In Frame 15, approximately 60 seconds later, the workstation disconnects from the server.

To reduce the workstation idle disconnect time, add or change the registry key below. For more information on this setting, see Knowledge Base article 102981, Title: REG: Workstation Service Entries.

Reduce the workstation idle disconnect time.

Registry Path

HKEY_LOCAL_MACHINE \System \CurrentControlSet
Services\LanManWorkstation\Parameters

Parameter

KeepConn

Type

REG_DWORD

Default Value

600 (seconds)

Suggested Value

90 (seconds)

Make sure the idle disconnect parameters for server and workstation services fall within the auto-disconnect value configured on the dial-on-demand routers. Keep the server service AutoDisconnect time higher than the workstation server service, so that the workstation initiates disconnection.

Messenger Service

The messenger service receives network messages (such as print notification or administrative alerts) and displays them to the logged-in user through a popup dialog box. The messenger service is required to receive messages, not to send them.

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

Network activity at start of 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 for the machine name and the second for the logged-on user. A typical startup sequence shows only the machine registration entry when the messenger service starts; it shows the second WINS registration entry when a user logs on.

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

WINS/usernames released at log off.

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

This trace shows the network traffic resulting from a simple NET SEND command.

NET SEND command traffic.

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 (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. You can disable it. Even though the messenger service adds minimal network traffic, it has some drawbacks:

  • If a LAN has a local WINS server, user logon/logoff on a Windows NT-based computer 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 to send information about the user to a headquarters WINS server.

  • The messenger service makes two WINS registrations, one for the computer 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 available lines.

License Logging Service (LLS)

The LLS allows a LAN administrator to track the usage of Microsoft BackOffice licenses throughout the enterprise. It stores license usage information locally and periodically rolls it up to a central license-logging server, which by default is the PDC for the domain (although you can use the license manager application to specify a separate server). 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.

  • 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 computer.

LLS sending license information at start.

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

  • 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 information, it is affected by the workstation service idle disconnect timeout period. Refer to the "Windows NT Server and Workstation Services" section above.

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

License Logging Service Strategy

You can disable the LLS without adversely affecting Windows NT operation. If you want to use the service, configure the replication interval and start time to suit your needs. In a LAN environment the LLS replication usually occurs at night. In a dial-on-demand environment, you 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:00 a.m. and 6:00 a.m. for backups, perform LLS replication within that window.

Windows NT Spooler

Windows NT printing services access the network when connecting to printers, printing, and checking printer and job status. Usually client computers are close to their printers and do not generate WAN traffic.

The Windows NT Spooler can cause excess dialing when it distributes information on available printers. It 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 connection pattern is then repeated in Frames 98, 175 and 749 at 777-second intervals. Some frames have been omitted for clarity.

Windows NT spooler sending print browser information.

Frame

Time

Src MAC Address

Dst MAC Address

Protocol

Description

7

7.373

LONDON

GLASGOW

NBT

SS: Session Request, Dest: GLASGO, 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

Windows NT spooler sending print browser information. (continued)

Frame

Time

Src MAC Address

Dst MAC Address

Protocol

Description

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

Use REGEDIT.EXE to modify the default print browser parameter as shown in the table below. Disabling the thread reduces network traffic, but prevents the print servers knowing about other print shares on the network. For more information see Knowledge Base article 131902, Title: Printer Browse Thread May Cause Extensive Network Traffic.

Modify the default print browser parameter.

Registry Path

HKEY_LOCAL_MACHINE \System \CurrentControlSet
Control\Print

Parameter

DisableServerThread

Type

REG_DWORD

Default Value

0 (enabled)

Suggested Value

1 (disabled)

Windows NT Scheduler

Starting and stopping the Windows NT Scheduler service causes no traffic because by default the service runs under the LocalSystem account, which is part of the local security accounts manager (SAM) database and does not have access to the network. It can cause some traffic on startup, though: authentication (if it runs under a domain account) and copying its account to the local computer (if the account has a central profile). And it can create 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 computers 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 works well in a LAN environment it can severely tax a dial-on-demand connection.

The default interval for directory replication is five minutes. You can modify this interval using the registry information shown below, up to a maximum interval of 60 minutes.

Modify the Directory Replication interval.

Registry Path

HKEY_LOCAL_MACHINE \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, after which it contacts its partners and notifies them of an update. The replicator service on the export server still attempts 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 (Pulse x Interval) 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 the "Windows NT Server and Workstation Services" section above apply to directory replication.

Directory Replication Strategy

Because the Directory Replication service severely affects a dial-on-demand network, consider disabling the service. Some options:

  • 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 computers with local logon files, you 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, Title: Service Running as System Account Fails Accessing Network.) The Windows NT Scheduler service on the remote computers should now be able to access all of the files on that share.

  • Use the Microsoft Content Replication server.

  • Distribute LOGON files with routine business activities.

NETLOGON Service

This provides three primary functions within Windows NT domains:

  • On the PDC, it ensures that all BDCs regularly receive copies of all changes made to the domain SAM database.

  • On domain controllers, it authenticates domain logon requests against the local copy of the domain SAM database.

  • It supports pass-through authentication to other [Trusted] domains.

Only the first function affects dial-on-demand environments. By default the NETLOGON service sends an update pulse every five minutes to all BDCs. You can configure a number of parameters to reduce this activity. TechNet article "NETLOGON Service Entries" documents this configuration.

This next trace illustrates the sequence for providing NETLOGON updates between the PDC (LONDON) and a BDC (GLASGOW) within a domain that was synchronized to ensure that only one change was represented. The changed data is carried in Frame 7.

Sequence of NETLOGON updates showing one change.

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:

  • 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.

Sample environment for establishing a secure channel.

Account Domain USA

Resource Domain EUROPE

NEWYORK PDC

LONDON PDC

SEATTLE BDC

PARIS BDC

CHICAGO BDC

 

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

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 authenticates itself against the PDC (Frames 7-10) so that it can begin to receive SAM updates, 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 computer 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 (Frame 14) and it is used to process any pass-through authentication requests. (You can check the status of pass-through authentication by using 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.

Network trace of establishing a secure channel.

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

Network trace of establishing a secure channel. (continued)

Frame

Time

Src MAC Address

Dst MAC Address

Protocol

Description

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 a dial-on-demand event 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.

  • Changing Machine and Trust Relationship Passwords. When you configure a trust relationship for the first time you 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 its counterpart. The password is automatically changed every week as shown in the trace below. The actual passwords are set in Frames 24 and 26. Because this information is part of Local Security Authority (LSA) secrets, the domain immediately attempt to synchronize the SAM with all backup domain controllers.

Trust relationships password changed weekly.

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

Trust relationships password changed weekly. (continued)

Frame

Time

Src MAC Address

Dst MAC Address

Protocol

Description

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:

When a Windows NT Server or Workstation is a member of the domain there is a similar activity, but its traffic is one-way. The Windows NT-based computer receives a password that it can use in conjunction with its computer account to provide pass-through authentication to the domain NETLOGON services. This machine password changes weekly.

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

  • Disabling Machine Account Password Changes. In an organization with 3000 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 $78,000 (3000 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 registry key below. (For information on disabling machine account passwords, see Knowledge Base article 154501, Title: How to Disable Automatic Machine Account Password Changes.)

Disable machine account password change.

Registry Path

HKEY_LOCAL_MACHINE \System \CurrentControlSet
Service\NETLOGON\Parameters

Parameter

DisablePasswordChange

Type

REG_DWORD

Default Value

0 (enabled)

Suggested Value

1 (disabled)

  • Replicating LSA Secrets. One class of security information, LSA secrets, requires that the SAM be synchronized without waiting for the next NETLOGON pulse period. Even when you have correctly configured the NETLOGON parameters 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 cannot 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.

To reduce NETLOGON traffic:

  • Change the default parameters for NETLOGON replication.

  • Disable weekly machine account password changes.

    You cannot disable the NETLOGON service. The methods above work for domain designs with distributed or centralized BDCs.

Implementing Windows NT Dial-on-Demand Optimizations

During deployment, you can configure all Windows NT Server-based computers optimally for a dial-on-demand network. It is more challenging, however, to implement recommended changes to an existing network because computers may not follow a standard configuration. This section includes a Windows NT policy file you can use to configure Windows NT 4.0-based computers with a set of parameters.

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

Copy the policy file (DOD.ADM) to a local file system on a server and name it DOD.ADM.

Click here to download DOD.ADM to your computer

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 computers in the domain, guaranteeing that both existing and new computers 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 or resource kit.

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

When Windows NT-based computers are not members of a domain, you can still implement local policies but you have to make a one-time modification to every computer. To implement local policies, open the registry editor and edit or create the following registry values:

One-time modification for standalone computers (a).

Registry Path

HKEY_LOCAL_MACHINE \System \CurrentControlSet
Control\Update

Parameter

UpdateMode

Type

REG_DWORD

Value

2 (manual updates)

One-time modification to standalone computers (b).

 

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 multiple computers, export this registry key to a .REG file using REGEDIT.EXE. Then merge it on remote computers by using Windows NT Scheduler, Microsoft Systems Management Server, or some other method. Create the NTCONFIG.POL file and save it to a directory. Reboot each computer 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 makes changes to services that users started before the policies were applied.

Implementing Dial-on-Demand Policies using a REG File

If administrators prefer not to use System Polices in their environments, they can apply the template DOD.REG file (included on the sample CD in the DialOn folder) 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 chapter. The .REG file states values in hexadecimal, not decimal. You can use the Windows calculator to convert: on the View menu select Scientific.

More Information

KB Articles referenced in this chapter:

  • 164308, Title: Windows NT 4.0 Clients May Refresh WINS Entries Frequently

  • 139270, Title: How to Change Name Resolution Order on Windows 95 and Windows NT

  • 120642, Title: TCP/IP & NBT Configuration Parameters for Windows NT

  • 102878, Title: Information on Browser Operation

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

  • 138365, Title: How the Autodisconnect Works in Windows NT

  • 105134, Title: AutoDisconnect Default Incorrect in Online Help

  • 102981, Title: REG: Workstation Service Entries

  • 131902, Title: Printer Browse Thread May Cause Extensive Network Traffic

  • 124184, Title: Service Running as System Account Fails Accessing Network

  • 154501, Title: How to Disable Automatic Machine Account Password Changes

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft