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 https://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 |
Column definitions:
Frame. Unique number, starting from 1, assigned to each frame as the network monitor receives it.
Time. Elapsed time from the beginning of the trace until the frame was received.
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).
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.
Protocol. Highest-level protocol used within the frame.
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:
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).
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.
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
Parameter |
UpdateMode |
Type |
REG_DWORD |
Value |
2 (manual updates) |
One-time modification to standalone computers (b). |
|
Registry Path |
HKEY_LOCAL_MACHINE \System \CurrentControlSet |
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