Troubleshooting Directory Replicator Problems (104204)

If you experience problems during directory replication, the following list of troubleshooting steps may be helpful.

NOTE: Some steps only require that you note information for use in subsequent steps.

What operating system is running on the import computer? (Windows NT, Windows NT Advanced Server, OS/2, UNIX)
Is there anything interesting in the error log in the import computer? The applications log has entries for the replicator service and often contains useful information. Look at the logs on both the import and export computers.
What file systems are installed in the partitions pointed to by the import and export paths?
How many import computers exhibit this behavior?
What time zones are the import and export computers running in?
Make sure the import computer has Backup Operator permissions.

a. You must have at least change permissions for the IMPORT AND IMPORT\SCRIPTS directories.

b. The Backup Operaters Group must have at least "Backup Files and Directories" and "Restore Files and Directories" rights.

If these permissions are not set up, errors 5, 1300, and 1307 will show up in the event log. NOTE: With Windows NT 3.5 and 3.51, incorrect permissions result in error 3216, system error 2116.
Are the import and export computers in different domains? If so, are the password and user name the same in both domains? Do the domains trust each other?
Are alerts being received by administrative accounts? (Has the alerter service been started?)
Are there any extended attributes in the files or directories being replicated?
If the source directory is on an NTFS partition, are there any alternate data streams in the files or directories being replicated?
If the source or destination directories are on an NTFS partition, look at the access control lists (ACLs) on the import and export trees with File Manager. Does the Replicator local group have at least CHANGE privileges to these directories?
Is it possible that an account has a file open (on import or export) all the time? This would show up as a sharing violation in the event log (error 32).
Is there an REPL$ share on the export computer? (The share is created as a side effect of the Directory Replicating dialog box on the export computer. This dialog box also sets an ACL for the REPL$ share. Using the NET command or any other means to create the REPL$ share is likely to cause problems.)
If you run the NET START command on the export and import computers, do both computers show "Directory Replicator" (or equivalent) in the list?
If you are exporting or importing from an NTFS directory, does either tree have filenames that differ only in case? Which file gets replicated is not predictable. It is possible that the export computer will choose one file and the import computer will choose another. This results in the replication being out of sync.
If the export computer is running OS/2 or UNIX and the import computer is running Windows NT, is the export computer's local time within half of an hour of the import computer's time? If not, the Windows NT network redirector will "bias" the times. This can cause everything to be copied again and again. Replication may never occur.
Some versions of the OS/2 importer leave the archive bit set on all files imported, whether or not it was set on the export side. This too could result in continuous copying. One workaround is to set the archive bit on all files on the export computer. (Windows NT to Windows NT replication correctly clones the archive bit.)
Some LAN Manager 2.1a import computers do not set their status file to OK.RP$. The cause is currently unknown, but there are few side effects. Files will not be recopied each pass but a file comparison will occur. Except for the status file state, the files are correctly replicated. This behavior does not occur on LAN Manager 2.2 importers.
Some versions of LAN Manager for OS/2 and UNIX allow hard disk files with reserved names, such as LPT1 or COM1. This can cause problems and should be avoided. The Windows NT replicator currently lets these filenames exist.
There is a design limitation of OS/2 LAN Manager that you should be aware of if you are using it to replicate files. OS/2 LAN Manager only allows one set of credentials to be in use at a time. (The credentials consist of the user name and password.) If someone is interactively logged on to one user identification (ID) and the replicator is trying to use a different user ID, then the replicator runs into that limitation. Replication will be delayed until the interactive user logs off. On the other hand, if the interactive user and the replicator user have the same user ID, then replication is possible, depending on the value of the TryUser value in the LANMAN.INI file.
The OS/2 and UNIX LAN Manager importers are generally designed with a limit of 1000 files per directory. You should be aware that the "." and ".." directory entries use two of those 1000 entries. Also, some versions may have an off-by-one error that causes repeated file copies with exactly 1000 entries. This gives a practical limit of 997 files for those importers. The Windows NT importer does not have these limitations.
Are there some files being replicated from an HPFS partition (written by OS/2) to a Windows NT server? Do these files have extended attributes (EAs)? There may be problems with the EAs. OS/2 might have written the EAs in discontiguous parts of the disk; Windows NT does not support this. The directory replicator includes the EA sizes in its checksums, and they may be wrong in this case. The replication may stay out of sync permanently. You can use Windows NT to rewrite the same EA values to a single contiguous area, if you know the original EA values. Note that accessing an HPFS volume over the network while OS/2 is directly reading or writing the volume will work correctly.
If the computers are across a router, add their machine name to the Import or Export "To List" in Control Panel (choose Server and then choose Replication). This forces name resolution across the router and should synchronize the computers with the domain.