The File Replication Service (FRS) is a fairly simple service. Fortunately, there are several
items you can check to narrow your search for the cause of a problem

Verify Connectivity and the Service:

FRS uses fully qualified domain names (FQDNs), not IP addresses, to contact replication
partners. Start troubleshooting problems by confirming that you can use the ping utility to
contact each replication partner from the console of each domain controller. If you can’t, the
domain controller might have a DNS configuration problem, DNS might be set up wrong, DNS
might be down, or basic network connectivity might be affected. Troubleshoot these problems,
and FRS will likely resume working.

You’ll also need to verify that FRS is started. It should be configured to start automatically on all
domain controllers; if such isn’t the case, modify the service configuration appropriately and try
starting the service. If it won’t start, check the FRS event log for error messages.
Finally, verify that the remote procedure call (RPC) protocol can connect between domain
controllers. This problem is rare unless domain controllers are separated by firewalls or port-
filtering routers. The FRS event log on domain controllers will log event ID 13508 if the RPC
service is unable to connect to its replication partners or if it’s unable to create a secure RPC
connection. Perform a network packet capture to see where the RPC traffic is going astray,
particularly if there are port-filtering devices between the affected domain controllers.

Verify Active Directory:

Use the Microsoft Management Console (MMC) AD Sites & Services console to verify the
replication schedule on the connection objects between any affected domain controllers. Ensure
that replication is enabled; if Active Directory (AD) replication isn’t working, FRS won’t work
either.

Connection objects should be automatically created between domain controllers in each site by
the Knowledge Consistency Checker (KCC). If necessary, you can create manual connection
objects, but in general, you want to get the KCC working properly—it provides the best way of
keeping your replication topology working correctly

Test FRS:

The simplest way to test FRS is to create a file and see whether the file replicates. Place the file
under one domain controller’s SYSVOL hierarchy, and check to see whether the file shows up
on other domain controllers. You should also be able to delete the file and see it disappear on
other domain controllers. Don’t delete or mess with any of the files already under SYSVOL—
you can break AD in some fairly subtle and difficult-to-repair ways by manually removing
Group Policy Objects (GPOs), scripts, and other files

File and Disk Problems:

Ensure that both the source and destination computers have sufficient free space on their system
volumes for two copies of each file being replicated. Remember that FRS creates a temporary
copy of the file when sending and receiving; space must exist to make that possible.

Two events in the FRS event log can alert you to other disk space problems. Event ID 13511
indicates that the FRS database is out of space; either free up space on the system volume or
move the FRS database. Event ID 13522 indicates that the staging folder used for temporary files
is full. If the system volume should have enough space, then it’s possible that the domain
controller has not been able to replicate files for some time and it has built up a large number of
files in the staging area while attempting to replicate them. Delete the connection objects from
the affected domain controller, then stop and restart FRS. Doing so should delete the temp files
and allow you to troubleshoot the basic connectivity issue.

FRS cannot replicate encrypted files. Windows will never apply Encrypting File System (EFS) to any
SYSVOL files on its own, but it’s possible that another administrator may have done so. Doing so will
break FRS until the files are decrypted

FRS Utility:

Windows includes a diagnostic tool, Ntfrsutl.exe, which can help troubleshoot FRS problems.
The syntax for this tool is:
•  Ntfrsutl memory and Ntfrsutl threads—Lists the memory or threads being utilized by
FRS. Optionally, include a remote computer name (Ntfrsutl memory server1) to get
statistics for another computer.
•  Ntfrsutl ds—Shows the FRS view of the directory service. Optionally, include a remote
computer name to get the view from another computer’s FRS.
•  Ntfrsutl poll—Lists the current polling interval for FRS. Optionally, include a remote
computer name (Ntfrs poll server1) to see another computer’s polling interval.
•  Ntfrsutl poll /quickly—Repeatedly polls partners in rapid succession until all partners are
in sync. You can include a remote computer name to force this process on another
domain controller.
•  Ntfrsutl poll /now—Forces an immediate one-time poll. You can include a remote
computer name to force it to poll.

Log Files:

In addition to its event log, FRS can produce a detailed debugging log to help pinpoint troubles.
To change the log configuration, stop FRS, and open a registry editor. Browse to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters, and
modify the following values:

•  Debug Log Severity—Set this value to zero to record only the most severe events to the
log; set this value to 5 to record almost every event that FRS can generate.
•  Debug Log Files—Sets the maximum number of log files. FRS will create multiple files,
deleting the oldest when the number specified in this value is reached. Set this value to a
high number when troubleshooting to get the most data to work with. Five is a good
value for normal operations.
•  Debug Maximum Log Messages—Sets the maximum number of entries per log file, with
10,000 entries requiring about 1MB of disk space. When the log fills, a new one is
created, up to the maximum number specified in Debug Log

Restart FRS. Log files are created in %systemroot%\Debug and are named Ntfrs_xxxx, where
xxxx is the log file number, up to the maximum you specified.

What should you look for in the log files? Primarily the keywords
error,warn , or fail —all of which indicate a problem. You’ll also see SHARING_VIOLATION when a file or process has
locked a file that FRS is trying to replicate; repeated sharing violations indicate a problem that
you can often resolve by restarting the affected domain controller.

To look for problems related to a specific file, open the log on the source computer. Look for the
file name and the corresponding :: COG number in the file; note the GUID from that log entry
and look for it in the destination domain controller’s log files

Most log entries will contain a thread identifier. Because each file (or group of files) is replicated on a
separate thread, if you find a failure or warning, look for all further log entries using the same thread
ID. Doing so will allow you to follow that particular thread to see what it’s doing and why it might be
having problems