Microsoft KB Archive/321557

From BetaArchive Wiki

Article ID: 321557

Article Last Modified on 2/1/2007



APPLIES TO

  • Microsoft Windows 2000 Service Pack 1
  • Microsoft Windows 2000 Service Pack 2
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Service Pack 1
  • Microsoft Windows 2000 Service Pack 2



This article was previously published under Q321557

IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows Registry


SYMPTOMS

The File Replication service (FRS) is a multi-threaded, multi-master replication engine that replaces the LANMan Directory Replication service (LMRepl service) in Microsoft Windows NT versions 3.x and 4.0. Windows 2000-based domain controllers and servers use FRS to replicate system policy and logon scripts for Windows 2000-based and earlier clients.

Optionally, FRS can replicate content between Windows 2000-based servers that host the same fault-tolerant Distributed File System (DFS) roots or child-node replicas.

The changes to Ntfrs.exe that are described in the "Changes to the Post-SP2 Hotfix Versions of Ntfrs.exe and Ntfs.sys" section of this article were originally released as hotfix Q307319 in the Fall of 2001. When a Microsoft Office data-file-deletion problem that is common to all versions of the File Replication service was discovered, Ntfrs.exe was updated again and released again as hotfix Q307319 in March, 2002.

Both versions of the Q307319 hotfix expose a problem in Ntfs.sys that prevents certain rename operations and blocks the replication of some files. Therefore, Ntfrs.exe from the 2002 release of hotfix Q307319 is being repackaged and re-released with the hotfix Q319473 release of Ntfs.sys as hotfix Q321557. Because Ntfs.sys is included, installing this hotfix requires that you restart the computer.

This article describes changes to the versions of Ntfrs.exe and Ntfs.sys that are available in a Windows 2000 post-Service Pack 2 (post-SP2) hotfix that resolves known issues and improves the manageability and robustness of FRS. For a description of these changes, see the "Changes to the Post-SP2 Hotfix Versions of Ntfrs.exe and Ntfs.sys" section in this article.

If this release of Ntfrs.exe is installed on any FRS replica set member, Microsoft recommends that administrators deploy either the Q321557 hotfix version or Windows 2000 Service Pack 3 release of Ntfrs.exe on all members of a common FRS replica set, which means all domain controllers in the same domain or all members of Distributed File System (DFS) root or link targets where FRS replication has been enabled.

CAUSE

When it processes a change order on a downstream partner, Ntfrs renames the matching staging file in a pre-installation folder to its destination file name and folder. Previous versions of Ntfrs may encounter sharing violations during the rename operation if the destination folder is locked by other processes such as Explorer.exe.

To avoid sharing violations, the Q307319 (and the Q321557) version of FRS opens parent folders with reduced access requirements (FILE_READ_ATTRIBUTES instead of GENERIC_READ and GENERIC_EXECUTE). In doing so, the relaxed folder locks avoid sharing violations that prevent the rename operation from completing. However, this exposes an incorrect access check in the Ntfs.sys file system driver. This problem prevents file renames by a service such as Ntfrs that do not have sufficient explicit access to perform the operation on a file or folder, but does have implicit rights as a service. In this case, NTFRS has backup/restore rights, which provides implicit access to all of the folders and files in a volume. The Q321557 hotfix includes an updated Ntfs.sys driver that resolves this problem.


RESOLUTION

Service Pack Information

To resolve this problem, obtain the latest service pack for Microsoft Windows 2000. For additional 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 hotfix is now available from Microsoft, but it is only intended to correct the problem that is described in this article. Only apply it to systems that are experiencing this specific problem. This hotfix may receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next Windows 2000 service pack that contains this hotfix.

To resolve this problem immediately, contact Microsoft Product Support Services to obtain the fix. For a complete list of Microsoft Product Support Services phone numbers and information about support costs, visit the following Microsoft Web site:

NOTE: In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The typical support costs will apply to additional support questions and issues that do not qualify for the specific update in question.

The English version of this fix should have the following file attributes or later:

   Date         Time   Version        Size     File name
   --------------------------------------------------------
   02-Mar-2002  23:40  5.0.2195.5016  733,456  Ntfrs.exe
   03-Mar-2002  02:44  5.0.2195.5016   54,544  Ntfrsapi.dll
   03-Mar-2002  02:44  5.0.2195.5016   21,264  Ntfrsprf.dll
   02-Mar-2002  23:39  5.0.2195.5016   80,384  Ntfrsres.dll
   03-Apr-2002  02:41  5.0.2195.5524  513,072  Ntfs.sys


To avoid replication problems in which System does not have full control of the FRS replica tree, install this Ntfs.sys hotfix on all Windows 2000-based domain controllers and member servers on which the Q307319 release of Ntfrs.exe is installed. After you install this hotfix you must restart the computer.

WORKAROUND

To work around this problem without installing the hotfix, select a member of the affected Ntfrs replica set (preferably a bridgehead server with many outbound connections). Grant the System account full control of the all of the folders in the FRS replica tree by using these steps:

  1. Stop the Ntfrs service.
  2. By using the Security tab in Windows Explorer, or by using a command-line equivalent, grant the System account full control on all folders at and below the FRS replica root, including the hidden DO_NOT_REMOVE_NtFrs_PreInstall_Directory folder, so that new files and folders inherit this permission. You must stop FRS to modify the ACL for the DO_NOT_REMOVE_NtFrs_PreInstall_Directory folder.

    You might want to use the following sample script from a command prompt. The script is focused on the FRS replica root folder by using Subinacl.exe to grant the System account full control of the FRS replica tree and the DO_NOT_REMOVE_NtFrs_PreInstall_Directory folder:

    C:\>for /r "X:\Frs_root_dir" /d %i in (*) do subinacl /file "%i" /grant=system=f

    In this sample script, X:\Frs_root_dir is the drive and path for the FRS replica root folder in which the ACL will be modified.

    The script adds "SYSTEM = Full Control" to the existing permissions on all folders at and below the path that is specified in the X:\Frs_root_dir parameter. In response to the ACL change, Ntfrs replicates all of the folders in the specified directory tree, but does not replicate the files.

    The version of Subinacl.exe must be version 2.6.0.1399 or later to avoid improperly ordered ACEs. The file information for a known good Subinacl.exe is:

    --a-- W32i   APP ENU   2.6.0.1399 shp   193,024 01-15-2002 subinacl.exe
  3. Restart the FRS service.
  4. Monitor the pre-installation folders and replica trees. Files in pre-installation folders are removed as the files are moved to their destination folders as the new ACL change takes effect.


STATUS

Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article. This problem was first corrected in Microsoft Windows 2000 Service Pack 4.

MORE INFORMATION

Two versions of Ntfrs.exe that were released as hotfix Q307319 in the Fall of 2001 and in March, 2002, expose an access check problem in Ntfs.sys that prevents the FRS from fully replicating files and folders. Administrators who installed either of these versions of Ntfrs.exe on computers on which the System account does not have full control of the replicated directory tree may experience any of the following symptoms:

  • An inconsistency in the contents of FRS-replicated DFS or Sysvol replica sets. Specifically:
    • A file or folder may exist on the upstream partner on which the file was created or last written, but not on other members of the replica set.
    • Files and folders may exist on both upstream and downstream partners, but their versions may be inconsistent (older) compared to the computer that received the last update.
    • Files and folders that are created in Windows Explorer (by clicking New on the File menu, and then creating a file or folder) are replicated to downstream partners, but are not replicated if they are created by using any other method (such as the mkdir command, the copy con filename.ext command, the copy command, the Save command on the File menu, the Save As command on the File menu, or by dragging the file in Windows Explorer.
  • Files that are located in the in the DO_NOT_REMOVE_NtFrs_PreInstall_Directory folder are not moved to their final locations.
  • A Connstat report from an upstream partner indicates that all of the change orders that were sent to the downstream partner have been received and processed.
  • The ntfrsutl idtable command indicates that files that are located in folders on the upstream partner but are missing on the downstream partner are located in the FRS IDTABLE of both computers. This indicates that the change order for a file was received by the downstream partner.
  • "Access Denied" error messages are recorded in the FRS debug logs when the FRS tries to rename a pre-installation file to its final name. For example:

    <StuPreInstallRename: 2728: 1546: S0: HH:MM:SS> ++ ERROR - Failed to rename pre-install file NTFRS_<ChangeOrder_GUID> for filename.ext WStatus: ERROR_ACCESS_DENIED

  • The inbound log (by using the ntfrsutl inlog command) on downstream partners shows that change orders for the missing files are in an "IBCO_INSTALL_REN_RETRY" state. This indicates that multiple attempts to rename the pre-installation file to its destination location were made (see the STATE: field). For example:
    Table Type: Inbound Log Table for DFSROOT|APPS (1)
    SequenceNumber               : 0000000d
    Flags                        : 0100004e Flags [VVAct Content Locn Retry CmpresStage ]
    IFlags                       : 00000001 Flags [IFlagVVRetireExec ]
    State                        : 0000000e  CO STATE:  IBCO_INSTALL_REN_RETRY   <--Note the rename retry error state.
    ContentCmd                   : 00002000 Flags [RenNew ]
    Lcmd                         : 00000004  D/F 0   Movein
    FileAttributes               : 00000020 Flags [ARCHIVE ]
    FileVersionNumber            : 00000005
    ..
    ..
    ChangeOrderGuid              : 9883330a-265f-4384-a38b69acb9d224bc
    OriginatorGuid               : fce4a387-68c7-43b2-9a2e93c3acbb401c
    FileGuid                     : 16ed465b-0324-4248-8c25535248bb51b6
    OldParentGuid                : 54d058b9-9a2e-4225-866d0a8a77cce7f0
    NewParentGuid                : 54d058b9-9a2e-4225-866d0a8a77cce7f0
    CxtionGuid                   : 86bc5234-f9ec-496b-8fc1b09eb55fa4b9
    Spare1Ull                    : Mon Jan  7, 2002 09:13:26
    MD5CheckSum                  : MD5: 9ac5676d 669a9926 a5a86bac 6eeae417 
    ..
    FileName                     : SOMESUCHFILE.EXT

This scenario is best identified by the "Access Denied" error messages in the FRS debug logs, and if files and folders that are created in Windows Explorer are replicated to downstream partners, but are not replicated if they are created by using any other method.

Changes to the Post-SP2 Hotfix Versions of Ntfrs.exe and Ntfs.sys

This article describes changes to the versions of Ntfrs.exe and Ntfs.sys that are available in a Windows 2000 post-Service Pack 2 (post-SP2) hotfix that resolves known issues and improves the manageability and robustness of FRS.

FRS Detects and Suppresses Excessive Replication

When data is written to a file, that file is staged for replication. However, there are some cases in which data is written but the file is not changed. 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. Therefore, FRS tires to replicate the "changed" files even though the permissions were not necessarily modified.

In the post-SP2 hotfix, FRS does not replicate a file if no actual changes were made. Also, if FRS detects a significant increase in the number of changes that are made to a file, FRS 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 of 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. Therefore, if the first upstream partner is synchronized, the new member replicates all of 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 member.

FRS Does Not Stop Replicating If the Staging Area Is Filled

If FRS tries to allocate space for a staging file but is not successful either because 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), 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. Therefore, FRS no longer stops replicating if the staging area runs out of free space. If a replica-set member goes offline for a long time, FRS does not block replication on an upstream member because the staging area is filled. For additional information about the staging space limit parameter, click the article number below to view the article in the Microsoft Knowledge Base:

221111 Description of FRS Entries in the Registry


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 128 megabytes (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 in the FRS event log to remind you to perform the operation at a convenient time. A registry key has been included to configure an automatic non-authoritative restore operation if you want to do so. However, if 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 if many members attempt to synchronize at once with an upstream partner.
  • The time-out problem that occurs if a staging file for a very large file is being created.

Changes to the Way in Which 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. This message is:

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:

[1] Run "net stop ntfrs" or use the Services snap-in to stop File Replication Service.

[2] 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.

[3] Run "net start ntfrs" or use the Services snap-in to start File Replication Service.

FRS Renaming of Files in the Pre-Installation Folder Generates "Access Denied"

This version of FRS opens parent folders with reduced access requirements (FILE_READ_ATTRIBUTES instead of GENERIC_READ and GENERIC_EXECUTE) to avoid sharing violations that prevent the rename operation on staging files from completing. However, this exposes an incorrect access check in the Ntfs.sys file system driver. An updated Ntfs.sys driver is included in this hotfix package.

Other Changes

  • 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) enables compression "on the wire." If the replicated data is already compressed, the resulting file may actually be larger than the original. When this occurs, the FRS "silently" does not replicate. This problem has been resolved.
  • Changes to Microsoft Office document files (.doc, .xl?, etc.) on one replica may cause the same file to be deleted on all downstream partners. This problem has been fixed.
  • 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 folders even if drive letter assignments change. FRS no longer polls removable drives when it builds this table.
  • Event messages that include instructions about how to update the registry have been corrected.
  • A memory leak that can be significant in environments that have many domain controllers has been fixed.

For additional information, click the article number below to view the article in the Microsoft Knowledge Base:

221111 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:

265173 The Datacenter Program and Windows 2000 Datacenter Server Product


Keywords: kbbug kbfix kbwin2000presp3fix kbqfe kboswin2000fix kbwin2ksp4fix kbhotfixserver KB321557