Microsoft KB Archive/811370

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

Article ID: 811370

Article Last Modified on 10/31/2006

-

APPLIES TO


 * Microsoft Windows 2000 Advanced Server
 * Microsoft Windows 2000 Service Pack 4

-



SUMMARY
This article describes changes to the File Replication Service (FRS) in a Windows 2000 post-Service Pack 4 (SP4) hotfix that improves the robustness of the service. You must have Windows 2000 SP4 installed before you apply this hotfix. This hotfix includes multiple fixes.

Important Microsoft discovered an issue with this version of NTFRS, resolved it, and then re-released the hotfix under the same name: Q811370. Under certain conditions, Microsoft Excel (.xls) files are renamed as an 8-digit hexadecimal number. There is no data loss associated with this issue. This issue may occur if you are working on an Excel file that exists in the Replica Set that is monitored by NTFRS. If you open an Excel file in the Replica Set, edit the file, and then save your changes, NTFRS renames the file to an 8-character hexadecimal name -- for example, CEA14500. The contents of the file are preserved, but the name of the file is potentially changed on one or more members of the FRS replica set. This 8-character name is the name of the temporary file that Excel creates during the editing process. This issue may occur if the server is using version 5.0.2195.6628 of Ntfrs.exe. You can verify the version by viewing the properties of Ntfrs.exe. Microsoft fixed this issue in the latest version of this FRS hotfix. The new version of Ntfrs.exe that includes this fix is 5.0.2195.6743. You can request this hotfix by contacting Microsoft Product Support Services (PSS). To do so, visit the following Microsoft Web site:

http://support.microsoft.com

For more information about the latest service pack for Microsoft Windows 2000, click the following article number to view the article in the Microsoft Knowledge Base:

260910 How to obtain the latest Windows 2000 service pack



Issues Fixed in This Hotfix
 The &quot; :: CoG 91cc0f81, CxtG 847d1e73, FV 2, FID 00010000 00000026, FN: DirName, [Rename failed (ERROR_ACCESS_DENIED)]&quot; 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 &quot;DirName&quot; 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.</li> WMI leaks memory because of a handle leak in FRS.</li> 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.</li></ul>

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 &quot;change order.&quot; 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.

.

<div class="resolution_section">

Service Pack Information
To resolve this problem, obtain the latest service pack for Microsoft Windows 2000. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

260910 How to obtain the latest Windows 2000 service pack

Hotfix Information
A 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 2000 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:

http://support.microsoft.com/contactus/?ws=support

The English version of this fix has the file attributes (or later) 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. <pre class="fixed_text">  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 Note Windows 2000 SP4 (version 5.0.2195.6709) upgrades the older version of Ntfrs.exe (5.0.2195.6628) that had the problem with .xls files that is described earlier in this article. Windows 2000 SP4 does not replace the current version of Ntfrs.exe (version 5.0.2195.6743) that already has the .xls fix in it. If you have version 5.0.2195.6743, you have the current and latest version of Ntfrs.exe. This version of Ntfrs.exe does not change after you apply SP4. Note You must restart the computer after you install this hotfix. If you do not want to restart your computer, you must manually stop the File Replication service before you install the hotfix. If you do this, you must manually restart the File Replication service after you install the hotfix.

Important This hotfix increases the default Journal size from 32 MB to 512 MB. Therefore, you must either manually set the appropriate registry key to prevent the increase or make sure that you have enough free disk space to accommodate the change. For more information about setting the appropriate registry keys, click the following article number to view the article in the Microsoft Knowledge Base:

221111 Description of FRS entries in the registry

<div class="status_section">

STATUS
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the &quot;Applies to&quot; section. This problem was first corrected in Microsoft Windows 2000 Service Pack 4.

<div class="references_section">