Windows Server: FRS Adding _NTFRS_ Folders? Understand the Issue & Solution

Table of Contents

File Replication Service (FRS) is a multi-threaded, multi-master replication engine that replaces the LAN Manager 2.x Replication Service. FRS is primarily used to replicate the SYSVOL directory structure on Windows 2000 and Windows Server 2003 domain controllers. It is also used to replicate content for the Distributed File System (DFS) in Windows 2000 and Windows Server 2003 environments. While newer Windows Server versions have transitioned to DFSR (Distributed File System Replication), FRS remains relevant for legacy systems and migration paths.

A common issue encountered when using FRS is that it may append a suffix in the format _NTFRS_<xxxxxxxx> to folder names. This occurs during the replication process and indicates a name conflict detected by the FRS engine. Understanding the root cause and proper resolution is crucial for maintaining a healthy and consistent replicated environment, particularly for the critical SYSVOL share which contains Group Policy objects and login scripts.

Symptoms¶

The primary symptom of this issue is the unexpected modification of folder names within an FRS-replicated replica set. When a new folder is created, instead of its original name being replicated consistently to all members, one or more replicas show the folder name modified by appending _NTFRS_ followed by an eight-character hexadecimal string (e.g., _NTFRS_000abc12).

This behavior is a mechanism FRS uses to handle naming conflicts. It essentially renames the conflicting object to allow replication to proceed, preventing the loss of one of the conflicting creations. While intended to maintain data integrity in a conflict scenario, it leads to administrative confusion and potential issues with scripts or applications that rely on specific folder paths.

Consider the following examples demonstrating how FRS might alter folder names when a conflict occurs:

Original Folder Name	New Folder Name
Policies	Policies_NTFRS_000add30
scripts	scripts_NTFRS_000874bb

These renamed folders coexist with the correctly named version of the folder (or another renamed version, depending on the conflict). Identifying which is the “correct” or desired folder requires administrative investigation, often by examining the contents or timestamps.

The presence of these suffixed folders can indicate underlying issues with the replication topology, network latency, or administrative procedures. It signifies that FRS detected ambiguous creation events for objects with the same name across different servers in the replica set.

Cause¶

The fundamental cause of FRS adding the _NTFRS_<xxxxxxxx> suffix to folder names is a name conflict detected during the replication process. FRS operates on a multi-master model, meaning changes can originate from any member of the replica set. Each file and folder managed by FRS is uniquely identified by a File/Folder GUID (Globally Unique Identifier) within the FRS database. The name visible to users is merely an attribute of the object identified by the GUID.

When a new folder is created on one replica member, FRS assigns it a unique GUID and schedules the creation for replication to other members. If, before this creation replicates to another member, a folder with the exact same name is independently created on that second member, FRS encounters a conflict when the first creation reaches it. Both folders have the same name but different GUIDs (because they were created independently). FRS must resolve this conflict. It cannot have two objects with different GUIDs sharing the same name and parent path within the same replica set view.

FRS resolves this conflict by allowing one creation event to “win” the original name (typically based on version stamps, timestamps, or replica preference, although the exact conflict resolution logic can be complex). The other creation event, which represents the folder with the conflicting name but a different GUID, has its name modified by appending the _NTFRS_<xxxxxxxx> suffix. This ensures that both objects can coexist in the file system, albeit with one having an altered name.

There are two particularly common scenarios that frequently lead to this type of FRS name conflict:

1. Simultaneous Creation on Multiple Members: This is perhaps the most straightforward cause. An administrator or an automated process might create the same folder (with the identical path and name) on several domain controllers or FRS replica members in quick succession, often as part of a manual data synchronization effort. If these creations occur before FRS has a chance to replicate the initial creation to the other members, each server acts as the “originator” of an independently created folder with the same name. When replication messages are exchanged, the conflict arises. This is particularly common when administrators manually copy data to multiple servers believing they are helping to “seed” the replication, but instead they create conflicting objects.

2. Incorrect Procedures During Authoritative Restore (D4/D2): Authoritative restore (often initiated by setting the BurFlags registry key to D4) is a drastic measure used to rebuild the FRS replica set from a single known good source. A non-authoritative restore (BurFlags set to D2) is used to reinitialize a single replica member by pulling data from a partner. Improperly performing these restores, especially an authoritative restore affecting the SYSVOL share, can flood the replica set with conflicting data and create numerous _NTFRS_ suffixed folders.

   • Authoritative Restore (D4) Issues: Setting BurFlags to D4 on a server tells FRS that its copy of the data is the “authoritative” source for the entire replica set. When this server comes online, it increments the version stamps for all its files and folders and replicates them outwards, instructing partners to synchronize from it. If other members of the replica set are allowed to continue processing incoming replication or originate changes before they have been properly reinitialized (typically via a D2 restore directed at the authoritative server), they might reintroduce older or conflicting versions of files/folders, or worse, independent creations that conflict with the authoritative data.
   • Required Steps for D4: To avoid conflicts during an authoritative restore, it is critical to:
     • Stop the FRS service on all other members of the replica set before restarting the FRS service on the server performing the D4 restore.
     • Configure the BurFlags key to D2 on all these other members before restarting their FRS service. This forces them to discard their current FRS database and contents and perform an initial, non-authoritative synchronization from a designated upstream partner (which should be the D4 server). Failing to stop the service or set D2 flags on partners allows them to potentially process changes or create new objects (like folders) independently, leading to conflicts when they eventually try to synchronize with the authoritative source.

In essence, any scenario where FRS detects the independent creation of an object with the same name and parent path, but a different GUID, on multiple replica members will trigger this conflict resolution mechanism, resulting in the _NTFRS_ suffix being added to one of the conflicting objects. The FRS database, which tracks the GUIDs, version numbers, and state of each replicated object, is central to this process. When a conflict is detected, FRS consults its database and applies the conflict resolution logic, updating the database entry for the renamed object and replicating this change.

Resolution¶

Resolving the issue of _NTFRS_ suffixed folders requires careful administrative steps to ensure that a single, desired version of the folder exists across the entire replica set without triggering further conflicts. The recommended approach involves a two-step process centered around renaming and then deleting. It is crucial to allow sufficient time for changes to replicate between steps.

Important Precaution: Before undertaking any steps to resolve this issue, it is strongly recommended to perform a full backup of the replicated data on at least one stable member of the replica set. This provides a safety net in case of accidental data loss during the cleanup process.

Here are the detailed steps to resolve the FRS name conflict issue:

1. Rename Both the Original and the Suffixed Folders:

   • Identify the folder(s) that have been duplicated and one or more instances have the _NTFRS_<xxxxxxxx> suffix.
   • On the server where the desired version of the folder exists (or choose one as the authoritative source for the cleanup), rename the original folder to a temporary, unique name (e.g., append _TEMP or a date/timestamp to its name).
   • On the same server (or the server(s) where they exist), rename the folder(s) with the _NTFRS_<xxxxxxxx> suffix to another unique, temporary name (e.g., append _CONFLICT or _OLD). Ensure the new temporary names are distinct from the original and from each other.
   • Crucially: Wait for these renaming operations to replicate to all other members of the FRS replica set. The time required for replication depends on the replica set size, topology, and network latency. Monitor FRS event logs (Event Viewer -> Applications and Services Logs -> File Replication Service) on all servers to confirm that the rename events have been processed. Look for events indicating successful replication. Do not proceed until you are certain the temporary names have propagated everywhere. This step is vital because it gives each folder object (identified by its unique GUID) a unique name across the replica set view, removing the name conflict that FRS detected initially. Simply deleting the undesired folder at this stage can sometimes lead to replication issues or the recreation of conflicts because FRS might interpret the deletion differently across replicas if the name conflict hasn’t been fully resolved by ensuring unique temporary names for all conflicting GUIDs.

2. Choose the Desired Folder and Revert its Name, Then Delete the Others:

   • After confirming that the temporary names from step 1 have replicated to all members, you now have folder(s) with temporary names representing the original (desired) version and the conflicting (_NTFRS_ suffixed) versions.
   • Determine which of the temporarily renamed folders contains the data you wish to keep. This often involves examining the contents, timestamps, or permissions.
   • On the server where the desired, temporarily renamed folder resides, rename it back to the original, intended folder name.
   • Wait again for this final rename operation to replicate to all other members of the replica set. Confirm replication completion via FRS event logs. Now, the desired folder should exist on all members with its correct, original name.
   • Once the desired folder has its correct name and this change has replicated, you can safely delete the other temporarily renamed folders (those that originally had the _NTFRS_ suffix or were the non-chosen conflicting version). Perform this deletion on one server and wait for the deletion to replicate throughout the replica set.

Following this two-step process of renaming all conflicting versions temporarily before deleting ensures that FRS can correctly track the objects by their GUIDs through the renaming process, resolving the name conflict cleanly. Deleting a folder only after the name conflict is definitively resolved across all replicas minimizes the risk of FRS attempting to re-create a conflicting object or encountering further replication issues.

Important Note: If the number of _NTFRS_ suffixed folders is very large, manually renaming and deleting might be impractical. In such cases, scripting might be necessary, but this requires advanced knowledge of scripting and FRS behavior and should be approached with extreme caution and thorough testing in a lab environment first. Analyzing FRS debug logs (enabled via the DebugFlags registry key) using tools like FRSKCC and NTFRSD can also provide deeper insight into the conflict state and help identify the problematic objects, but this is a task for experienced administrators. For SYSVOL replication, ensure that Group Policy works correctly after the cleanup by running gpupdate /force on client machines and domain controllers and verifying policy application.

More Information¶

As discussed, the core concept behind FRS’s handling of files and folders is the use of GUIDs (Globally Unique Identifiers) as the canonical identifier. Every file and folder replicated by FRS is assigned a unique GUID when it is first introduced into the replica set. FRS tracks the state, version, and location of objects based on their GUIDs in its internal database.

The file or folder name and its path within the replicated directory structure are considered attributes of the object identified by the GUID, much like the last modified timestamp or file permissions. While important for user interaction and application access, the name is secondary to the GUID for FRS’s internal tracking and conflict resolution.

When FRS receives a replication order to create an object with a specific name and parent path, it checks its database. If it finds an existing object (identified by a different GUID) already occupying that name and path, it detects a name conflict. Since two distinct objects (with different GUIDs) cannot have the identical name and path simultaneously on the same server, FRS must differentiate them. The conflict resolution logic determines which object retains the original name. The other object is then subjected to a name modification: the _NTFRS_<xxxxxxxx> suffix is appended to its name. This new, unique name allows FRS to place both objects on the server, each still tied to their original, unique GUIDs.

This mechanism prevents data loss in the sense that neither independently created object is immediately overwritten or deleted. However, it leaves the administrative task of reconciling the conflicting versions and cleaning up the unwanted duplicates. The hexadecimal string <xxxxxxxx> appended to _NTFRS_ is derived from the object’s GUID, providing a unique identifier for the conflicting object even in its renamed state.

Understanding that FRS prioritizes the GUID as the true identity of a replicated object is key to resolving conflicts. The recommended resolution method (renaming all conflicting versions temporarily) works because it ensures that for a period, every object GUID involved in the conflict has a unique name within the replica set, allowing FRS to stabilize its view before the final desired name is applied and unwanted duplicates are removed.

Understanding FRS¶

File Replication Service (FRS) is a legacy but fundamental component of Windows Server operating systems up to Windows Server 2003. Its primary roles were:

• SYSVOL Replication: Replicating the contents of the SYSVOL share among domain controllers in a Windows 2000 or Windows Server 2003 domain. SYSVOL stores crucial domain data, including Group Policy Objects (GPOs), logon scripts, and other administrative files, ensuring consistency across all domain controllers.
• DFS Replication (Standalone and Domain-based): Replicating data between targets in a Distributed File System (DFS) namespace, allowing users to access geographically dispersed data through a single namespace path. FRS was used for DFS replication in Windows 2000 and Windows Server 2003.

FRS operates as a multi-master replication engine. This means that changes can originate on any server participating in the replica set. FRS uses a change-journaling mechanism on NTFS file systems (the USN journal) to track file and folder modifications. When a change is detected, FRS stages the file or folder and replicates it to its partners according to the defined replication topology (connection objects in the Active Directory Sites and Services snap-in for SYSVOL replication).

While effective for its time, FRS has limitations. It can be sensitive to network latency, prone to journal wraps (losing track of changes if the journal is overwritten before FRS processes it), and conflict resolution can be complex, leading to issues like the _NTFRS_ suffix problem. For these reasons, Microsoft introduced Distributed File System Replication (DFSR) starting with Windows Server 2003 R2 as a more robust and efficient replication engine, which became the default for SYSVOL replication starting with Windows Server 2008. However, environments still running older servers or those that haven’t migrated SYSVOL to DFSR still rely on FRS.

Impact of the Issue¶

The presence of folders suffixed with _NTFRS_<xxxxxxxx> is more than just an administrative annoyance. It can have several negative impacts on the domain and replicated data:

• Broken Scripts and Applications: Logon scripts, batch files, or applications that rely on hardcoded paths within the SYSVOL share (e.g., paths to specific policy files or utility scripts) will fail if the expected folder name has been modified by FRS. This can lead to failed logins, incorrect policy application, or application errors.
• Administrative Confusion: It becomes difficult for administrators to determine which folder is the legitimate, current version and which is the conflicting duplicate. This adds overhead in managing the replicated data.
• Potential for Data Inconsistency: While FRS’s conflict resolution prevents data loss in the short term, a large number of unresolved conflicts can indicate deeper replication problems. If conflicts are not cleaned up, users or administrators might accidentally modify data in the “wrong” folder, leading to inconsistencies across the replica set.
• Increased Storage Consumption: The conflicting folders consume disk space unnecessarily.
• Symptom of Deeper Issues: The appearance of many _NTFRS_ folders often signals underlying problems, such as incorrect replication topology, network issues causing excessive latency, or improper administrative procedures (like incorrect restore methods). Addressing the symptoms (cleaning up the folders) is necessary, but investigating and resolving the root cause is essential to prevent recurrence.

Preventing Future Conflicts¶

Preventing FRS name conflicts is always better than having to resolve them. Here are some best practices:

• Avoid Simultaneous Manual Creation: Refrain from manually creating folders with the same name and path on multiple FRS members simultaneously. If you need to seed data, create it on one server and allow FRS to replicate it naturally.
• Follow Strict Restore Procedures: If you need to perform an authoritative or non-authoritative restore involving an FRS replicated share (especially SYSVOL), meticulously follow Microsoft’s documented procedures, paying close attention to stopping the FRS service on partners and setting correct BurFlags values before restarting the service. Incorrect restore procedures are a major cause of widespread conflicts.
• Monitor Replication Health: Regularly monitor FRS event logs on all replica members for errors or warnings that indicate replication problems. Use tools like Ultrasound (if available for your OS version) or analyze debug logs to understand the replication status.
• Ensure Adequate Network Connectivity: Ensure stable and sufficiently fast network connections between FRS replica partners to minimize replication latency.
• Consider Migrating to DFSR: If your environment allows, plan and execute a migration from FRS to DFSR for SYSVOL and other replicated data. DFSR uses a more robust algorithm for conflict resolution and is generally more resilient and efficient than FRS.

By understanding how FRS handles conflicts and following careful procedures, administrators can minimize the occurrence of _NTFRS_ suffixed folders and maintain a healthy replicated environment.

We hope this detailed explanation helps you understand the issue of FRS adding suffixes to folder names and provides a clear path to resolving it. Have you encountered this issue in your environment? Share your experiences or any tips you’ve found helpful in the comments below!