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:
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.
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).
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.
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 184.108.40.2069 or later to avoid improperly ordered ACEs. The file information for a known good Subinacl.exe is: