Domain DFS recreates link folder every hour when FRS is enabled at the DFS Root (259033)

SUMMARY

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

Optionally, FRS can replicate files and folders between Windows 2000 servers that host the same fault-tolerant Microsoft Distributed File System (DFS) root or child replicas.

This article describes the effect of morphed or conflicted directories in the shares of DFS root targets where FRS replication is enabled on the DFS root.

MORE INFORMATION

When you use the Distributed File System snap-in to create a domain DFS root or link, the DFS service creates an empty directory tree that mirrors the DFS root and link names and hierarchy on each DFS root target server. If you enable FRS replication at the DFS root, FRS replicates the directory created by DFS to all other root target computers that participate in the FRS replica set. The code in DFS to create this directory is executed on each DFS root target.

Additionally, DFS polls Active Directory for any configuration changes one time each hour and recreates these link directories. To do so, the code first deletes any existing file or folder with the associated name, and then it creates a new file or folder. When FRS finds the newly created folder, it replicates the folder to the other targets, where it finds a preexisting folder with the same name that was created by DFS. To handle this directory name conflict, FRS appends a suffix in the form "NTFRS_xxxxxxxx" to the end of one of the directories, and then FRS finishes the replication action. The problem is analogous to an administrator creating identically named directories on each member of the FRS replica set, where each directory has a unique file ID. The behavior as of Windows 2000 Service Pack 3 is for FRS to morph the names of duplicate directories created on each DFS target to protect the original directories. This behavior repeats every hour, so the root directory slowly fills with morphed directory names, which is a maintenance problem for the administrator.

Enhancements in Windows 2000 Service Pack 2 prevented the recreation of a new directory during each hourly poll by DFS if the root or link directory already existed.

While referrals to root and link targets continue, morphed directories are visible to users viewing the root of the DFS namespace. To work around this issue, use one of the following methods:

Do not enable replication at the root of a DFS. Instead, create targets at the link level, and then enable FRS replication for those targets.
Periodically clean up the directory

Enabling FRS replication at DFS links has the following advantages over enabling replication on DFS roots:

You can take individual link targets offline when a new target is added to the DFS link. This prevents clients from connecting to targets that are in the process of completing their initial FRS synchronization from an existing member.
You can take link targets offline when their data is inconsistent or in an error state.
Data is divided up so new FRS replication members can source data in a priority determined by the administrator
Data is divided up so existing members can source data in priority determined by the administrator if they encounter replication errors and must resource FRS replicated content.

When you take a target for a DFS link offline, DFS clients that do not already have a referral for that target do not discover it. Specifically, DFS root targets do not hand out referrals for offline link targets. Taking targets offline prevents DFS clients from connecting to a link target that is still in the process of replicating data or is in some kind of error state.