Windows Insider

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 just...out...of...reach.

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.

Dfs Structure
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.

Dfs volume
Figure 1. A typical Dfs Volume, as seen through the MMC.

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.

Finding a Dfs volume
Figure 2. The process of finding a Dfs volume, from the client point of view. Note that this is transparent to the user.

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 same files.

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 for Win2K.

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.

After initial FRS replication....
Figure 4. The NtFrs_PreExisting___See_ EventLog folder holds existing files following initial FRS replication.

Site Affiliation
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.

Path is unavailable
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 mapping drives.

comments powered by Disqus

Reader Comments:

Tue, Aug 17, 2004 Anonymous Anonymous

I just wanted to know if there was such a thing as a hub replica. Our Hub master went down and was rebuilt. Ever since then we are suffering the old NtFRSPreExisting directory which causes more trouble than it is worth. In fact replication is no erratic and I fear I'll have to set everything up from scratch. That surely can't be right. Poo again Microsoft...please do large scale testing rather than relying on the big companies to do it for you. Our clients can't be too happy if things like this fail.

Mon, Jun 30, 2003 Hans Italy

Very nice article and thanks for all the valuable comments. Focusing on DFS based on theory without knowing the biggest Real World problem with it would probably have been a bad idea for me.
Thanks again!

Wed, Jan 22, 2003 Armin Linder Germany

I found frs a very helpful tool to avoid shortages in disk space on servers. Because after some time of flawless operation it started to throw away a single directory, then all subdirectories of a directory, and finally the whole frs root directory with everything in it was gone. I saw some of the contents pass through the (still undocumented) ntfrs_preexisting_blahblah directory, before that directory suddently had been gone as well. Haven't had so much disk space on my server for many years. No way to recover yet. Neither the missing data is beeing replicated inward from other servers still holding replicas, nor did copying the data using explorer help: after a couple of minutes everything is gone again. Thanks Microsoft, great software, has recovered pretious disk space.

Armin Linder

Fri, Sep 6, 2002 Anonymous Anonymous

Dfs is great for abstracting data away from a server location Letting FRS replication large amounts of data is a bad idea given the limitations of FRS. My opinion is to use Dfs to structure your data but not to replication data - use a proper tool! The article should talk about Dfs/FRS problems.

Tue, Sep 3, 2002 Stefan Bode Germany

We got the replication working but still have problem with the inital file copy process. Even if the files are there before, it will move all files to NTFRS_preexisting and copy them again. This will hurt on a 1024kbit line and 30GB of data

Sat, Aug 31, 2002 Anonymous Anonymous

My DFS was not working using UNC share names for dfsroot, but using the FQDN path to DFS makes it works. When using UNC naming folders would appear however nothing would be in them. Using FQDN made everthing work. Not sure what happened to client to cause this behavior?

Wed, Aug 14, 2002 Anonymous Anonymous

DFS is new to a lot of NT folks. It is very powerful just grouping shares from different physical locations.

Sun, Aug 11, 2002 Anonymous Anonymous

good to know

Mon, Jul 29, 2002 Joeri Brussels Belgium

Good article. I knew about DFs from my mcse exams and tried it out. It worked out pretty ok, but the replication was giving some problems.
I wasn't aware of problems with that much data.

Thx 4 the info

Fri, Jul 26, 2002 Andy Greenhalgh Shetland, UK

Hi Bill,
I got severely burned by replication with DFS and suffered major loss of face when it failed.

We have several 100Mb LAN sites connected at >100Mb/s by private fibre. I recommended 3 DFS replicas. 1 at each end of the fibre links and 1 approx centrally at our ICT department. The idea was to provide resiliance against server failure or fibre damage.

The setup works fine under lab conditions, with realtively small amounts of data, replication took place OK, and Windows 2000 clients connected to the nearest available replica.

In real world conditions, all hell breaks loose. With somewhere in the region of 20Gb and above of data, when you copy the data onto the master replica for the first time the data starts replicating and then at some point overnight NTFRS fails. When you restart NTFRS you start building up the NTFRS_preexisting directories. Then you discover that the master replica fails before full replication has taken place. The next thing you know is that one of the partial replicas is now replicating back to your master copy and all your original files are now in another NTFRS_Preexisting directory.

While you are fighting this problem you discover that there are a whole group of previously undiscovered windows 95 client PC's on the network and the DFS client will not do down level drive mappings for them.

It's obviously time to pay for some support from Microsoft.

The best I got from them was "Don't use replication with DFS. It doesn't work very well".

Actually the support engineer did try very hard to help me get things working. We tried all the relevant hot fixes. We updated antivirus software, we even completely disabled it just to make sure. Nothing would work

In the end I admitted defeat, told the boss it wouldn't work, and did my best to convince him of the benefits of DFS wthout replication.

At least Microsoft decided that the support call was not chargable.

I guess what I should have done was to build a big enough lab setup to take the 20+ Gb of data. Then expanded it to the full 160Gb, and then added 500 mixed 95, 98 and 2000 clients. And I should have done this before telling the boss it would work!

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.