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).
If you need to manually copy folders, ensure that you fully
understand the implications of this action, or perform this task
under the advice of your Microsoft Product Support provider.
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:
Examine the event logs on the computers involved. The most
common causes of replication failure are logged in the File
Replication Service event log.
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
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.
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.
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.
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
By default, the following files and folders are excluded from
File names starting with a tilde (~) character.
Files with .bak or .tmp extensions.
Regardless of the filters you set, FRS always excludes the
following from replication:
NTFS mounted drives.
Files encrypted by using EFS.
Any reparse points except those associated with DFS namespaces.
If a file has a reparse point used for Hierarchical Storage
Management (HSM) or Single Instance Store (SIS), FRS replicates the
underlying file but not the reparse point.
Files on which the temporary attribute has been set.
Check whether the file on the originating server is locked on
the target computer. See Sharing
Violations for details on this process.
As a last resort you might try a service restart on either the
upstream and/or the downstream partner.