Issues that are resolved in the pre-Service Pack 1 release of Ntfrs.exe
Key Terms and Concepts That Are Used in this Article
- Change Order (Also Known as CO)
When a change is made to a file or folder on a replica member, the information about that change (such as the name of the file or the ID of the member) that is used to construct a message is named a "change order." The change order is sent to the member's outbound partners. If the outbound partners accept the change, the partners request the associated staging file. After the change is installed on their individual replica tree, they each propagate the change order to their outbound partners.
- File GUID
The file GUID identifies the file or folder. It is created and managed by the replication service. The file GUID, with the replication version number and event time, is stored in the File ID table in the FRS database. Corresponding files and folders across all replica-set members have the same file GUID.
- File ID Table
The File ID table is a table in the FRS database that contains an entry with version and identity information for each file and folder in the replica tree.
- Identity-Based Replication
All objects in a replica tree are assigned a unique ID. In FRS, the NTFS object ID attribute that contains a 16-byte GUID is used. The same object on all replica members has the same object ID. This functionality permits unambiguous location of the object by using the object's GUID and the corresponding parent GUID.
- Replica Partner
The immediate upstream and downstream partners of a replica member are referred to as its replication partners. Upstream partners are also referred to as inbound partners. Downstream partners are also referred to as outbound partners.
- Replica Set
In FRS, two or more computers that are configured to replicate the contents of a folder are known as a replica set. The individual computers are referred to as replica members.
- Update Sequence Number (USN)
NTFS maintains a monotonically increasing sequence number for each volume. This number is the update sequence number (USN). Each time a modification is made to a file on the volume, the USN is incremented.
- Version Vector
This vector is a vector of USNs, where there is one entry per member of a replica set. All change orders carry the originator GUID of the originating member and the associated USN. As each member of a replica set receives the update, it tracks the USN in a vector slot that is assigned to the originating member. This vector describes how up-to-date the replica tree is with respect to each member. The version vector is then used to filter updates from inbound partners that may have already received the update. The version vector is also delivered to the inbound partner when the two members join. When a new connection is created, the version vector is used to scan the File ID table for more recent updates that are not seen by the new outbound partner.
List of Issues That Are Resolved in This HotfixThe hotfix described in this article resolves the following issues:
- "<StuInstallRename: 420: 1430: S3: 00:00:00> :: CoG 91cc0f81, CxtG 847d1e73, FV 2, FID 00010000 00000026, FN: DirName , [Rename failed (ERROR_ACCESS_DENIED)]" Error Message
This error message may occur in situations when a change order of an existing file is an implicit rename change order, and it is not checked for a morph conflict. An incoming change order becomes an implicit rename change order after it is typically checked for name conflicts. However, when the change order of an existing file is not checked for a morph conflict and a morph is not generated, the change order still has the "DirName" name in Install. As a result, the rename operation cannot be processed during a file installation because it is blocked by "DirName".
- Incomplete Information About Event ID 13508 Warning Messages
Event ID 13508 warning messages that are logged in the event log contain incomplete information. You may not be able to understand what you have to do when this message appears in the log.
- Event ID 13506 Errors Are Logged and FRS Stops Intermittently Stops Responding
FRS may stop responding every few minutes, and entries that are similar to the following are logged to the event log:Error 13505 STOPPED_ASSERT
Info 13502 STOPPING
Error 13555 IN_ERROR_STATE STRINGS: SystemRoot\ntfrs\jet
Error 13506 ASSERT STRINGS: ChgOrdDispatch: | 7340 | COE_FLAG_ON(ChangeOrder, COE_FLAG_NEED_DELETE)
Warn 13508 LONG_JOIN STRINGS: COMP1 | COMP2
Info 13501 STARTING
Error 13505 STOPPED_ASSERT
Info 13502 STOPPING
Error 13555 IN_ERROR_STATE
- Replication Stops Responding (Hangs) When Vvjoin Staging Generation for Large Files Takes a Long Time
When vvjoin staging file generation for large files takes a long time to complete, fetch request timeouts may occur. This may cause replication to stop responding (hang).
- Sysvol Is Marked As Ready on a Domain Controller Before File System Policy Exists in the Replica Set Root
In some situations, you may find that the Sysvol on a server that is recently promoted to a domain controller is marked as ready before file system policy exists in the replica set root.
- Memory Leak Condition in Windows Management Instrumentation (WMI)
A handle leak in FRS may cause a memory leak condition in WMI.
Updates That Are Included in This HotfixThe hotfix described in this article adds the following new functionality to FRS:
- Security Settings for the Debug Folder
The Everyone group has Full Control permission to the Debug folder and the debug log files that are stored in the Debug folder. The information contained in the debug logs include file and folder names and other information that is related to FRS operations. The debug logs do not contain any useful information about the content of the replicated files. Only members of the Administrators group are granted access to other folders that are created by FRS. These folders include the Staging, Database, Pre-Install, and Pre-Existing folders.
After you apply this hotfix, you can increase the security settings for the Debug folder to match the security settings of the other folders that are created by FRS.
- NTFRSUTL FORCEREPL Command-Line Option to Force Replication
You can use the new ntfrsutl forcerepl command to enforce replication regardless of the predefined replication schedule. This is only implemented for the domain controller Sysvol replica set.
ntfrsutl forcerepl [Computer] /r [SetName] /p [DnsName]
This command forces FRS to start a replication cycle. You must specify the Computer, SetName and DnsName.
Note In this command, the following placeholders are used:
- [Computer] = Connect with the NtFrs service on this machine.
- [SetName] = The name of the replica set.
- [DnsName] = The DNS name of the inbound partner to force replication from.
For example:ntfrsutl.exe forcerepl DestinationDC /r "Domain System Volume (SYSVOL share)" /p SourceDC.domain.com
The quotation marks in this example are required when you use the /r option. If the quotation marks are not present, the command will not work.
- Increase in the 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 has to replicate and you must perform a non-authoritative restore operation. When you apply this hotfix, the NTFS journal size is increased to 512 megabytes (MB) to reduce the risk of a journal wrap.
- New Options for Sharing Violation Issues
A new feature, Install Override, permits FRS to override sharing violations on file installs. Additionally, a new event ID is created that logs sharing violation-related activity.For additional information, click the following article number to view the article in the Microsoft Knowledge Base:822300 FRS encounters "ERROR_SHARING_VIOLATION" errors when it tries to replicate data that is still in use816493 How to configure the File Replication Service to allow fewer Sharing violations that block replication
Hotfix InformationA supported feature that modifies the product's default behavior is now available from Microsoft, but it is only intended to modify the behavior that this article describes. Apply it only to systems that specifically require it. This feature may receive additional testing. Therefore, if the system is not severely affected by the lack of this feature, we recommend that you wait for the next Windows Server 2003 service pack that contains this feature.
To obtain this feature immediately, contact Microsoft Product Support Services. For a complete list of Microsoft Product Support Services telephone numbers and information about support costs, visit the following Microsoft Web site:
PrerequisitesNo prerequisites are required.
Restart RequirementYou must restart your computer after you apply this hotfix.
Hotfix Replacement InformationThis hotfix does not replace any other hotfixes.
File InformationIf the server to which you apply this fix has an installed version of the Windows Server 2003 Support Tools, you must replace NTFRSUTL.EXE in the Support Tools folder with the new version of NTFRSUTL.EXE. Additionally, you can delete the version of NTFRSUTL.EXE in the Support Tools folder because the new version is installed into %systemroot%\system32.
The English version of this hotfix has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in Coordinated Universal Time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time tool in Control Panel.
Date Time Version Size File name ------------------------------------------------------- 23-Jan-2004 01:49 5.2.3790.121 772,096 Ntfrs.exe 23-Jan-2004 01:49 5.2.3790.121 57,856 Ntfrsapi.dll 23-Jan-2004 01:49 5.2.3790.121 21,504 Ntfrsprf.dll 23-Jan-2004 01:49 5.2.3790.123 9,728 Ntfrsutl.exe
Article ID: 823230 - Last Review: 12/03/2007 04:26:40 - Revision: 13.7
- kbhotfixserver kbqfe kbinfo kbbug kbfix kbqfe kbwinserv2003presp1fix KB823230