| 
| 
Troubleshooting Directory Replicator Problems
ID: Q104204
 
 |  The information in this article applies to:
 
 
Microsoft Windows NT operating system version 3.1
Microsoft Windows NT Advanced Server version 3.1
Microsoft Windows NT Workstation versions  3.5, 3.51, 4.0
Microsoft Windows NT Server versions  3.5, 3.51, 4.0
 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.
 
 Additional query words: 
prodnt  
Keywords          : kbnetwork ntdomain NTSrvWkst Version           : 3.1 3.5 3.51 4.0
 Platform          : winnt
 Issue type        :
 |