Knowledge Base

FRS Does Not Replicate Files or Folders If the System Account Does Not Have Full Control of the Directory Tree

Article ID: 319473

Article Last Modified on 2/22/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 Q319473

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.

This article describes a code change in the Q307319 release of Ntfrs.exe that causes files and folders in FRS-replicated trees not to be replicated. Administrators may experience any of the following symptoms:

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

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 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 exposed an incorrect access check in the Ntfs.sys file system driver. The incorrect access check in the Windows 2000 Ntfs.sys rename path was fixed in Microsoft Windows XP. This fix prevents file renames by a service such as Ntfrs, even if the service has sufficient rights (in this case, backup/restore rights).

RESOLUTION

To resolve this problem, obtain the latest service pack for 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

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

   Date         Time   Version        Size     File name
   -----------------------------------------------------
   02-Mar-2002  14:40  5.0.2195.5016  733,456  Ntfrs.exe
   02-Apr-2002  17: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:

Stop the Ntfrs service.
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
```
Restart the FRS service.
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 Windows 2000 Service Pack 3.

MORE INFORMATION

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

307319 Changes to the File Replication Service

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

For additional information about how to install multiple hotfixes with only one reboot, click the article number below to view the article in the Microsoft Knowledge Base:

296861 Use QChain.exe to Install Multiple Hotfixes with One Reboot

Additional query words: kbBaseOS

Keywords: kbbug kbfix kbwin2000presp3fix kbqfe kbwin2000sp3fix kboswin2000fix kbwin2ksp4fix kbhotfixserver KB319473

Microsoft KB Archive/319473

Contents