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.

• By Bill Boswell
• August 01, 2002

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.

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.

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.

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.

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.

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.