Optimizing Windows NT Server for a Dial-on-Demand Network
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
By Gary Milne, Microsoft Consulting Services
At A Glance
Key Point: Organizations that maintain a dial-on-demand network can optimize Microsoft Windows NT Server configuration to reduce the number of connections and thus reduce telecommunication costs.
Detail: High Task: Implementation, Troubleshooting
Article Section |
What's There |
---|---|
Introduction |
Configuration of Windows NT Server services affects dial-on-demand network traffic. |
Dynamic Host Configuration Protocol Server Renewal Requests |
Increasing the DHCP lease time decreases the amount and frequency of DHCP-related traffic. |
Windows Internet Name Service (WINS) Client |
Increasing the WINS renewal period is the simplest and most effective way to reduce renewal traffic |
Windows NT Browser |
Administrators can decrease browser update frequency. |
Windows NT Server and Workstation Services |
Adjust the registry settings to reduce the time before a server or workstation disconnects an idle session. |
Messenger Service |
Administrators can disable the messenger service for end-users. |
License Logging Service (LLS) |
Network administrators can disable the LLS. |
Windows NT Spooler |
Administrators can disable the Spooler that sends out print browser information. |
Windows NT Scheduler |
By default, Windows NT Scheduler does not create any network traffic. |
Directory Replication |
Three options in place of Directory Replication. |
NETLOGON Service |
Administrators should change the default settings, or disable weekly machine account password changes |
Implementing Windows NT Dial-on-Demand Optimizations |
A Systems Policy file (ADM) and REG file that administrators can use to configure Windows NT Server. |
Conclusion |
|
More Information |
Pointers to more information on TechNet and the Microsoft web. |
Introduction
Many businesses, for example insurance, real estate, travel firms, retail stores, and restaurants, often have a large number of geographically dispersed branch offices connected to a corporate office by telephone lines and routers. In an effort to contain connectivity costs, such businesses often elect not to maintain continuous network connections, but instead establish them as needed—an arrangement known as dial-on-demand connections.
The cost of ISDN or analog lines grows in proportion with their use. For example, 5000 remote sites of an insurance company use a single nightly dial-on-demand connection to the central office. At $0.10/minute, a five-minute auto-disconnect time for each site's router would still cost the company $912,000 dollars annually. By looking at the network demands of different Microsoft Windows NT operating system services, systems administrators can configure Windows NT Server to reduce the number of dial-on-demand events, and thus reduce telecommunications costs.
This paper discusses common Windows NT Server services that can affect a dial-on-demand network over TCP/IP. It provides a brief description of each service, demonstrates the impact of configuration on network traffic, describes strategies to improve the default behavior, and when appropriate, shows how to modify the registry. Although different domain models affect network traffic, this paper does not discuss specific domain planning recommendations.
Other sources of information (Microsoft Knowledge Base and TechNet articles) are cited. This article also provides examples of network traces to illustrate points conveyed in the text:
Frame |
Time |
Src MAC Address |
Dst MAC Address |
Protocol |
Description |
---|---|---|---|---|---|
9 |
57.947 |
SERVER |
PDC |
NBT |
NS: Refresh req. for TESTLAB <00> |
10 |
57.954 |
SERVER |
PDC |
ARP_RARP |
ARP: Reply, Target IP: 10.100.1.21 Target Hdwr Addr: 000083228675 |
Column definitions:
**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 of the network card that placed the frame onto the network. These appear in the tables as a mnemonic name associated with that particular MAC address (which is always the same as the computer name).
**Dst MAC Address—**Destination MAC address to which the frame is sent. These display in the tables as a mnemonic name associated with that particular MAC address.
**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 IP addresses that computers use to communicate with one another. A DHCP server "leases" IP addresses to any DHCP client. Windows NT DHCP clients request a lease renewal from a DHCP server at boot time, halfway through the default lease time of three days, and at 87.5% and 100% of the original lease interval if the original DHCP server is unavailable.
The following network trace shows the packets that arise from a successful DHCP renewal request. A single directed request followed by a single acknowledgement (ACK).
Frame |
Time |
Src MAC Address |
Dst MAC Address |
Protocol |
Description |
---|---|---|---|---|---|
1 |
2.307 |
LAPTOP |
LONDON |
DHCP |
Request (xid=7A074280) |
2 |
2.378 |
LONDON |
SERVER |
DHCP |
ACK (xid=7A074280) |
Increasing the DHCP lease time reduces the amount and frequency of DHCP-related traffic. An office with 10 machines using the default three-day lease produces, on average, a dial-on-demand event every 3.6 hours. The following strategies reduce the number of DHCP renewal requests:
Set DHCP lease period for a longer duration using the Windows NT Server DHCP administration utility, assuming that sufficient IP addresses are available for all machines. Increasing the renewal period lengthens the time to propagate DHCP configuration changes to all DHCP clients because longer leases delay connection with the server.
Implement a DHCP server on the local LAN segment, especially in an environment wherein a high number of clients shutdown or regularly reboot. LAN-based DHCP servers require minimal maintenance after configuration and deployment.
In small organizations, use static IP addresses to eliminate DHCP requests.
Note: For larger organizations, this could increase operational costs and is probably undesirable because of the costs associated with allocating, managing, tracking, and troubleshooting many IP addresses. However, some software or configurations may require static addresses and DHCP may not be an option.
Windows Internet Name Service (WINS) Client
Windows NT Server-based machines connect with one another over the network by obtaining IP addresses of destination computers. Windows NT Server's WINS client requests a computername and the WINS server returns its IP address. Two types of WINS traffic affect a dial-on-demand environment: WINS Queries and WINS Registration\Renewal Requests.
WINS Registration\Renewal Request
Like the DHCP clients, WINS clients must renew their registration with a WINS server. By default the WINS server sets the registration renewal period to four days. WINS clients automatically renew registrations at various intervals: halfway through this set period, when users reboot machines, when services stop or start, or when administrators promote a machine from backup domain controller (BDC) to primary domain controller (PDC).
A WINS registration number has 16 digits: the first 15 identify the computername, and the last indicates a particular type of service running on a machine. In the traces below and throughout this article, SERVERNAME<XX> refers to a server and its registration number as a two digit hexadecimal value. Common values and their significance are listed in the table below.
Frame 9 - TESTLAB <00>. |
Name refresh request for the domain name. |
Frame 12 - SERVER. |
Name refresh request for the SERVER process, equivalent to SERVER <20>. |
Frame 14 - SERVER <03>. |
Name refresh request for the messenger service for the machine. |
Frame 16 - SERVER <00>. |
Name refresh request for the workstation process for the machine. |
Frame |
Time |
Src MAC Address |
Dst MAC Address |
Protocol |
Description |
---|---|---|---|---|---|
9 |
57.947 |
SERVER |
PDC |
NBT |
NS: Refresh req. for TESTLAB <00> |
10 |
57.954 |
SERVER |
PDC |
ARP_RARP |
ARP: Reply, Target IP: 10.100.1.21 Target Hdwr Addr: 000083228675 |
11 |
57.954 |
PDC |
SERVER |
NBT |
NS: Registration (Node Status) resp. for TESTLAB <00>, Success, Owner Addr. 10.100.1.23 |
12 |
57.955 |
SERVER |
PDC |
NBT |
NS: Refresh req. for SERVER |
13 |
57.977 |
PDC |
SERVER |
NBT |
NS: Registration (Node Status) resp. for SERVER, Success, Owner Addr. 10.100.1.23 |
14 |
57.978 |
SERVER |
PDC |
NBT |
NS: Refresh req. for SERVER <03> |
15 |
58.003 |
PDC |
SERVER |
NBT |
NS: Registration (Node Status) resp. for SERVER <03>, Success, Owner Addr. 10.100.1.23 |
16 |
58.003 |
SERVER |
PDC |
NBT |
NS: Refresh req. for SERVER <00> |
17 |
58.043 |
PDC |
SERVER |
NBT |
NS: Registration (Node Status) resp. for SERVER <00>, Success, Owner Addr. 10.100.1.23 |
The number and type of registrations vary based upon the number and type of services running on a machine. For example, the PDC and the makes more WINS registrations than a member server or workstation. The four registrations shown in the above example are typical for a Windows NT Workstation or Windows NT Server that is a member of a domain.
Strategies to Reduce WINS Registration\Renewal Traffic
To reduce WINS registration and renewal traffic over a dial-on-demand connection, consider these strategies:
Increase the WINS renewal period—This is the simplest and most effective way to reduce WINS renewal traffic and still provide WINS services.
Note: Windows NT Server 4.0-based machines with Remote Access Service (RAS) or that are multi-homed refresh their names with a WINS server every ten minutes, instead of using the time-to-live (TTL) value returned by the WINS server. For more information on how to correct this behavior see Knowledge Base article 164308.
Avoid using WINS at remote sites—Use broadcast name resolution to find local resources and an LMHOSTS file to locate remote resources. By using the LMHOSTS #INCLUDE syntax, an administrator updates a single LMHOSTS file at each remote site as needed. The distribution of this file can also be scheduled to piggyback on other business activities.
Warning: In this scenario the Windows NT-based workstations at the remote site do not register with any WINS server, and other machines cannot locate them on the network without a static entry being created in some kind of name resolution mechanism.
Install a local WINS server (small organizations only)—This avoids transmissions of registrations across the WAN.
Note: Having a large number of WINS servers is not a recommended strategy. If you have a small number of offices (2-10) then this strategy is practical.
Remote offices use WINS frequently, accessing a small percentage of resources at the corporate location. In turn, the corporate helpdesk and operations staff require WINS infrequently but immediately in supporting a large number of field machines. Because an organization needs access to all machines, it cannot eliminate WINS completely, especially when using DHCP. For most branch office environments, the best option is simply to increase the WINS renewal period.
WINS Queries
Whenever a Windows NT-based workstation attempts to locate a resource on the network, it generates a WINS query, a fairly simple process. The workstation directs the WINS server to locate a given machine or resource name, and the server responds by returning the IP address corresponding to the requested name. The following sequence shows a successful lookup on the name VENICE. The lookup query results in two packets on the local network: one request and one response.
Frame |
Time |
Src MAC Address |
Dst MAC Address |
Protocol |
Description |
---|---|---|---|---|---|
2 |
2.549 |
GARYMIL_PC |
GLASGOW |
NBT |
NS: Query req. for VENICE <00> |
3 |
2.552 |
GLASGOW |
GARYMIL_PC |
NBT |
NS: Query (Node Status) resp. for VENICE <00>, Success |
This next trace shows a failed WINS query on the name SICILY.
Frame |
Time |
Src MAC Address |
Dst MAC Address |
Protocol |
Description |
---|---|---|---|---|---|
1 |
2.446 |
GARYMIL_PC |
GLASGOW |
NBT |
NS: Query req. for SICILY <00> |
2 |
2.45 |
GLASGOW |
GARYMIL_PC |
NBT |
NS: Query (Node Status) resp. for SICILY <00>, Requested |
3 |
3.94 |
GARYMIL_PC |
LONDON |
NBT |
NS: Query req. for SICILY <00> |
4 |
3.948 |
LONDON |
GARYMIL_PC |
NBT |
NS: Query (Node Status) resp. for SICILY <00>, Requested |
5 |
5.442 |
GARYMIL_PC |
*BROADCAST |
NBT |
NS: Query req. for SICILY <00> |
6 |
6.193 |
GARYMIL_PC |
*BROADCAST |
NBT |
NS: Query req. for SICILY <00> |
7 |
6.945 |
GARYMIL_PC |
*BROADCAST |
NBT |
NS: Query req. for SICILY <00> |
Notice that the workstation contacts both WINS servers in turn in an attempt to resolve the name. This is followed by three broadcasts onto the local network segment at 0.75-second intervals. The total time that it takes for this name lookup to fail is 4.5 seconds.
Strategies to Reduce WINS Queries
As shown in the successful query above, WINS provides an effective and efficient method for name resolution. In most cases, attempting to modify default behavior yields no benefit because a WINS lookup precedes a network connection attempt.
In small branch offices, however, it is possible to make some efficient changes. Small offices usually have local shared resources (such as file and print shares) and no local WINS server. It is possible to save money in this situation by using the DHCP Administrator to specify a scope or global option of type 046, "WINS/NBT Node Type," an M-node (0x4) model. This ensures that machines broadcast locally for name resolution before sending a directed query to a WINS server that invokes the dial-on-demand connection. See Knowledge Base article 139270 for details on how to configure name resolution order when DHCP is not used.
To maintain name resolution performance while reducing dial-on-demand traffic, consider reducing the number and timing of the NetBIOS broadcast traffic by making the following changes.
1. To reduce the amount of time between successive NetBIOS broadcasts change the following registry key.
Registry Path |
HKLM\System\CurrentControlSet\Services\NetNT\Parameters |
Parameter |
BcastQueryTimeout |
Type |
REG_DWORD |
Default Value |
750 (milliseconds) |
Suggested Value |
250 (milliseconds) |
2. To reduce the number of NetBIOS broadcasts before attempting P-node change the following registry key.
Registry Path |
HKLM\System\CurrentControlSet\Services\NetNT\Parameters |
Parameter |
BcastNameQueryCount |
Type |
REG_DWORD |
Default Value |
3 |
Suggested Value |
2 |
Using the default parameters to locate a remote resource would result in a 2.25-second delay before a name query is sent to the WINS server. Using the suggested values reduces this to 0.5 seconds.
Depending upon the connect time of the dial-on-demand link, administrators can increase the timeout and retry values for the WINS server lookup, which defaults to 1.5 seconds and three retries and can timeout before the dial-on-demand connection completes. See Knowledge Base article 120642 for more information on how to implement this.
Windows NT Browser
The Windows NT Browser service provides administrators with an enterprise-wide view of available network resources. The browser service establishes a hierarchy of machines starting with the PDC as domain master browser followed by a distribution of master and backup browsers throughout the network. These browser services regularly pass data that provides a list of available domains and machines on the network.
Updating Browser Information
In a TCP/IP–based network, each segment (subnet) automatically elects one machine to function as the master browser, with several other machines operating as backup browsers. By default, each master browser attempts to contact the domain master browser every twelve minutes using a remote procedure call (RPC) over a named pipe to request a new browser list. If the domain master browser recognizes that the master browser is connecting from a remote subnet (a subnet other than one to which the domain master browser is directly connected) it will in turn establish a named pipe connection to the calling master browser, request its browse list, and use that information to update its own master browse list. Because the browser uses named pipes to establish a connection and pass information, the default workstation idle timeout period applies (see the "Windows NT Server and Workstation Services" section below for more information).
Strategies to Reduce Browser Traffic
Establishing a connection every twelve minutes, 365 days per year is a very expensive proposition for any dial-on-demand environment. Fortunately, there are several ways to reduce the impact of the Windows NT browser service:
1. Reduce browser update frequency—Change the default of 720 seconds to a more reasonable number for a dial-on-demand network. To reduce the frequency at which the master browser attempts to connect to the domain master browser change the following registry key on all machines that serve as a master browser. For more information on browser services, see Knowledge Base articles 102878 and 134985.
Registry Path |
HKLM\System\CurrentControlSet\Services\Browser\Parameters |
Parameter |
MasterPeriodicity |
Type |
REG_DWORD |
Default Value |
720 (seconds) |
Suggested Value |
86400 (seconds) – i.e. Daily. |
Note: This value of 86400 seconds is a suggestion. Systems administrators must evaluate the cost of this dial-on-demand connection for their organizations.
2. Disable the browser after business hours—Administrators can easily stop and start browser service using the command prompt line NET STOP BROWSER, and stop browser service after working hours with the Windows NT Scheduler.
3. Disable the browser completely—If a network doesn't require browser service, administrators can disable the service, which requires disabling the service on all machines in a subnet.
Warning: Programs such as Server Manager that provide a "Select Computer" menu option do so by using the browse list. If the browser service is disabled, users must type in a computer name and they cannot browse all domains.
Windows NT Server and Workstation Services
These services support the client and server connections between two Windows NT-based systems. Both of these services exist on Windows NT Workstation and Server and under normal conditions run at all times.
Server Service
This networking service maintains incoming connections to a machine. Without it, a machine can not receive connections from other machines. The server service generates only low level browser traffic that announces the presence of the server service on the network. The most important element of this service for a dial-on-demand network is the idle disconnect timeout value that specifies how long a connection to the server can remain idle before disconnecting. To reduce the time before an idle session disconnects from the server, administrators can change or add the following registry key. See Knowledge Base articles 138365 and 105134 for more information on this setting.
Registry Path |
HKLM\System\CurrentControlSet\Services\LanManServer\Parameters |
Parameter |
AutoDisconnect |
Type |
REG_DWORD |
Default Value |
15 (minutes) |
Suggested Value |
2 (minutes) |
Workstation Service
This service parallels the Server service described in the section above. Without it, a machine cannot connect to a remote server. The workstation service creates only low level browser traffic that announces the presence of the workstation service on the network.
Like the server service, the workstation service also controls an idle disconnect parameter. The following trace shows a named pipe connection between two machines for the transfer of browser information. In this trace the workstation idle disconnect time was reduced to 60 seconds.
Frame |
Time |
Src MAC Address |
Dst MAC Address |
Protocol |
Description |
---|---|---|---|---|---|
1 |
6.553 |
GLASGOW |
LONDON |
TCP |
....S., len: 4, seq: 9483601-9483604, ack: 0, win: 8 |
2 |
6.554 |
LONDON |
GLASGOW |
TCP |
.A..S., len: 4, seq: 9537563-9537566, ack: 9483602, win: 8 |
3 |
6.555 |
GLASGOW |
LONDON |
TCP |
.A...., len: 0, seq: 9483602-9483602, ack: 9537564, win: 8 |
4 |
6.556 |
GLASGOW |
LONDON |
NBT |
SS: Session Request, Dest: LONDON , Source: GLASGOW |
5 |
6.558 |
LONDON |
GLASGOW |
NBT |
SS: Positive Session Response, Len: 0 |
6 |
6.56 |
GLASGOW |
LONDON |
SMB |
C negotiate, Dialect = NT LM 0.12 |
7 |
6.563 |
LONDON |
GLASGOW |
SMB |
R negotiate, Dialect # = 7 |
8 |
6.567 |
GLASGOW |
LONDON |
SMB |
C session setup & X, Username = , and C tree connect & X, Share = |
9 |
6.584 |
LONDON |
GLASGOW |
SMB |
R session setup & X, and R tree connect & X, Type = IPC |
10 |
6.588 |
GLASGOW |
LONDON |
SMB |
C transact, Remote API |
11 |
6.609 |
LONDON |
GLASGOW |
SMB |
R transact, Remote API (response to Frame 10) |
12 |
6.616 |
GLASGOW |
LONDON |
SMB |
C transact, Remote API |
13 |
6.632 |
LONDON |
GLASGOW |
SMB |
R transact, Remote API (response to Frame 12) |
14 |
6.75 |
GLASGOW |
LONDON |
TCP |
.A...., len: 0, seq: 9484272-9484272, ack: 9538051, win: 8 |
15 |
67.615 |
GLASGOW |
LONDON |
SMB |
C tree disconnect |
16 |
67.621 |
LONDON |
GLASGOW |
SMB |
R tree disconnect |
17 |
67.622 |
GLASGOW |
LONDON |
SMB |
C logoff & X |
18 |
67.624 |
LONDON |
GLASGOW |
SMB |
R logoff & X |
19 |
67.625 |
GLASGOW |
LONDON |
TCP |
.A...F, len: 0, seq: 9484354-9484354, ack: 9538133, win: 8 |
20 |
67.627 |
LONDON |
GLASGOW |
TCP |
.A...F, len: 0, seq: 9538133-9538133, ack: 9484355, win: 8 |
21 |
67.628 |
GLASGOW |
LONDON |
TCP |
.A...., len: 0, seq: 9484355-9484355, ack: 9538134, win: 8 |
Frame 8 shows the named pipe connection being initiated; data transfer is finished by Frame 13. Notice however that the connection remains intact until the idle disconnect timeout is reached—an additional 60 seconds. In Frame 15, approximately 60 seconds later, the workstation initiates a disconnect from the server.
To reduce the time before a workstation disconnects an idle session, add or change the following registry key. See Knowledge Base article 102981 for more information on this setting.
Registry Path |
HKLM\System\CurrentControlSet\Services\LanManServer\Parameters |
Parameter |
KeepConn |
Type |
REG_DWORD |
Default Value |
600 (seconds) |
Suggested Value |
90 (seconds) |
Administrators should make sure that the idle disconnect parameters for both the server and workstation services fall within the auto-disconnect value configured on the dial-on-demand routers. The AutoDisconnect time for the server service should remain higher than that for the workstation service so that the workstation initiates the disconnect process.
Messenger Service
The messenger service receives network messages and displays them to the logged in user through a popup dialog box, for example print notification or administrative alerts. The messenger service is not required in order to send messages, only to receive them.
The following trace demonstrates network activity when starting the Windows NT messenger service.
Frame |
Time |
Src MAC Address |
Dst MAC Address |
Protocol |
Description |
---|---|---|---|---|---|
16 |
3.223 |
SERVER |
PDC |
NBT |
NS: Registration req. for SERVER <03> |
17 |
3.231 |
PDC |
SERVER |
NBT |
NS: Registration (Node Status) resp. for SERVER <03>, Success |
18 |
3.484 |
SERVER |
PDC |
NBT |
NS: Registration req. for GARYMIL <03> |
19 |
3.489 |
PDC |
SERVER |
NBT |
NS: Registration (Node Status) resp. for GARYMIL <03>, Success |
The messenger service makes two "<03>" type WINS registrations, the first one for the machine name and the second for the logged on user. A typical startup sequence shows only the entry for the machine registration when the messenger service starts, and the second WINS registration entry when a user logs on.
Whenever users shut down machines, messenger service stops, and the machine releases its WINS name (Frame17 below). When users log off machines, WINS releases usernames (Frame 18).
Frame |
Time |
Src MAC Address |
Dst MAC Address |
Protocol |
Description |
---|---|---|---|---|---|
17 |
4.071 |
SERVER |
PDC |
NBT |
NS: Release req. for WS001048 <03> |
18 |
4.072 |
SERVER |
PDC |
NBT |
NS: Release req. for HXGJM0 <03> |
19 |
4.074 |
PDC |
SERVER |
NBT |
NS: Release (Node Status) resp. for WS001048 <03>, Success |
20 |
4.076 |
PDC |
SERVER |
NBT |
NS: Release (Node Status) resp. for HXGJM0 <03>, Success |
Sending Messages via the Messenger Service
The following trace shows the network traffic that results from a simple NET SEND command.
Frame |
Time |
Src MAC Address |
Dst MAC Address |
Protocol |
Description |
---|---|---|---|---|---|
4 |
1.953 |
SERVER |
PDC |
NBT |
NS: Query req. for EINSTEIN <03> |
5 |
1.964 |
PDC |
SERVER |
NBT |
NS: Query (Node Status) resp. for EINSTEIN <03>, Success |
6 |
1.965 |
SERVER |
*BROADCAST |
ARP_RARP |
ARP: Request, Target IP: 10.169.105.34 |
7 |
1.966 |
WKS01 |
SERVER |
ARP_RARP |
ARP: Reply, Target IP: 10.169.105.20 Target Hdwr Addr: 0000832B8A77 |
8 |
1.966 |
SERVER |
WKS01 |
TCP |
....S., len: 4, seq: 511560177, ack: 0, win: 8192, src: 1590 dst: 139 |
9 |
1.967 |
WKS01 |
SERVER |
TCP |
.A..S., len: 4, seq: 4010727, ack: 511560178, win:16064, src: 139 dst: 159 |
10 |
1.968 |
SERVER |
WKS01 |
TCP |
.A...., len: 0, seq: 511560178, ack: 4010728, win:16064, src: 1590 dst: 139 |
11 |
1.968 |
SERVER |
WKS01 |
NBT |
SS: Session Request, Dest: EINSTEIN <03>, Source: SERVER <01>, Len: 68 |
12 |
1.969 |
WKS01 |
SERVER |
NBT |
SS: Positive Session Response, Len: 0 |
13 |
1.97 |
SERVER |
WKS01 |
SMB |
C send message, from SERVER to EINSTEIN |
14 |
2.085 |
WKS01 |
SERVER |
TCP |
.A...., len: 0, seq: 4010732, ack: 511560339, win:15903, src: 139 … |
15 |
2.112 |
WKS01 |
SERVER |
SMB |
C send message, reply |
16 |
2.113 |
SERVER |
WKS01 |
TCP |
.A...F, len: 0, seq: 511560339, ack: 4010771, win:16021, src: 1590 dst: 139 |
17 |
2.114 |
WKS01 |
SERVER |
TCP |
.A...F, len: 0, seq: 4010771, ack: 511560340, win:15903, src: 139 dst: 159 |
18 |
2.115 |
SERVER |
WKS01 |
TCP |
.A...., len: 0, seq: 511560340, ack: 4010772, win:16021, src: 1590 dst: 139 |
It begins with a name query and response in Frames 4 and 5. After receiving the target address the server performs a Reverse Address Resolution Protocol (RARP) to retrieve the MAC address for the destination node. A TCP/IP session is established in Frames 8-10. A NetBIOS session is established in Frames 11 and 12. Finally in Frame 13, a workstation sends a message and the server returns a success code (Frame 15).
Messenger Service Strategy
With the exception of receiving print notifications and system alerts, the messenger service provides little benefit to end-users. Administrators can disable it. The messenger service adds minimal network traffic, but has some drawbacks:
If a LAN has a local WINS server, user logon/logoff a Windows NT-based machine with messenger service creates minimal network traffic with WINS registration. If the LAN does not have a local WINS server and a local BDC validates user accounts, the messenger service unnecessarily uses the router.
The messenger service makes two WINS registrations, one for the machine and one for the user. A network that replicates WINS information across a large number of remote sites effectively doubles the amount of the WINS data that it transfers.
Use of the NET SEND "Message" /DOMAIN:NAME command can tax the dial-on-demand connection very quickly by tying up all of the available lines.
License Logging Service (LLS)
The LLS allows a LAN administrator to track the usage of Microsoft BackOffice licenses throughout the enterprise. If the LLS is enabled, it will store license usage information locally and periodically roll it up to a central license-logging server. By default the central license-logging server is the PDC for the domain although a separate server can be specified using the license manager application. The LLS is present only on Windows NT-based servers.
License Logging Service Traffic
The LLS creates three types of network traffic identified in the following traces.
1. At service start time, the LLS sends its license information to the PDC as shown in the example below, it queries for the domain name (Frames 3-4) and then queries the NETLOGON service for the PDC name. If the LLS reports to an enterprise server, a WINS query resolves the name of that particular machine.
Frame |
Time |
Src MAC Address |
Dst MAC Address |
Protocol |
Description |
---|---|---|---|---|---|
2 |
3.54 |
SERVER |
*BROADCAST |
ARP_RARP |
ARP: Request, Target IP: 10.100.1.21 |
3 |
3.54 |
PDC |
SERVER |
ARP_RARP |
ARP: Reply, Target IP: 10.100.1.23 Target Hdwr Addr: 0000F6181D73 |
4 |
3.541 |
SERVER |
PDC |
NBT |
SERVER NS: Query req. for TESTLAB <1B> |
5 |
3.548 |
PDC |
SERVER |
NBT |
PDC NS: Query (Node Status) resp. for TESTLAB <1B>, Success |
6 |
3.561 |
SERVER |
PDC |
NETLOGON |
SERVER Query for Primary DC |
7 |
3.564 |
PDC |
SERVER |
NETLOGON |
PDC Response to Primary Query |
2. If the Windows NT Server cannot communicate with the central LLS, it attempts to reconnect every 15 minutes. If an enterprise server regularly receives license information, the server must be available at all times.
Note: Because the LLS uses a redirector connection to pass LLS information, the workstation service idle disconnect timeout period applies to the use of this service. Refer to the "Windows NT Server and Workstation Services" section above for more information.
3. The LLS replicates license information to the PDC or enterprise server every 24 hours by default. With the License Manager administrators can configure this interval (from 1-72 hours) and the start time. By default Windows NT Server automatically staggers submission of license information to the PDC to avoid overloading the server.
License Logging Service Strategy
Network administrators can disable the LLS, and not adversely affect the operation of Windows NT in any way. If the network uses the service, administrators should configure the replication interval and start time according to specific needs. In a LAN environment the LLS replication usually occurs at night. In a dial-on-demand environment, administrators should configure this time to maximize a connection that has already been established. For example, if there is dial-on-demand connection every night between 4:00AM and 6:00 AM for backups, LLS replication can occur during that window.
Windows NT Spooler
There are several conditions under which Windows NT printing services access the network: connecting to printers, printing, and checking printer and job status. Usually client machines are close to their printers and do not generate WAN traffic.
The Windows NT Spooler can cause excess dialing in the process of distributing information on available printers throughout the enterprise. Windows NT Spooler sends out print browser information every 777 seconds as shown in the trace below. Frame 13 shows the initial connection to the SPOOLSS named pipe on the remote server. This same connection pattern is then repeated in Frames 98, 175 and 749 at 777-second intervals. Some frames have been omitted for clarity.
Frame |
Time |
Src MAC Address |
Dst MAC Address |
Protocol |
Description |
---|---|---|---|---|---|
7 |
7.373 |
LONDON |
GLASGOW |
NBT |
SS: Session Request, Dest: GLASGOW , Source: LONDON |
8 |
7.373 |
GLASGOW |
LONDON |
NBT |
SS: Positive Session Response, Len: 0 |
9 |
7.377 |
LONDON |
GLASGOW |
SMB |
C negotiate, Dialect = NT LM 0.12 |
10 |
7.378 |
GLASGOW |
LONDON |
SMB |
R negotiate, Dialect # = 7 |
11 |
7.401 |
LONDON |
GLASGOW |
SMB |
C session setup & X, Username = , and C tree connect & X, Share = |
12 |
7.406 |
GLASGOW |
LONDON |
SMB |
R session setup & X, and R tree connect & X, Type = IPC |
13 |
7.411 |
LONDON |
GLASGOW |
SMB |
C NT create & X, File = \spoolss |
14 |
7.418 |
GLASGOW |
LONDON |
SMB |
R NT create & X, FID = 0x801 |
15 |
7.422 |
LONDON |
GLASGOW |
MSRPC |
c/o RPC Bind: UUID 12345678-1234-ABCD-EF00-0123456789AB |
16 |
7.428 |
GLASGOW |
LONDON |
MSRPC |
c/o RPC Bind Ack: call 0x44005C assoc grp 0x394C7A xmit 0x1 |
17 |
7.432 |
LONDON |
GLASGOW |
R_WINSPOO |
Error: Bad Opcode (Function does not exist) |
18 |
7.438 |
GLASGOW |
LONDON |
R_WINSPOO |
Error: Bad Opcode (Function does not exist) |
19 |
7.441 |
LONDON |
GLASGOW |
SMB |
C close file, FID = 0x801 |
20 |
7.445 |
GLASGOW |
LONDON |
SMB |
R close file |
98 |
784.562 |
GLASGOW |
LONDON |
SMB |
C NT create & X, File = \spoolss |
175 |
1807.79 |
LONDON |
GLASGOW |
SMB |
C NT create & X, File = \spoolss |
749 |
2584.88 |
GLASGOW |
LONDON |
SMB |
C NT create & X, File = \spoolss |
Network administrators should modify the default print browser parameter described in the table below to the suggested value using REGEDIT.EXE. Disabling the thread reduces network traffic, but prevents the print servers knowing about other print shares on the network. See Knowledge Base article 131902 for more information.
Registry Path |
HKLM\System\CurrentControlSet\Control\Print |
Parameter |
DisableServerThread |
Type |
REG_DWORD |
Default Value |
0 (enabled) |
Suggested Value |
1 (disabled) |
Windows NT Scheduler
By default the Windows NT Scheduler service runs under the "LocalSystem" account on a Windows NT machine. This account is part of the local security accounts manager (SAM) database and does not have access to the network. Under these conditions stopping and starting the Windows NT Scheduler does not create any network traffic. However, if the scheduler runs under a domain account, authentication takes place when the service starts, and if the scheduler account has a central profile, it is copied to the local machine. The scheduler causes network traffic when a scheduled job uses network facilities for WINS lookups, file copying, and so forth.
Directory Replication
The Directory Replication service synchronizes a directory structure between machines in the domain, primarily the NETLOGON shares between the PDC and all BDCs. The NETLOGON share typically contains all of the scripts associated with the logon process. Although this Directory Replication works well in a LAN environment it can severely tax a dial-on-demand connection.
The default interval for directory replication is five minutes. Administrators can modify this interval using the registry information shown below. However, the Directory Replication service accepts a maximum interval of 60 minutes.
Registry Path |
HKLM\System\CurrentControlSet\Replicator\Parameters\Interval |
Parameter |
Interval |
Type |
REG_DWORD |
Default Value |
5 (minutes) Range 1-60 |
Suggested Value |
60 (minutes) |
This interval controls the frequency at which the export computer checks its export file system for changes. The export computer then contacts its partners and notifies them of an update. The replicator service on the export server will still attempt to communicate with the replicator service on the import server even if there are no changes in the file system just to ensure that it is still available. Import computers then contact the export server and copy any directories in which changes are found. If the export server fails to contact the import server within a defined period (Interval x Pulse) then the import server initiates communication.
Replication Characteristics
When the Directory Replication service detects a change in the file system, it replicates all of the contents for the directory, including any sub-directories. When there are many files or change is frequent, replication can be time consuming. The Directory Replication service uses the redirector to establish a connection and transfer the files. The idle disconnect parameters described in "Windows NT Server and Workstation Services" section above apply to directory replication.
Directory Replication Strategy
Because Directory Replication service severely impacts a dial-on-demand network, network administrators should consider disabling the service and using one of the following options:
Use the Windows NT Scheduler service to run a batch job on a regular basis that copies any changed files. The Windows NT Server Resource Kit ROBOCOPY.EXE utility provides the ability to synchronize source and destination directories by copying only differences. This method does have some implications.
The Windows NT Scheduler account must run under a domain account. In a network with standalone domains, without trusts or individual Windows NT-based machines with local logon files, administrators should use the LocalSystem account for the replicator service. Configure a Null Session Share on the servers hosting the master copy of the logon scripts and give everyone READ access to the share. (See Knowledge Base article 124184.) The Windows NT Scheduler service on the remote machines should now be able to access all of the files on that share.
Use the Microsoft Content Replication server.
Distribute LOGON files with routine business activities.
NETLOGON Service
The NETLOGON service provides three primary functions within Windows NT domains:
On the PDC, the NETLOGON service ensures that all of the BDCs regularly receive copies of all changes made to the domain SAM database.
On domain controllers, the NETLOGON service authenticates domain logon requests against the local copy of the domain SAM database.
The NETLOGON service supports pass-through authentication to other domains.
Of these functions, the first affects dial-on-demand environments. By default the NETLOGON service sends an update pulse every five minutes to all BDCs. A systems administrator can configure a number of parameters to reduce this NETLOGON activity. TechNet Article "B.4.7 NETLOGON Service Entries" documents this configuration.
The following trace illustrates the sequence for providing NETLOGON updates between the PDC (LONDON) and BDC (GLASGOW) within a domain. The domain had been previously synchronized to ensure that only a single change is represented. The changed data is carried in Frame 7.
Frame |
Time |
Src MAC Address |
Dst MAC Address |
Protocol |
Description |
---|---|---|---|---|---|
1 |
157.360 |
LONDON |
GLASGOW |
NETLOGON |
Announce Change to UAS or SAM |
2 |
158.036 |
GLASGOW |
LONDON |
SMB |
C NT create & X, File = \NETLOGON |
3 |
158.073 |
LONDON |
GLASGOW |
SMB |
R NT create & X, FID = 0x800a |
4 |
158.076 |
GLASGOW |
LONDON |
MSRPC |
c/o RPC Bind: UUID 12345678-1234-ABCD-EF00-01234567CFFB |
5 |
158.092 |
LONDON |
GLASGOW |
MSRPC |
c/o RPC Bind Ack: call 0x0 assoc grp 0x8159 xmit 0x1630 re |
6 |
158.095 |
GLASGOW |
LONDON |
R_LOGON |
RPC Client call logon:NetrDatabaseDeltas(..) |
7 |
158.165 |
LONDON |
GLASGOW |
R_LOGON |
RPC Server response logon:NetrDatabaseDeltas(..) |
8 |
158.288 |
GLASGOW |
LONDON |
TCP |
.A...., len: 0, seq: 876161-876161, ack: 1823715, win: 87 |
Other NETLOGON Traffic
In addition to the NETLOGON functions listed above, other functions can affect a dial-on-demand environment:
1. Establishing a Secure Channel to other Domains—When a NETLOGON Service starts on a domain controller it immediately attempts to contact a domain controller in each of the trusted domains. The communication establishes a secure channel that allows pass-through authentication to the SAM database with the trusted domains.
In the domain environment represented in the trace below, the resource domain trusts the account domain, therefore the domain controllers (DCs) in the resource domain must establish a secure channel to a DC in the account domain.
Account Domain – USA |
Resource Domain – EUROPE |
---|---|
NEWYORK – PDC |
LONDON – PDC |
SEATTLE – BDC |
PARIS – BDC |
CHICAGO – BDC |
|
When the NETLOGON service on the PARIS BDC. starts, it locates the PDC for its own domain and establishes a connection to the NETLOGON named pipe. PARIS then authenticates itself against the PDC (Frames 7-10) so that it can begin to receive SAM updates. PARIS then attempts to locate a domain controller in the trusted domain USA by sending out SAM LOGON requests in Frames 11-13. On a system reboot the machine would typically use WINS to obtain a list of DCs in the trusted domain. The first DC from the account domain to respond is CHICAGO in Frame 14. This machine will be used to process any pass-through authentication requests. (To check the status of pass-through authentication use the Windows NT Resource Kit utility DOMMON.EXE.) The BDC then synchronizes the SAM with the PDC by requesting any outstanding changes in Frames 15-18.
Frame |
Time |
Src MAC Address |
Dst MAC Address |
Protocol |
Description |
---|---|---|---|---|---|
1 |
9.276 |
PARIS |
LONDON |
NETLOGON |
Query for Primary DC |
2 |
9.278 |
LONDON |
PARIS |
NETLOGON |
Response to Primary Query |
3 |
9.29 |
PARIS |
LONDON |
SMB |
C NT create & X, File = \NETLOGON |
4 |
9.292 |
LONDON |
PARIS |
SMB |
R NT create & X, FID = 0x5001 |
5 |
9.292 |
PARIS |
LONDON |
MSRPC |
c/o RPC Bind: UUID 12345678-1234-ABCD … |
6 |
9.293 |
LONDON |
PARIS |
MSRPC |
c/o RPC Bind Ack: call 0x1 assoc grp 0x9B50 xmit 0 |
7 |
9.294 |
PARIS |
LONDON |
R_LOGON |
RPC Client call logon:NetrServerReqChallenge(..) |
8 |
9.295 |
LONDON |
PARIS |
R_LOGON |
RPC Server response logon:NetrServerReqChallenge(..) |
9 |
9.296 |
PARIS |
LONDON |
R_LOGON |
RPC Client call logon:NetrServerAuthenticate2(..) |
10 |
9.301 |
LONDON |
PARIS |
R_LOGON |
RPC Server response logon:NetrServerAuthenticate2(..) |
11 |
9.303 |
PARIS |
*BROADCAST |
NETLOGON |
SAM LOGON request from client |
12 |
9.303 |
PARIS |
NEWYORK |
NETLOGON |
SAM LOGON request from client |
13 |
9.304 |
PARIS |
NEWYORK |
NETLOGON |
SAM LOGON request from client |
14 |
9.305 |
CHICAGO |
PARIS |
NETLOGON |
SAM Response to SAM LOGON request |
15 |
9.33 |
PARIS |
LONDON |
R_LOGON |
RPC Client call logon:NetrDatabaseDeltas(..) |
16 |
9.332 |
LONDON |
PARIS |
R_LOGON |
RPC Server response logon:NetrDatabaseDeltas(..) |
17 |
9.333 |
PARIS |
LONDON |
R_LOGON |
RPC Client call logon:NetrDatabaseDeltas(..) |
18 |
9.334 |
LONDON |
PARIS |
R_LOGON |
RPC Server response logon:NetrDatabaseDeltas(..) |
19 |
9.334 |
SEATTLE |
PARIS |
NETLOGON |
SAM Response to SAM LOGON request |
20 |
9.336 |
PARIS |
LONDON |
R_LOGON |
RPC Client call logon:NetrDatabaseDeltas(..) |
21 |
9.337 |
LONDON |
PARIS |
R_LOGON |
RPC Server response logon:NetrDatabaseDeltas(..) |
In most cases this sequence poses no problem, but stopping and starting DCs or the NETLOGON service initiates in a dial-on-demand event in order to establish a secure channel to a trusted domain. In some domain designs this behavior could result in numerous dial-on-demand events occurring for every DC that is restarted.
2. NETLOGON Service—Changing Machine and Trust Relationship Passwords—When administrators configure a trust relationship for the first time, they enter an initial password on both sides to enable the domains to communicate securely. Once established, each PDC establishes a secret account and password with their counterpart. On a weekly basis this password is changed automatically as shown in the trace below. The actual passwords are set in Frames 24 and 26 respectively. Because this information is part of Local Security Authority (LSA) secrets the domain immediately attempt to synchronize the SAM with all backup domain controllers.
Frame |
Time |
Src MAC Address |
Dst MAC Address |
Protocol |
Description |
---|---|---|---|---|---|
1 |
33.634 |
LONDON |
*BROADCAST |
NBT |
NS: Query req. for NEWYORK |
2 |
33.639 |
NEWYORK |
*BROADCAST |
ARP_RARP |
ARP: Request, Target IP: 89.0.0.3 |
3 |
33.640 |
LONDON |
NEWYORK |
ARP_RARP |
ARP: Reply, Target IP: 89.0.0.2 Target Hdwr Addr: 0080C7E2168A |
4 |
33.640 |
NEWYORK |
LONDON |
NBT |
NS: Query (Node Status) resp. for NEWYORK, Success |
5 |
33.642 |
LONDON |
NEWYORK |
TCP |
....S., len: 4, seq: 604893393-604893396, ack: 0, win: |
6 |
33.643 |
NEWYORK |
LONDON |
TCP |
.A..S., len: 4, seq: 391927223-391927226, ack: 604893394, win: |
7 |
33.645 |
LONDON |
NEWYORK |
TCP |
.A...., len: 0, seq: 604893394-604893394, ack: 391927224, win: |
8 |
33.645 |
LONDON |
NEWYORK |
NBT |
SS: Session Request, Dest: NEWYORK , Source: LONDON |
9 |
33.646 |
NEWYORK |
LONDON |
NBT |
SS: Positive Session Response, Len: 0 |
10 |
33.656 |
LONDON |
NEWYORK |
SMB |
C negotiate, Dialect = NT LM 0.12 |
11 |
33.658 |
NEWYORK |
LONDON |
SMB |
R negotiate, Dialect # = 7 |
12 |
33.717 |
LONDON |
NEWYORK |
SMB |
C session setup & X, Username = , and C tree connect & X, Share = |
13 |
33.721 |
NEWYORK |
LONDON |
SMB |
R session setup & X, and R tree connect & X, Type = IPC |
14 |
33.734 |
LONDON |
NEWYORK |
SMB |
C NT create & X, File = \NETLOGON |
15 |
33.742 |
NEWYORK |
LONDON |
SMB |
R NT create & X, FID = 0x800 |
16 |
33.755 |
LONDON |
NEWYORK |
MSRPC |
c/o RPC Bind: UUID 12345678-1234-ABCD-EF00-01234567CFFB |
17 |
33.762 |
NEWYORK |
LONDON |
MSRPC |
c/o RPC Bind Ack: call 0x3 assoc grp 0xE6F8 xmit 0x1630 re |
18 |
33.809 |
LONDON |
NEWYORK |
R_LOGON |
RPC Client call logon:NetrServerReqChallenge(..) |
19 |
33.815 |
NEWYORK |
LONDON |
R_LOGON |
RPC Server response logon:NetrServerReqChallenge(..) |
20 |
33.850 |
LONDON |
NEWYORK |
R_LOGON |
RPC Client call logon:NetrServerAuthenticate2(..) |
21 |
34.009 |
NEWYORK |
LONDON |
TCP |
.A...., len: 0, seq: 391927786-391927786, ack: 604894484, win: |
22 |
34.124 |
NEWYORK |
LONDON |
R_LOGON |
RPC Server response logon:NetrServerAuthenticate2(..) |
23 |
34.291 |
LONDON |
NEWYORK |
TCP |
.A...., len: 0, seq: 604894484-604894484, ack: 391927886, win: |
24 |
34.650 |
LONDON |
NEWYORK |
R_LOGON |
RPC Client call logon:NetrServerPasswordSet(..) |
25 |
34.811 |
NEWYORK |
LONDON |
TCP |
.A...., len: 0, seq: 391927886-391927886, ack: 604894712, win: |
26 |
34.886 |
NEWYORK |
LONDON |
R_LOGON |
RPC Server response logon:NetrServerPasswordSet(..) |
27 |
34.992 |
LONDON |
NEWYORK |
TCP |
.A...., len: 0, seq: 604894712-604894712, ack: 391927986, win: |
In the case of a Windows NT Server or Workstation that is a member of the domain there is an activity to that described above but only in a single direction. The Windows NT-based machine will receive a password that it can use in conjunction with its machine account to provide pass-through authentication to the domain NETLOGON services. Like the trust password the machine password also gets changed on a weekly basis.
Note: In Windows NT Server domains all changes to the SAM, including machine account information, occur at the PDC.
3. Disabling Machine Account Password Changes—In an organization with 5000 copies of Windows NT Workstation installed into a large dial-on-demand network the annual cost of this type of traffic alone could be as high as $130,000 (5000 nodes x 52 weeks x 5 minutes per call x $0.10 per minute). To disable the machine account password change on a Windows NT Workstation or Server, edit the following registry key. (Refer to Knowledge Base article 154501 for more information on disabling machine account passwords.)
Registry Path |
HKLM\System\CurrentControlSet\Service\NETLOGON\Parameters |
Parameter |
DisablePasswordChange |
Type |
REG_DWORD |
Default Value |
0 (enabled) |
Suggested Value |
1 (disabled) |
4. Replicating LSA Secrets—One class of security information, LSA secrets, requires that the SAM be synchronized without waiting for the next NETLOGON pulse period. Although administrators have correctly configured the NETLOGON parameters of "ChangeLogSize" and "Pulse," LSA Secrets replication can increase NETLOGON traffic with:
Addition of machine accounts to the domain (but not deletion).
Changes in machine account passwords.
Changes in account policies.
Changes in trust relationships including trust password changes.
The synchronization of LSA Secrets uses the same transmission mechanism as all other NETLOGON data except that it happens immediately instead of being deferred until the next NETLOGON pulse. Although administrators can not alter the behavior of LSA Secrets replication, simple measures such as creating machine accounts in batch mode instead of sporadically throughout the day can reduce unwanted connections.
Strategies for Reducing NETLOGON Traffic
The NETLOGON service, unlike some other Windows NT Server services, cannot be disabled. Whether the domain design has a BDC at each remote location or BDCs located centrally, here are two ways to reduce traffic: Change the default parameters for NETLOGON replication.
Disable weekly machine account password changes.
Implementing Windows NT Dial-on-Demand Optimizations
Administrators can configure all Windows NT Server-based machines optimally for a dial-on-demand network during a deployment. However, administrators face a greater challenge implementing the recommended changes to an existing network because machines may not follow a standard configuration. This section includes a Windows NT policy file that allows administrators to configure Windows NT 4.0-based machines with a set of parameters.
Implementing Dial-on-Demand Policies in an Windows NT 4.0 Domain
Save the embedded policy file (DOD.ADM) below to a local filesystem on a server and name it DOD.ADM. Start the Windows NT Policy Editor and select Options-Policy Template, and add the DOD.ADM file. Make the selections that you require and save the file as NTCONFIG.POL. Windows NT Server adds this new policy and automatically applies it to all machines in the domain, guaranteeing that both existing and new machines are optimized with the appropriate dial-on-demand policies. For information on the use and deployment of system policies see the Window NT Server 4.0 documentation.
Implementing Dial-on-Demand Policies on Standalone Windows NT 4.0 Workstations or Servers
In an environment where Windows NT-based machines are not members of a domain, administrators can still implement local policies. However, this requires a one-time modification to every machine. To implement local policies open the registry editor and edit or create the following registry values.
Registry Path |
HKEY_LOCAL_MACHINE \System \CurrentControlSet \Control \Update |
Parameter |
UpdateMode |
Type |
REG_DWORD |
Value |
2 (manual updates) |
Registry Path |
HKEY_LOCAL_MACHINE \System \CurrentControlSet \Control \Update |
Parameter |
NetworkPath |
Type |
REG_SZ |
Value |
C:\WINNT\POLICY\NTCONFIG.POL (example only) |
To implement this registry or editing step on a large number of machines, export this registry key to a .REG file using REGEDIT.EXE. Then merge this key on remote machines by using Windows NT Scheduler, Microsoft Systems Management Server, or some other method. Create the NTCONFIG.POL file and save to a directory. Reboot each machine twice to make sure policies have installed completely. The first reboot applies the policy and changes the registry to reflect the new value. The second reboot makes changes to services that users started prior to applying the policies.
Implementing Dial-on-Demand Policies using a REG File
If administrators prefer not use System Polices in their environments, they can apply the template .REG file (included below) with Windows NT Scheduler or other software distribution tools. To perform a silent installation of a .REG file, use REGEDIT /S DOD.REG. The settings in the .REG file are the same as the suggested values found throughout this paper. The .REG file states values in hexadecimal, not decimal. The Windows calculator provides a conversion equation.
This sample file is only available from the TechNet CD product.
Conclusion
The Windows NT Server default parameters operate effectively over a permanently connected network. Applying them to a dial-on-demand network will likely result in unnecessarily high telecommunications costs and the need for excessive peak capacity. IT professionals should consider these recommendations in the context of their own environment, and the potential impact on the usability and maintenance of the network.
More Information
On TechNet:
Presents detailed information that is specific mainly to using Windows NT Server on or with a network. |
|
Details how to use the Registry editors, with an emphasis on protecting the Registry contents. |
On the Microsoft Web:
Windows NT Server Product Page |
Microsoft TechNet
November 1997
Volume 5, Issue 11