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.