Article ID: 328492
Article Last Modified on 11/29/2007
APPLIES TO
- Microsoft Windows 2000 Service Pack 1
- Microsoft Windows 2000 Service Pack 2
- Microsoft Windows 2000 Service Pack 3
- Microsoft Windows 2000 Advanced Server
- Microsoft Windows 2000 Advanced Server
- Microsoft Windows 2000 Advanced Server
- Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
- Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
- Microsoft Windows Server 2003, Standard Edition (32-bit x86)
- Microsoft Windows Server 2003, Web Edition
This article was previously published under Q328492
SYMPTOMS
File Replication service (FRS) may change the name of a folder by adding "NTFRS_xxxxxxxx" to the folder name.
Note In this example, xxxxxxxx represents eight random hexadecimal digits.
The following is an example of two frequently changed folders:
07/29/2002 09:58a Policies
07/29/2002 09:58a Policies_NTFRS_000add30
07/29/2002 10:18a scripts
07/29/2002 10:02p scripts_NTFRS_000874bb
CAUSE
When two users create a folder of the same name on two different replicas, File Replication service (FRS) detects a name conflict during replication.
One of the create operations take precedence and that folder retains the name. The other folder name is changed.
There are two common causes of this problem:
- A folder is created on multiple machines in the replica set before the folder has been able to replicate. The administrator or program may create duplicate folders on multiple FRS members. This may occur, for example, if the administrator is trying to make data consistent among all members with a manual copy.
- You initiate an authoritative restore (D4) on one server and:
- You did not stop the service on all other members of the reinitialized replica set before the NTFRS service restarts after the authoritative restore.
- You did not set the D2 registry key on all other members of the reinitialized replica set before such a server replicated outbound changes to reinitialized members of the replica set.
RESOLUTION
To resolve this problem, follow these steps:
- Rename the original folders and the changed folders to different names, and then wait for the new names to propagate through the system.
This makes sure the folder then has a common name throughout the SYSVOL, and that the names and GUIDs match on all members.
Note Do not delete the undesirable folder and rename the other one. This can lead to even more naming conflicts.
- After the rename has propagated, choose the folder that you want to keep, and then rename it back to the original name. Other changed folders can then be safely deleted.
Note Before you delete any of the folders, it is a best practice to make sure that you have a backup of the original (and complete) data.
MORE INFORMATION
All files and folders that FRS manages are uniquely identified by a special file ID called a file GUID. FRS uses file GUIDs as the canonical identifiers of files and folders that are being replicated.
FRS tries to make sure that the GUID for each file or folder is exactly the same on all members of the replica set. To FRS, the file or folder name visible in Windows Explorer or the DIR command is just a property of a file or folder. The name and path are not the identifier of the file. The GUID is the identifier of the file.
If an FRS member receives a change order to create a folder whose name already exists but has a different file GUID than the pre-existing folder, FRS detects a naming conflict. Because the file GUIDs for the two folders are different, it cannot be a change to the existing folder. In this case, the conflicting folder is given a new name of the form FolderName_NTFRS_GUIDname.
Note In this example, FolderName is the original name of the folder and GUIDname is a unique XX character string such as "001a84b2."
Administrators should be aware that group policy processing will not work during the clean-up process. This is because the UNC path in the policy will not match the folder name.
Additional query words: morphed
Keywords: kbprb KB328492
