Files Not Replicating

Files can fail to replicate for a wide range of underlying reasons: DNS problems, firewalls, topology problems, insufficient disk space, the FRS service being stopped, FRS servers in an error state, or sharing violations. When troubleshooting this problem, focus on how to enable FRS to run again. Do not start replicating data using some additional, out-of-band mechanism, such as manual copying of files. If replication stops for some reason, the very worst thing you can do is to copy files manually to replication partners — this will cause additional replication traffic, backlog, and possible replication conflicts (see Morphed Folders for more details).

Important

The correct course of action is to find the root cause. Common causes for files not replicating include lack of disk space for data or staging, poor connectivity, critical FRS objects/attributes missing in Active Directory, or files and directories that are in use and cannot be replaced.

A general procedure for troubleshooting FRS when files appear to not be replicating between any two direct replication partners A and B consists of the following steps:

  1. Examine the event logs on the computers involved. The most common causes of replication failure are logged in the File Replication Service event log.
  2. Verify that both Computer A and Computer B are available on the network. Because FRS uses the fully qualified domain name (FQDN) of the replica members, a good first check is to use a ping command specifying the fully qualified name of the problem replicas. From the console of Computer A, send a ping command with Computer B’s FQDN. Then, from the console of Computer B, send a ping command to Computer A’s FQDN. Verify that the addresses returned by the ping command are the same as the addresses returned by an ipconfig /all command carried out on the command line of the destination computer.
  3. Verify remote procedure call (RPC) connectivity between Computer A and Computer B. A good method to do this to execute the command-line command NTFRSUTL VERSION FQDN_of_other_computer from both servers.
  4. Use the Active Directory Sites and Services snap-in to verify the replication schedule on the connection object, and to confirm that replication is enabled between the computers.
  5. Check for files that are larger than the amount of free space on the source or destination server, larger than free space on the staging directory volume, or the size of the staging directory limit in the registry. Resolve the disk space problem or increase the maximum staging file space. See Staging Directory is Full and Huge File Added to Replica Tree for more details.
  6. Check whether the source file was excluded from replication by FRS file and folder filters (search for "filter" in the Ntfrs_ds.txt file generated by FRSDiag or in Ultrasound see the Replica sets view in the Advanced tab under General.) Confirm that the file is not EFS encrypted, a reparse point, marked as temporary or excluded by a file or folder filter on the originating replica member (see article 296944, "HOW TO: Use File Replication Service File and Folder Filters in Windows 2000" at http://support.microsoft.com/?id=296944 and article 229928, "Design Decisions, Defaults and Behavior for FRS File and Folder Filters in DFS and SYSVOL Replica Sets" at http://support.microsoft.com/?id=229928.) If any of these conditions are true, FRS does not replicate the file or directory.

    By default, the following files and folders are excluded from FRS replication:

    Regardless of the filters you set, FRS always excludes the following from replication:

  7. Check whether the file on the originating server is locked on the target computer. See Sharing Violations for details on this process.
  8. As a last resort you might try a service restart on either the upstream and/or the downstream partner.