Possible Causes of a Full File Replication Service Staging Area (307777)

MORE INFORMATION

When a file in an FRS-replicated folder is changed, the changed file is copied to the staging area to allow for replication to the downstream partners. This eliminates the need to lock the original file while the replication occurs. After the file is staged in the staging area, notifications are sent to the downstream partners to notify them of the available file. After all of the downstream partners request the file, receive the file, and send a positive acknowledgement, the file in the staging area is deleted.

The FRS staging area may consume more space than is typical for the following reasons:

• A downstream partner is offline or unreachable.
• Excessive replication is occurring.
• There is missing or corrupted configuration data in Active Directory.

A Downstream Partner Is Offline or Unreachable

If a downstream partner is offline, inaccessible because of network problems, or the site link schedule does not allow for replication at that time, all of the changed files in the FRS-replicated folder are stored for that downstream partner until that partner becomes available. If a server has stopped working or has been taken offline without being gracefully removed from the replica set, the staging area continues to fill until the server runs out of staging space. When this occurs, the NTFRS service stops responding.

For additional information about this condition and about how to reset the size of the staging folder, click the article number below to view the article in the Microsoft Knowledge Base: The procedure to gracefully remove a server from a replica set differs based on the type of replica set. For a Sysvol replica set, gracefully removing a server consists of demoting it by using the Dcpromo.exe tool. For a DFS replica set, gracefully removing the server from the replica set consists of removing it as a replicated DFS root or link by using the Dfsgui.msc snap-in.

Excessive Replication Is Occurring

There are several possible causes for excessive replication. Anything that writes a change to a file (with the exception of the archive bit) causes that file to be replicated. The types of changes that generate replication are:

• Access control list changes
• Primary data stream changes
• Alternate data stream changes

Access Control List Changes

An Access Control List (ACL) change is a change in the security or auditing information for a file or folder. This includes changes that are initiated manually by a user, or changes that are initiated by applying a group policy that applies permissions to files or folders. If a Group Policy object (GPO) that sets security on the Winnt or Sysvol folder on a domain controller is applied, the computer will attempt to replicate the entire contents of its Sysvol folder to its downstream partners every time that the policy is applied (this occurs every five minutes by default on a domain controller). For additional information, click the article number below to view the article in the Microsoft Knowledge Base:

Primary Data Stream Changes

A primary data stream change is a change to the primary data in a file. This occurs when data is added to or removed from a file, and includes creating or deleting files. These activities cause the file that was changed to be replicated.

Alternate Data Stream Changes

Alternate data streams are a feature of the NTFS file system that allow data to be stored in an alternate data stream in a file. This data is then available to any program that can use that data. Programs that might use this feature include antivirus scanners, backup programs, and quota software. The use of this feature is not limited to any type of program. Not all antivirus scanners, backup programs, and quota software use alternate data streams to store program-specific data. When a program does store data in an alternate data stream, special steps are required to ensure that the data is not replicated if it does not need to be replicated. For additional information, visit the following Microsoft Web site:

There Is Missing or Corrupted Configuration Data in Active Directory

FRS relies on containers, objects, and attributes that are stored in Active Directory and replicated among domain controllers in a domain to function. Critical objects include FRS member and Subscriber objects. Required and optional attributes include the schedule, file filters, folder filters, and database location. Schema definitions define the containers or location in which FRS objects reside. If any of the required objects or attributes are missing or corrupted, FRS may not work.

For additional information about these objects and how to recover them, click the article number below to view the article in the Microsoft Knowledge Base: