This article describes changes to the File Replication
Service (FRS) in a Windows 2000 Post-Service Pack 2 (SP2) hotfix that improve
the robustness of the service. These changes address behavior that may cause
FRS to stop replicating. The changes also include manageability improvements
and minor problem fixes.
A supported feature that modifies the default behavior of the product is available from Microsoft. However, this feature is intended to modify only the behavior that this article describes. Apply this feature only to systems that specifically require it.
If the feature is available for download, there is a "Hotfix download available" section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the feature. Note
If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific feature. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site: Note
The "Hotfix download available" form displays the languages for which the feature is available. If you do not see your language, it is because the feature is not available for that language. The English version of this feature should have the
following file attributes or later:
Date Time Version Size File name
02-Mar-2002 22:40 5.0.2195.5016 733,456 Ntfrs.exe
03-Mar-2002 01:44 5.0.2195.5016 54,544 Ntfrsapi.dll
03-Mar-2002 01:44 5.0.2195.5016 21,264 Ntfrsprf.dll
02-Mar-2002 22:39 5.0.2195.5016 80,384 Ntfrsres.dll
02-Mar-2002 22:39 5.0.2195.5016 39,696 Ntfrsutl.exe
Due to directory access changes in this release, the replication
of files and directories will fail with an "access denied" error if the System
account does not have full control of all folders in the directory tree that is
replicated by the File Replication Service (FRS).
For additional information, click the article number below to
view the article in the Microsoft Knowledge Base:
FRS Does Not Replicate Files or Folders If System Does Not Have Full Control of the Directory Tree
This section describes these changes.
FRS Detects and Suppresses Excessive Replication
Whenever data is written to a file, that file is staged for
replication. However, there are some cases where data is written that do not
change the file at all. For example, if you use Group Policy to apply file
permissions, the file is not changed. If you use Group Policy to enforce
permissions on files in SYSVOL, that policy is applied every five minutes by
default. As a result, FRS attempts to replicate the "changed" files even though
the permissions were not necessarily modified.
In the post-SP2
hotfix, FRS replicates a file if no actual changes were made to it. In
addition, if FRS detects a significant increase in the number of changes made
to a file, it logs an event ID 13567 message in the FRS event log.
FRS Performs Serialized Version Vector Joins
When a member first joins a replica set, FRS locates the upstream
partners and requests a list of all the files in the replica set. In versions
of Windows 2000 before this post-SP2 hotfix, FRS obtains this list of files
from all upstream partners at the same time, which results in a duplication of
effort on those partners. In the Windows 2000 post-SP2 hotfix, this behavior
has been changed so that FRS obtains the list from the upstream partners one
after the other. As a result, if the first upstream partner is synchronized,
the new member replicates all the files from it. The version vector join
process with each subsequent partner is much shorter because the new member
does not need to replicate any files. If the initial partner is not
synchronized, subsequent joins result in updates that are sent to the new
FRS Does Not Stop Replicating If the Staging Area Is Filled
When FRS tries to allocate space for a staging file and is not
successful because either there is not enough space or because the amount of
space in use has reached 90 percent of the staging space limit parameter (the
default value is 660 megabytes [MB]), FRS starts to delete staging files.
Staged files are deleted (in the order of the longest time since the last
access) until the amount of space in use has dropped below 60 percent of the
staging space limit parameter. As a result, FRS no longer stops replicating if
the staging area runs out of free space. This means that if a replica set
member goes offline for an extended period of time, it does not block
replication on an upstream member because the staging area is
For additional information about the staging space limit
parameter, click the article number below to view the article in the Microsoft
Description of FRS Entries in the Registry
Increase in NTFS Journal Size
FRS uses the NTFS file system journal to alert it when changes
are made to a file. If the journal wraps, FRS loses track of the changes it
needed to replicate, and you must perform a non-authoritative restore
operation. The NTFS journal size has been increased to 128 MB to reduce the
possibility of a journal wrap.
Changes to the Automatic Non-Authoritative Restore Functionality
FRS no longer performs an automatic non-authoritative restore if a
journal wrap condition is detected. Instead, it logs an event ID 13568 message
to the FRS event log to remind you to perform the operation at a convenient
time. A registry key has been provided to configure an automatic
non-authoritative restore operation if you want to use that functionality.
However, when you configure this setting, the contents of the replica tree may
be made unavailable while the restore operation is taking place.
Time Out Problems
The following time out problems have been addressed:
- The time out problem that occurs when a large number of
members attempt to synchronize all at once with an upstream partner.
- The time out problem that occurs when a stage file for a
very large file is being created.
Changes to the Way You Change the FRS Staging Path
You can now change the FRS staging path without having to perform
a non-authoritative restore operation. When FRS detects a change to the staging
path, it logs an event ID 13563 message in the FRS event log that describes the
procedure. The following section contains the text for this message:
The File Replication Service has detected that the staging path for the replica set %1 has changed.
Current staging path = %2
New staging path = %3
The service will start using the new staging path after it restarts.
The service is set to restart after every reboot. It is recommended that you manually
restart the service to prevent loss of data in the staging directory. To manually restart
the service, perform the following steps:
 Run "net stop ntfrs" or use the Services snap-in to stop File Replication Service.
 Move all the staging files corresponding to replica set %1 to the new staging
location. If more than one replica set are sharing the current staging directory then it
is safer to copy the staging files to the new staging directory.
 Run "net start ntfrs" or use the Services snap-in to start File Replication Service.
followed by "net start ntfrs".
- Event messages that are logged when a domain controller is
unable to create the Sysvol share are now more descriptive.
- The FRS update for Windows 2000 Service Pack 2 (SP2)
enabled compression on the wire. If the replicated data is already compressed,
the resulting file may actually be larger than the original, and the FRS
silently does not replicate. This problem has been resolved.
- Changes to a Microsoft Excel spreadsheet on one replica may
cause the same file to be deleted on all downstream partners. This problem has
- The FRS service must build a table that links volume serial
numbers to drive letters. This table is used to make sure that the service can
find the correct volume for the replicated directories even if drive letter
assignments change. FRS will no longer poll removable drives when it builds
- Event messages that include instructions on how to update
the registry have been corrected.
- A memory leak that can be significant in environments with
a large number of domain controllers has been fixed.
For additional information, click the article number below
to view the article in the Microsoft Knowledge Base:
Description of FRS Entries in the Registry
For additional information about how
to obtain a hotfix for Windows 2000 Datacenter Server, click the article number
below to view the article in the Microsoft Knowledge Base:
The Datacenter Program and Windows 2000 Datacenter Server Product
Article ID: 307319 - Last Review: October 30, 2006 - Revision: 4.2
- Microsoft Windows 2000 Server SP1
- Microsoft Windows 2000 Server SP2
- Microsoft Windows 2000 Advanced Server SP1
- Microsoft Windows 2000 Advanced Server SP2
|kbautohotfix kbhotfixserver kbfix kbinfo kbqfe kbwin2000presp3fix KB307319|