Issues that are fixed in the post-Service Pack 4 release of Ntfrs.exe (811370)

Issues Fixed in This Hotfix

• The "<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 occurs because a morph conflict must be checked for when the CO of an existing file is an implicit rename CO. The incoming CO ends up as an implicit rename, but not until after it is typically checked for name conflicts. Because it is a CO on an existing file, it is not checked for a morph conflict and a morph is not generated. This is incorrect. The CO still has the "DirName" name when it ends up in Install. An Install rename cannot be processed because DirName is blocking it.
• In the debug log directory created by FRS, the Everyone group has Full Control permission. The Everyone group also has Full Control permission for the debug logs. The information contained in the debug logs includes file and folder names and other information related to FRS operations. However, the debug logs contain no useful information about the content of the replicated files. In other directories created by FRS (for example, Staging, Database, Pre-Install, and Pre-Existing) only members of the Administrators group are granted access. As an added measure of security, you can change the security settings for the debug log directory to match the security settings of the other directories created by FRS. The hotfix described in this article also increases the security settings for the debug logs directory.
• A need for a mechanism to enforce replication regardless of the predefined schedule. This functionality has been added; you can use it with the new ntfrsutl forcerepl command.
• Incomplete information about event ID 13508 warnings in the FRS event log. You might not be able to understand what you must do when this message appears in the log.
• FRS stops working every few minutes, and generates error 13506 entries in the event log:
  Error 13505 STOPPED_ASSERT
  Info 13502 STOPPING
  Error 13555 IN_ERROR_STATE STRINGS: c:\winnt\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
• Vvjoin staging file generation for large files can take too long and cause fetch request time-outs. This may cause replication to stop working (hang).
• In some cases, after you restart a recently promoted domain controller, that domain controller immediately marks its Sysvol as ready, and advertises as a domain controller before file-system policy exists in the replica set root.
• WMI leaks memory because of a handle leak in FRS.
• 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 needs to replicate. You must perform a non-authoritative restore operation. The NTFS journal size has been increased to 512 megabytes (MB) to reduce the possibility of a journal wrap.

Glossary of Terms Used in This Article

Change Order (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) is used to construct a message that is called a "change order." The change order is sent to the member's outbound partners. If they decide to accept the change, the partners request the associated staging file. After installing the change on their individual replica tree, the partners 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. It, 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

This 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.

File Replication Service

FRS is a multiple-threaded, multiple-master replication engine. Windows 2000-based domain controllers and servers use FRS to replicate system policies and logon scripts for client computers that are running Windows 2000 and earlier versions of Microsoft Windows. FRS can also replicate content between Windows 2000-based servers that host the same fault-tolerant Distributed File System (DFS) root or link replicas.

Identity-Based Replication

All objects in a replica tree have a unique ID assigned to them. In FRS, the NTFS file system Object ID attribute that contains a 16-byte GUID is used. The same object on all replica members has the same object ID. This permits unambiguous location information for 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 file folder. The individual computers are referred to as replica members.

Update Sequence Number

The NTFS file system maintains a monotonically increasing sequence number for each volume that is called an update sequence number (USN). The USN is incremented every time a modification is made to a file on the volume.

Version Vector

This is a vector of USNs, with one entry per replica set member. All change orders carry the originator GUID of the originating member and the associated USN. As each replica-set member receives the update, it tracks the USN in a vector slot that is assigned to the originating member. This vector describes whether the replica tree is current with each member.

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 the new outbound partner does not see.

To set anonymous remote permissions in DCOM, follow these steps on a Microsoft Windows XP Service Pack 2 (SP2)-based computer that is running the SMS console:

1. Click Start, click Run, type dcomcnfg.exe in the Open box, and then click OK.
2. Locate the Console Root node, expand Component Services, and then expand Computers.
3. Right-click My Computer, and then click Properties.
4. In My Computer Properties, click the COM Security tab.
5. In Access Permissions, click Edit Limits, and then select ANONYMOUS LOGON.
6. Under Permissions for ANONYMOUS LOGON, click to select the Allow setting for Remote Access.
7. Click OK two times.
8. Restart your computer.

.

   Date         Time   Version            Size    File name
   --------------------------------------------------------------
   07-May-2003  19:14  5.0.2195.6743     745,232  Ntfrs.exe        
   15-May-2003  22:31  5.0.2195.6743      56,080  Ntfrsapi.dll     
   15-May-2003  22:31  5.0.2195.6743      22,288  Ntfrsprf.dll     
   07-May-2003  19:14  5.0.2195.6743      40,720  Ntfrsutl.exe