Replication in Windows NT

Synchronize your directory structures

The Windows NT replication process is a tool for keeping two directory structures synchronized, either on the same computer or across multiple computers. The replication process' main purpose is to ensure that the system copies logon scripts from a Primary Domain Controller (PDC) to the Backup Domain Controllers (BDCs). Regardless of which domain controller validates a user, every domain controller has the user's logon script.

You can use replication for other purposes, such as distributing read-only data (e.g., a corporate phone list, files containing information about company benefits) from a central server. However, replication isn't particularly beneficial for these tasks. Better techniques exist for distributing data.

NT replication seems simple, but it causes several problems. In this article I explain how replication works, when to use it, and how to set it up. I also discuss common problem areas and suggest ways to troubleshoot the replication process.

The Replication Process
Replication isn't a two-way process of directory synchronization. Instead, you need to make changes to master copies of files (typically on the PDC). You then make these files available for export so that a subscribing computer such as a BDC can import the files. When you make a change to a master file, the system replicates the file to the subscribing computers. If you add a file or delete a file from the master computer, the system adds the file or deletes it from the subscribing computers. Thus, if you add a new user account to the domain, the system replicates the user's logon script to the domain controllers within a few minutes.

If you examine how replication works, you'll see why the process works for logon scripts but isn't the best method for distributing other data. When you configure replication, you must specify an export directory. The default export directory is winntrootsystem32replexport, where winntroot is your NT directory. The replication process replicates only directories (not files) that you place below the export directory.

You can change the export directory. The directory is a hidden share called REPL$. When you change the export directory's path, the new path automatically accepts the REPL$ share. You don't see the REPL$ share right away, because it sets up when you install the replication service. The directory you specify as the export directory becomes the starting point for the replication process. You can't select various directories from different locations on your hard disks and have them replicate to the same locations on another server. Anything you want to export must be under the export directory. Thus, the replication process is inconvenient for general-purpose directory synchronization.

The import server has the same limitations that the export server has. The replication process imports replicated directories into the winntrootsystem32replimport directory. You can change this default, but you must place all replicated data under this import directory. The import directory isn't a share, but one of its subdirectories is the NETLOGON share. This share isn't hidden, and users connect to it when they log on to the domain. Changing the import directory is a bad idea, because users expect to find their logon scripts in the NETLOGON share.

When To Use Replication
Use replication for its intended purpose: keeping logon scripts synchronized between the PDC and the BDCs. Better technologies (e.g., an intranet) exist for distributing data such as the company phone list. Because replication is one-way, the import data must be read-only. The replication process overwrites changes on the import server the next time you change data on the master computer and replicate it to subscribers. Thus, replication isn't suitable for certain information (e.g., a sign-up list for the company softball team).

Some systems administrators try to use replication to copy users' data files from a file server to a backup server. However, they quickly discover that the replication process copies only directories that you place below the export (i.e., winntroot) directory. Putting all your user data on the same disk as your OS is a bad idea. You can change the export directory path, but then you must be careful how you handle logon scripts. The import server has similar limitations.

Replication isn't suitable for data backups. When the replication process synchronizes a directory, it doesn't look for the files that exist on the import server but not on the export server and delete those files. Replication deletes the whole directory, and rewrites it. Replication even deletes all the other directories below it in the tree, and rewrites them. Thus, one change can result in a lot of file copying. In the case of a large-scale backup of user files, the replicator would be constantly busy.

Configuring Replication
If you use logon scripts with multiple servers and you have one or more BDCs, you need to configure replication. In addition, replication is necessary for certain software packages. For example, Microsoft's Systems Management Server (SMS) requires that the client computers run a logon script to collect inventory and report an inventory summary to the logon server. In this case, you must configure replication even if you don't have BDCs. SMS generates logon scripts and places them in the export directory. You can then replicate the scripts from the export directory to the NETLOGON share. Even on the PDC, you must use the replication process to move scripts from the export directory to the import directory. Thus, when you generate a logon script, you need to place it in the export directory rather than the import directory. Doing so lets you verify that replication is working properly (at least locally). In addition, the next replication cycle won't accidentally overwrite your changes. If you build a file in the import directory and the file doesn't exist in the export directory, the synchronization process removes the file from the import directory at the first opportunity.

The replicator account. Replication is an NT service that runs in the background, regardless of whether anyone is logged on. Like all NT services, replication needs an account to use when it starts. In effect, the replication service logs on with the account and performs its functions in the account's security context. Most NT services can use the local system account, which gives them the privileges they need to run locally but provides no network rights. Replication must be able to communicate with other computers.

The first step in setting up replication is to add a user account to the domain for the service to use. You set up this account via User Manager for Domains. Systems administrators typically name the account something like REPL or Replica. (Replicator is already a group name, so you can't use it.)

The account needs an associated password. You'll want to make this password difficult to guess, because malicious users might try to break in through the account. Set the password to never expire, or replication will mysteriously stop someday.

The replicator account must be a member of the Replicator and Backup Operators groups. If you add the account to the Replicator group, NT automatically adds it to the Backup Operators group when you start the replication service.

Because the replication service logs on in the background, the account must have the Log on as a service right. In User Manager for Domains, select Policies, User Rights. Select Show Advanced User Rights. Then, scroll down to Log on as a service in the Right box, as Screen 1 shows. Click Add to add the replicator account. Configuring the Log on as a service right is optional. When you start the replication service, NT checks to see whether the replicator account has this right. If not, NT assigns the right.

Starting the replication service. You can configure start options for the replication service from Control Panel, Services. (Look for Directory Replicator.) However, I prefer to use Server Manager in the Administrative Tools folder. Select the export computer, and click Computer, Services. Scroll to the Directory Replicator service, and click Startup. Configure the service to start automatically, as Screen 2 shows. Then, specify the account to use (i.e., the replicator account that you set up). I find that clicking the ellipsis button to the right of the account box, searching for the account, and highlighting it works better than entering the account name. If you enter the account name, you must also provide the domain name, in the format DOMWESTReplicator. Finally, you must enter the password. You might think that selecting the account from the list automatically supplies the password. However, you must know the password and enter it at this stage. Then, click OK and exit the dialog box. Click Start to start the service.

You must configure the export and import servers to use the replicator account. If the servers are in the same domain, you can follow the same procedure for each computer. The account is already set up, so you just need to configure the replication service to start automatically with that account. If the import server is in another domain, configuration is trickier. You have two options: Make sure the trust relationships are established and use one account, or create an account with the same name and password in each domain. If you have administrative rights in both domains, you can connect to the import domain in Server Manager and User Manager for Domains on your computer. Then, you can configure replication remotely. If you don't have administrative rights in both domains, you must coordinate closely with the import domain's administrator.

Configuring the export server. You configure the export server for the replication process from Server Manager. Highlight the server and double-click it (or select Computer, Properties from the menu). The export computer must be an NT server, although NT workstations can be import servers. Next, click the Replication icon to open the replication dialog box, which Screen 3 shows. Select Export Directories. Use the default directory path and logon script path unless you have a reason to change them. Users will look for their logon scripts in the default NETLOGON share. Changing the logon script path in this dialog box doesn't change the NETLOGON share from winntrootsystem32replimportscripts, because this change would affect other services (e.g., the Net Logon service).

As a security measure, you can supply a list of domains or servers to which you want to export. The default is for this list to be blank and thus include all import computers in the local domain. If you enter a domain name in the To List box, you replace the default list. Thus, the export list no longer contains the local domain but contains only the domain you entered. You must specifically add the local domain.

Configuring the import server. You use the same procedure to configure the import server as you used to configure the export server. Select Import Directories. Again, use the default directory path.

In the From List box, add the name of the export domain from which you want to import (if you specified a domain during export server configuration). As previously, the default is all import servers in the local domain. If you enter a domain in the box, you override the default and must add the local domain. Make sure you replicate from the export to the import directories on the export server.

Microsoft recommends that when you're replicating over a WAN, you specify the computer names in export and import configurations. The domain names aren't specific enough.

Managing Replication
After you finish the configuration process, you can begin replicating data. Copy the directories you want to replicate to the export server. The logon scripts are probably already in place from when you added users. In Server Manager, select the export server, double-click it, and select Replication. Click Manage to bring up the replication list. You'll see the subdirectories that you're exporting, as Screen 4 shows. You can export the entire subtree or only the top-level directory below the export directory.

If you select Wait Until Stabilized, the replication process won't replicate a directory if you've made changes to it recently. You can configure this parameter from the Registry. Go to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesReplicatorParameters Registry key. Select GuardTime, and change the parameter as necessary. (The default is 2 minutes.) Many replication settings, including this parameter, appear in the Registry only after you set up the replication service.

You can place a lock on a directory so that the replication service can't replicate the directory while you're making changes to it (click Add Lock). A directory can have multiple locks. Suppose that another administrator places a lock on a directory. Then you go into the directory and edit some files. The other administrator removes the lock, but you're still making changes. Each administrator places one lock, then removes one lock when he completes his changes.

To manage import replication, open Server Manager, select the import server, double-click it, and select Replication. Click Manage to bring up the replication list. You'll see the data that you're importing, whether the subdirectory has a lock, the subdirectory's status, and the time of the last update, as Screen 5 shows. Locks are on the import side to prevent you from overwriting the data. If the status entry is missing, synchronization hasn't occurred. Check the accounts and permissions, and make sure the service is running. Try stopping and restarting the service. If the status entry is No Sync, synchronization has failed--­perhaps because of network problems, but more likely because of permissions problems. If you see No Master instead of a last update time, the subdirectory probably has a permissions problem.

Permissions
To understand the replication process' required permissions, you need to understand how replication works. The export server checks every few minutes for changes. You can configure this interval in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesReplicatorParameters Registry key. Select Interval, and change the parameter as necessary. When you make a change at the export server, it notifies the import servers. The import servers then copy the files from the export server. The import server pulls the files, rather than the export server pushing them. Thus, the replicator service account must have read permission on the export server and change permission on the import server. The account requires change permission (not just write permission) so that it can create new files on the import server. Ensure that the share permissions are correct on the export server and that NTFS file and directory permissions permit reads and writes. Incorrect permissions cause most replication problems.

Handle with Care
The NT replication process is a temperamental service that requires care in setup. Replication has limited capabilities and is most useful for keeping logon scripts synchronized between domain controllers. Replication performs adequately in this arena, and better tools exist for backing up or distributing data.