Overview
Microsoft Windows 2000 Server and Microsoft Windows Server 2003 domain controllers use the File Replication Service (FRS) to automatically replicate data between domain controllers.
In Windows 2000 Server, the contents of the Sysvol folder are replicated to all domain controllers. The Sysvol folder stores logon scripts, default domain profiles, and system policies. If a change is made to a logon script, domain profile, or system policy, the change is replicated to all other domain controllers. This keeps the content of the Sysvol folder consistent across all domain controllers.
In Windows Server 2003 and Windows 2000 server, the contents of Microsoft Distributed File System (DFS) roots and links are also replicated between domain controllers. You can use FRS to schedule replication to occur when servers are available or network conditions are favorable. You can also use FRS to include or to exclude specific files in a replication schedule.
Recommended limits
Replication
Microsoft recommends the following FRS replication limits:
Content and data limits
- A maximum file size of 20 gigabytes (GB).
- A maximum of 64 GB of data.
- A maximum of 500,000 files under the replica root.
- A maximum of 1,000,000 simultaneous change orders.
Topology limits
- A maximum of 150 replica sets per computer.
- A maximum of 1,000 replica members.
FRS Jet database
Microsoft recommends that you restrict the size of the FRS Jet database to 8 terabytes (TB) or less. The size of the FRS Jet database is not related to the disk space requirements of the data in the replica tree, but to the number of folders and files that are in the replica tree.
You must also consider that FRS keeps a record of deleted files and folders for 60 days and also records all outbound change orders for 7 days. This means that the size of the FRS Jet database will increase as more files are replicated.
Staging area
The Staging folder temporarily stores modified files before they are propagated to other replication partners. The FRS encapsulates the data and attributes that are associated with a replicated file object or folder object in a staging file. The FRS needs enough staging area space on both upstream and downstream computers to replicate files.
For Windows 2000 Service Pack 2 (SP2) and in later versions of Windows 2000, when a staging file has been generated on the originating computer, the FRS compresses the file. This saves space in the staging file and causes less data to be replicated between members. It also makes sure that the file data can be supplied to partners regardless of what file activity might prevent access to the original file.
The staging area on both domain controllers must be as large as the largest file that you want to replicate. It must also be sufficiently large to store any other files pending replication. The staging area size limits in Windows 2000 Server and Windows Server 2003 are:
- Default size: 660 megabytes (MB)
- Minimum size: 10 MB
- Maximum size: 2 TB
If you are using Windows 2000 SP2 or an earlier version of Windows 2000, note that the FRS stops replicating if the staging area runs out of free space. If a replica set member goes offline for a long time, replication is not blocked on an upstream member because the staging area is filled. Therefore, it is a good idea to use a generous estimate for the staging area size.
Windows 2000 Service Pack 3 (SP3) and later versions of Windows 2000 use an updated staging-file management algorithm. With the updated algorithm, if the FRS tries to allocate space for a staging file. However, it is not successful because there is insufficient space or because the space that is used has reached 90 percent of the staging space limit. Then, the FRS starts to delete staging files. Staged files are deleted, in the order of the longest time since the last access, until the space that is used has dropped below 60 percent of the staging space limit. Therefore, it is not as important to use as large an estimate for the staging area size as it is for pre-SP3 systems. However, it is still a good idea to do this because it helps prevent disk or CPU resources from being consumed by repeatedly staging and deleting files.
Also, if you do not allocate enough staging area space, and the service starts the cleanup process when 90 percent of the allocated space is being used, the system must generate those files again. Replication may slow down or stop if many files or very large files are moved.
The following table provides scenarios to help you determine the staging area size that you need.
| Scenario | Base staging space | VVJOIN (when you are adding a new member) | Backlog (accounting for schedules) | Configuration notes | Recommendation |
| Minimal | 660 MB | MAX [660 MB ((128 largest files in the replica set) * number of downstream connections) * 1.2] | 0 | None | Not recommended |
| Average Case | 660 MB | MAX [660 MB ((128 largest files in the replica set) * number of downstream connections) * 1.2] | ADDITIONAL: (Maximum expected file change quantity in a 7-day period) * 1.2 | Different drive for the staging area | Recommended |
| Best Performance | 660 MB | MAX [660 MB ((128 largest files in the replica set) * number of downstream connections) * 1.2] | ADDITIONAL: (Additional space equal to full expected replica set size) * 1.2 | Different drive for the staging area | Recommended for configurations with the best performance requirements |
Use the numbers in this table as base recommendations. Adjust the values to fit your configuration.
If you do not allocate sufficient staging area space, the cleanup process may delete staged files in the order of the longest time since last access. If a user tries to access a deleted file, FRS will regenerate the file. This may affect performance significantly.
Note You must set the staging area size on each domain controller in the replica set.
For additional information about how to set the size of the staging area, click the following article number to view the article in the Microsoft Knowledge Base:
221111
Description of FRS entries in the registry
The FRS outgoing log processing has been changed in the Windows 2000 post-SP2 hotfix and in SP3 to retain change orders even after they have been sent to all current downstream partners. This change allows the FRS to synchronize with a new downstream partner from the outgoing log and to avoid a full IDTable scan. This change is helpful in environments where the topology frequently changes. This change is also helpful during a rollout when new members are coming online in a short time.
The default outlog change-order retention period is 7 days. The space depends on your usage and environment. Because a cleanup routine has been added that starts when 90 percent of the allocated staging space is reached, a safety factor of 1.2 has been added in the equation.
For more information about staging area management, click the following article number to view the article in the Microsoft Knowledge Base:
321557
Improvements in the post-Service Pack 2 release of Ntfrs.exe that is packaged with an updated Ntfs.sys driver
USN journal
The update sequence number (USN) journal provides a persistent log of all changes that are made to files in a volume. As files, directories, and other NTFS file system objects are added, deleted, and modified, NTFS enters records in the USN change journal, one for each volume on the computer.
In Windows 2000 Server Service Pack 4 and later, the default size of the USN Journal is 512 MB. Microsoft recommends that you increase the default size by 128 MB for every 100,000 files and folders.
Other issues
Microsoft recommends that you evaluate your FRS configuration with caution. As the number of files and data size increase, you may experience scenarios that affect computer and network performance.
Extremely large data sets
For data sets that have more than 500,000 files or 64 GB of disk space, we recommend that you evaluate the new DFS-R service that is introduced in Windows Server 2003 R2. The DFS-R service has, among other improvements, support for bigger data sets that have more files.
If a newer Windows version is not an option now, you can also use the Robocopy.exe Resource Kit tool to copy data.
Morphed directories
Morphed directories are folders and files that have been replicated to other servers and are exact copies of each other, but FRS cannot determine the most recent folder. Because FRS cannot determine the most recent folder, it creates a duplicate folder.
Non-authoritative restores
A non-authoritative restore synchronizes an out-of-date domain controller with an up-to-date source. You must stop the NTFRS service and set the startup to manual on the outdated domain controller before you initiate the non-authoritative restore. In scenarios with multiple domain controllers, this can affect network performance for a significant length of time.
Network latency
You may experience network latency as the number of replicated files and the replicated data size in increase. For more information about network topology and bandwidth consideration, visit the following Microsoft Web site:
Additional resources
For additional information about how to troubleshoot FRS replication issues, click the following article number to view the article in the Microsoft Knowledge Base:
221112
NT file replication service log file size and verbosity settings
For additional information about resolving FRS replication traffic issues, click the following article number to view the article in the Microsoft Knowledge Base:
282791
FRS: Disk defragmentation causes excessive FRS replication traffic
For more information about the new DFS-R service, visit the following Microsoft Web site: