© Copyright Brian Brown, 1996-1999. All rights reserved.
This material may not be reproduced in printed or electronic format without the express permission of the author.

DOMAIN SYNCHRONIZATION AND REPLICATION
In this section, we shall look at how Windows NT Domains provide synchronization of the Domain accounts database across the domain controllers, and the use of the replication service to replicate important data and log on scripts across domain controllers.

In the previous section, it was discovered that log on scripts are executed only on the domain controller processing the log on request. If the log on script resides on a server other than the server validating the log on request, it is not executed.

The replication service provides a mechanism for copying these log on scripts [and other directories and files] to each backup domain controller in the network.

Periodically, the NT Server PDC synchronizes the domain account database to each BDC in the network. It sends only the changes to each BDC (this limits traffic). Synchronization is necessary in order to keep the domain accounts database consistent across the domain, remembering of course, that BDC’s can validate log on requests by users.

If any change is made to the domain accounts database [like adding or modifying a user] it will take a finite time for the BDC’s in the domain to be updated with the altered account information. If the user attempts to log on during this time before the changes are replicated, and this request is validated by a BDC, then the user will not be granted the correct rights or privileges because the BDC is using an outdated domain accounts database.

The registry entry which controls the frequency of the automatic synchronization for the domain accounts database is

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\Pulse

and is set to 300 seconds (5 minutes) by default. If you change the value of this parameter, you must restart the netlogon service for the changes to take effect.

Domain Synchronization across a WAN link
Windows NT Server provides a number of configurable parameters which control how the domain accounts database is to be replicated. These parameters are useful if you are replicating across a slow WAN link.

With the introduction of NT Server v3.5, the parameter

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\ReplicationGovernor

(which as a range of 0-100, with a default of 100), defines the percentage in both size of the data transferred and the frequency of the data transfer. When set to 100, a default of 128Kbytes is used; when set to 50, a buffer size of 64Kbytes is used and the BDC will have an outstanding synchronization only 50% of the time.

Setting the value too low will increase the time duration between synchronization. This parameter is set on each BDC [the PDC and BDC must be running NT 3.5 or greater].

Reducing the size of the parameter increases the time between calls, and reduces the buffer size used during each call. This essentially frees up the WAN link for use by other services, preventing the synchronization from consuming the entire WAN bandwidth.

For larger networks, it is desirable to install the BDC on site where the PDC is located. This installs the domain accounts database onto the BDC. The BDC is then shipped to the destination site, and connected back into the network. This ensures that the entire domain accounts database is not transferred across the WAN link when the BDC is installed.

A typical scenario of using BDC’s is as follows, where a company has a number of branch offices located geographically, each connected via low speed WAN links. The PDC is located in head office, and each regional site is equipped with a BDC. This ensures that domain log on requests are processed locally, and not sent across the WAN link for validation. Providing a BDC at each regional office ensures users can still log on to the domain even if the WAN link or PDC goes down.

DIRECTORY REPLICATION
In Windows NT Server, the special share REPL$ exists for directory replication. This is mapped to

\<winnt_root>\system32\repl\import

by default. Files to be exported to other computers [Domain Controllers, NT Servers or Windows NT Workstation] are exported from the directory

\<winnt_root>\system32\repl\export

This has special permissions already assigned, and administrators should place exported data and files under this share point. Remember that domain log on scripts reside under the import directory, so if you want these to be replicated to BDC’s within the domain, the log on scripts should be copied to the export directory.

Replication is recommended where only one copy of the file needs to be maintained, and where the data [usually log on scripts or mandatory profiles] need to be available on each domain controller in the network that validates log on requests. It is also handy for such this as phone lists and address books.

A file that is deleted under the export directory will not be deleted on the imported computers.

The export computer provides the files and directories which will be replicated to other computers. These must be Windows NT Server computers.

The import computers receive the replicated files and store this information under the REPL$ share point. These can be Windows NT Domain Controllers, Windows NT Servers, or Windows NT Workstation based computers.

Preparing the Export Computer
To provide replication, an account must be configured on the export server which will be used to replicate the required data. This account must have special properties, as outlined below. The basic steps involved are,

1. Create a user account which will be used to perform replication
   - all logon hours allowed
   - the account is a member of the domain Backup Operators and Replicator groups
   - the password never expires option is selected
   - the user must change password at next logon is NOT selected
   
2. Configure the directory replicator service to start automatically and log on as the user account
3. Place the required directories and files in the path
   \<winnt_root>\system32\repl\export
4. Use server manager to specify the files to be exported to the other import computers

If the export directory resides on an NTFS partition, the REPLICATOR GROUP on the export server should be given FULL CONTROL to the exported directory tree.

Preparing the Import Computer
Replication can occur to computers in either the local domain, or a trusting domain. If the computer is not in the export computers domain or a trusting domain, create a replication user, which has permissions to access the export computers REPL$ share.

If the import computer is in the export servers domain, or a trusting domain, then use the domain account created earlier for replication.

1. Make the replicator user account a member of the local replicator group
2. Configure the directory replicator service to start automatically and to log on as the user account
3. Use server manager to specify the export computer and files to be received

Specifying What to Export on The Export Computer
Use Server Manager to specify

1. the export path [directories which will be exported]
2. which directories are locked [applying a lock stops the directory from being exported]
3. whether files should remain unchanged for 2 minutes before being exported [stabilized]
4. whether the entire subdirectory tree should be exported
5. a list of the import computers

In the diagram below, the Administrator has selected the PDC as the export computer, to bring up the properties associated with the export computer. The replication tab controls how replication is handled by this computer.

When the administrator clicks on the replication tab, the Directory Replication dialog box appears. In the diagram below, the administrator has clicked on the Manage button to specify the directories to be exported or locked.

Managing Replication on The Import Computer
Server Manager is used to specify the replication information on the import computer in a similar manner to that done on the export computer [except the roles are reversed]. The administrator can specify

1. the import path [the path where the imported directories which will be stored]
2. which directories are imported [applying a lock stops the directory from being imported]
3. a list of the import computers

In addition, the status of any replication or replicated directories is available, showing when the last replication occurred and whether it is up to date. This status information is handy for troubleshooting replication problems.