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 \winntroot\system32\repl\export, 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 \winntroot\system32\repl\import 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.