Simplify Resource Navigation With Dfs
The Distributed file system (Dfs), when properly implemented, can help your users get where they want to go. But its usefulness doesn’t stop there.
We’ve all encountered it. The LOOK. You know the look I’m talking about.
It’s the look you see on a user’s face when you try to explain how to
map a drive to a network resource.
This look combines the bewildered confusion of someone lost in a strange
city, the helplessness of someone facing an inscrutable math quiz in junior
high, and the frustration of someone trying to reach an object that lies
Trying to master the simple act of mapping a network drive has driven
users to tears, career changes and curses so blue that even sailors get
uncomfortable. (I’m an ex-sailor and I’ve had angry users flat-out embarrass
me.) The source of all this frustration isn’t so much the tedious creation
of a mapped drive, although the process could be a lot simpler. Much of
the frustration comes from not knowing what server and resource to select.
After all, the files for a given user’s department might be scattered
over a half-dozen servers with helpful names such as NT-SRV-S32 or ACCT-03
or, worse yet, BORIS and NATASHA.
Even if a user knows that his or her files are on a specific server,
the cantankerous browse window in My Network Neighborhood might decide,
“Today’s Thursday so I won’t show any servers on the fourth floor.” Browsing
problems are guaranteed to send users into a tizzy and Help Desk operators
to their desk drawers for antacids.
The solution is to eliminate server-centric resource locations by abstracting
network resources into a logical structure that users can easily navigate.
After all, when you press the Send button on your cell phone, you don’t
have to tell the system what tower you want to use for transmissions.
When you think about it, a file system provides this sort of logical
abstraction. Imagine how difficult it would be to open a file if you had
to know its initial Logical Cluster Number and the LCN of each fragment.
It would be truly useful to have a network file system that abstracts
individual network resources in the same way that a standard file system
abstracts clusters on a hard drive.
This is the raison-d’etre (as we say in southern New Mexico) of the Distributed file system (Dfs). Using Dfs, you can create elegant and simple folder
arrangements for nearly all the data in your network. Like most things
that “simplify” the user experience, implementing Dfs means that we, as
systems administrators, face a little more complexity—but the payoff is
worth the work.
A file system consists of individual files with index structures
called directories or folders. The building blocks of Dfs are links and
share points. As I’m sure you know, a share point is simply a local folder
exposed by the LanManServer service as a network resource. LanManWorkstation
clients use Server Message Block (SMB) commands to connect to share points
and view the files and folders inside. Dfs aggregates share points into
a logical structure called a Dfs volume. Figure 1 shows an example volume
in the Dfs management console, Dfsgui.msc.
|Figure 1. A typical Dfs Volume, as seen through
In a file system such as NTFS, the file system root consists of a folder
record, which contains configuration information that defines the start
of the file system hierarchy. In Dfs, the root of a volume is defined
by a share point and the configuration information that defines the Dfs
link structure takes the form of a Partition Knowledge Table (PKT). In
a standalone Dfs, the root share resides on a single server with the PKT
information stored in the Registry of that server. If the server crashes,
the Dfs volume is unavailable. In a domain Dfs, the root share resides
on one or more servers and the PKT information is stored in Active Directory.
As long as you have one root server and one domain controller, users have
access to the Dfs volume.
The PKT contains a set of links that define UNC paths to network shares.
A link has a name independent of the share at which it points. For example,
a link called Accounting could point at a share with the UNC path of \\W2K-SRV-47\Acct.
You can see the contents of the PKT using the Dfsutil tool from the Windows
2000 Support Tools.
Finding a Dfs Volume
Think of a Dfs link as a referral mechanism. As shown in Figure
2, when a Dfs client first connects to a domain Dfs volume, it obtains
PKT information from a domain controller. The Dfs client uses this information
to locate a server hosting a replica of the Dfs root volume. This server
gives the client a referral to the target server that hosts the shared
resource. The client then makes a standard network connection to the shared
resource. All this happens transparently to the user.
|Figure 2. The process of finding a Dfs volume,
from the client point of view. Note that this is transparent to the
The final client connection to the target server need not be a standard
Windows SMB connection. It could be a NetWare Core Protocol (NCP) connection
to a NetWare server or an NFS (Network File System) connection to an NFS
mount on a Unix host. Both of these require a suitable client redirector
running on the desktop.
By structuring a set of Dfs links that mirrors the logical structure
of data in your organization, you give your users a well-ordered place
to find information rather than forcing them to scurry from server to
server like shoppers in a cheap department store. In a domain Dfs, clients
connect to the Dfs root using the domain name rather than a server name.
For example, if an AD domain has the name Company. com and the Dfs root
name is Dfsroot, the client can connect to Dfs using the UNC path \\company.com\dfsroot.
You can place a command such as NET USE R: \\company.com\dfsroot in a
logon script, and the users never again need concern themselves with drive
mappings. All they need to do is go to the R: drive to find their files.
Users aren’t the only Dfs beneficiaries. Any work process that requires
hard-coding a network path is much simpler to manage if the process points
at a Dfs folder rather than directly at a server. If you decide that server
S48 is getting overloaded and want to transfer some of the files to server
S57, just modify the Dfs link to point at the new share point. Dfs redirects
clients to the new server seamlessly without them being any the wiser.
It will take a short while for the shift-over. Clients cache PKT entries
with a default time-to-live of 1,800 seconds, or 30 minutes.
If You Call Within the Next 10 Minutes…
As they say in the infomercials—but wait, there’s more! A Dfs link
can point at more than one share point. This makes it possible to have
a redundant backup of files in the share point so that if one server goes
down, the clients get redirected to another server holding a copy of the
The challenge when creating multiple targets for the same link is keeping
the data synchronized between the associated share points. Dfs handles
this synchronization using the same File Replication Service (FRS) that
keeps Sysvol in sync between domain controllers. The FRS configuration
options for Dfs are relatively limited. You can define whether replication
happens automatically and you can enable/disable replication for each
target server. Windows .NET permits specifying the replication topology
for each link with multiple targets. In Win2K, FRS uses the same topology
used for AD replication. Figure 3 shows the replication policy settings
|Figure 3. Replication policy settings for a link
with multiple targets.
When configuring replication, one of the target servers is declared the
Master. When you initiate replication for the first time, FRS copies the
contents of the Master share to the shares on the other servers. Following
that initial replication event, FRS uses multiple-master replication and
immediately copies changes made at any replica to all other replicas.
FRS doesn’t wait for five minutes to send notifications to inter-site
partners or for polling to replicate to intra-site partners. So if you
create a Dfs link with multiple targets and the Master replica contains
a couple of gigs of files, you’ll be watching the usage meter on your
WAN link hit the peg for a while.
FRS faces a dilemma during this initial replication of the Master replica.
What happens if files already exist in the other shares? You don’t want
these files overwritten in case they’re more current than the files in
the Master replica and you certainly don’t want them deleted.
FRS deals with this dilemma by creating a new folder called NtFrs_ PreExisting___See_EventLog
at the secondary servers. Figure 4 shows what this looks like. FRS moves
the contents of the secondary share into this folder then replicates the
contents of the Master share. It’s up to you, as the administrator, to
move files from the NtFrs_PreExisting folder back into the main shared
folder. When you do this, the newly moved files replicate outward to the
other link targets.
|Figure 4. The NtFrs_PreExisting___See_ EventLog
folder holds existing files following initial FRS replication.
If you have a Dfs link with multiple targets, the Dfs clients must
select a target server. The selection method depends on the Dfs server/client
combination. NT 4.0 servers and Win2K servers queried by older Windows
clients return a list of referrals in the order they’re stored in the
PKT. The clients then make a random selection. This load balances the
servers. When queried by Win2K or XP clients, Win2K servers return a referral
list sorted so that replica servers in the local site come first. The
clients select the server at the top of the list. If more than one local
target server exists, Dfs changes the sort order for load balancing.
You can take advantage of this site-centric Dfs operation by putting
user home directories in a Dfs folder with target servers in each major
office. Traveling users access their files from the local replica rather
than going across the WAN to their home servers. If you have Windows 95
or 98 clients, you can install the Dsclient patch from the Win2K Server
CD, which upgrades the Dfs client to make it site-aware.
When a client selects a target server, Explorer displays the selection
in the Properties window for the Dfs folder. Select the Dfs tab to see
the server list. Figure 5 shows an example. If the target server selected
by the client crashes, the client discovers that the server is unavailable
and uses Dfs to select another. This takes only a few seconds. If a user
has open files, they can be saved to the new destination.
|Figure 5. If a target server is down, Explorer
will show the path as unavailable.
There’s a caveat to using links with multiple targets. FRS doesn’t have
a distributed locking feature. This means that a user could have a file
open on server S11 while another user has the same file open on S14. Without
file locking, the last user to save the file will overwrite any changes
made by the other user. You should avoid using links with multiple targets
for anything other than files that have single user or Read-Only access.
This is not as confining as you might think. User home directories are
a good use of multiple Dfs targets, along with redirected My Documents
folders, HTML and .ASP files for Web sites, application installation packages,
and server-based executables.
Dfs = Big Win
Even if you decide not to bother with links with multiple targets,
deploying a domain Dfs is a big win for your users. You’ll probably still
get the LOOK, from your users, but it’ll be for some process other than