Get Going with Dfs

Microsoft Dfs provides a great way to let users easily access data that's stored on multiple remote computers. Through Dfs, your users can view and access folders as a single set of shares through a familiar, unified folder hierarchy, even when those resources are in different domains or physical sites. If you've resisted using Dfs because you were afraid it might be complex, fear not: Setting up Dfs is a straightforward process, and using it is even easier. I'll help you get started with Dfs by explaining how it works and guiding you through a typical Dfs configuration. After you start using Dfs in your organization, you'll wonder how your users ever functioned without it.

How Dfs Works
The basic element of the Dfs structure is a share that represents the root of the Dfs hierarchy. Through Dfs, these shares form a single, contiguous namespace. Client systems use familiar methods—such as a mapped drive or a Universal Naming Convention (UNC) path—to connect to the Dfs root. After a client connects to the Dfs root, the Dfs structure appears to be a regular share that contains subfolders that users can navigate and search. Each subfolder that's displayed under the Dfs root is actually a link to a share (a link target) anywhere on the network. Dfs automatically redirects the client that's accessing the share to the data's actual location. As Figure 1 shows, the folders that the user sees represent Dfs's redirection of the user to alternate shares on servers A, B, and C. The link target can be any system that uses a network file system that you can access via a UNC path—such as Windows, Novell NetWare, and UNIX or Linux (i.e., NFS) machines.

Dfs provides two types of roots: standalone and Active Directory (AD)–integrated. These types differ in how they store Dfs data. With standalone roots, the Dfs hierarchy, which consists of the various links to network shares, is stored in the Dfs server's local registry. Because of the way the information is stored, it can't be replicated to other Dfs servers, which means that if the sole Dfs server hosting the Dfs root becomes unavailable, the entire Dfs hierarchy is unavailable to all clients on the network. Should the Dfs server become unavailable, clients can still access shares on the servers directly; they just can't use Dfs to access them. You must use standalone Dfs if your environment doesn't have AD or if the Dfs administrators aren't domain administrators and thus can't be granted the authority (i.e., given access to the DFS-Configuration object in the domain AD partition's System container) to manage Dfs.

Windows 2000 Server and later also support AD–integrated Dfs (aka domain-based or fault-tolerant Dfs). With AD–integrated roots, Dfs information is stored primarily in AD, although the actual Dfs servers still cache copies of the data in memory to minimize Dfs server requests to domain controllers (DCs), thereby reducing Dfs network overhead. You can use an AD–integrated Dfs root only when the Dfs server is a member of a domain; however, the Dfs server doesn't have to be a DC. Essentially, you should use standalone Dfs when you don't have an AD domain, have more than 5000 links, or have legacy clients on your network. For more information about the differences between standalone and AD–integrated Dfs, see the sidebar "Dfs Differences," page 59.

After you've decided which type of Dfs you'll use, you need to set up links and link targets, which contain the data that Dfs will make available to clients. As I mentioned earlier, a link target is the actual resource to which Dfs redirects the client when it accesses a link. A link can have multiple link targets, which helps to provide load balancing and fault tolerance: If a share on one server is unavailable, Dfs redirects the client to another copy of the data. The actual link target that the client uses depends mainly on the client's site. Essentially Dfs is a site-aware service, which means that, by default, when a link target exists in a client's local site, Dfs directs the client to that local target.

Configuring Dfs
Now that you've got a handle on Dfs essentials, you're ready to start setting up Dfs. Your first task is to create a Dfs root. You have two methods for doing this: either by using the Microsoft Management Console (MMC) Distributed File System snap-in or by executing the dfsutil.exe command-line utility. Here we'll use the snap-in method, which is a bit easier than the command-line tool when you're just getting started with Dfs. As you become familiar with Dfs, you'll probably want to use dfsutil.exe—for example, in a script that populates your Dfs hierarchy with links. Note that on Windows Server 2003, Standard Edition and Win2K Server, a server can host only one Dfs root. Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition can host an unlimited number of Dfs roots.

To create a new Dfs root by using the Distributed File System snap-in, perform the following steps:

At this point, clients can connect to the Dfs namespace by using the UNC path \dfstest.testshared; they don't need to know anything about which servers are hosting Dfs. Clients running Windows NT 4.0 with Service Pack 6a (SP6a) or later can connect to a domain-based Dfs namespace. However, clients running Windows 98 can access standalone Dfs namespaces but must have the AD client extension installed to access a domain-based namespace. Microsoft Windows Preinstallation Environment (WinPE) instances can access only standalone Dfs namespaces.

To benefit from a domain-based Dfs namespace's fault-tolerance capability, you need at least two Dfs servers to host the Dfs namespace. Follow these steps to configure a second Dfs host server:

The Dfs root will now display multiple servers that act as root targets for the namespace, as Figure 3 shows. Clients can now connect and will be directed to one of the Dfs namespace root targets. However, users who access a root target will see an empty folder because you haven't defined any links yet. The next step, then, is to add some links and link targets that will redirect clients to useful content.

At this stage, to finish your Dfs configuration, you need to create a list of the shares in your organization, determine which data is the same on the different shares, and decide how you want the data to be known to the client (i.e., the folder name and comment). After you've identified this information, you can create the links by performing these steps:

Now when clients access the Dfs namespace, they'll see a folder. When users open the folder, they'll be redirected to a share and will see the content that's stored under the share.

Say you also have a documents folder on a server in a remote office. Instead of creating a separate link to the folder (e.g., LondonDocuments), you can add another link target to the existing link. Setting up multiple link targets is another means for providing fault tolerance. If one link target fails, Dfs can redirect clients to an alternate copy of the data. To add another link target to an existing link, follow these steps:

When you view your link, you'll notice that two link targets that are enabled. When clients browse to this link, Dfs directs them to one of the targets. You can now repeat the previous steps to configure all the links and targets you require to populate your Dfs structure.

As you've seen, multiple link targets can exist for a link. This capability poses an obvious question: Won't the content be different on the different link targets, meaning that Dfs could randomly redirect clients to different link targets, and thus the clients would see different files? Because multiple targets for a link are effectively separate shares on separate servers, no mechanism exists for keeping the targets' contents synchronized. Therefore, it's entirely possible for the various link targets to have different content, so that a client could browse to a folder, access data, return to the same folder later, but be redirected to an alternate link target and see an entirely different set of data. (However, this scenario is unlikely, as I explain in the Web-exclusive sidebar "Fine-Tuning Dfs Redirection" at http://www.windowsitpro.com, InstantDoc ID 45621.) Fortunately, Win2K Server and later Dfs implementations include File Replication Service (FRS), which DCs use to keep their Sysvol shares synchronized. Dfs uses FRS to synchronize the targets of a link that's part of a domain-based namespace. FRS provides various replication options, such as continuous replication, which allows replication of changes in near real time, and replication at certain times of the day. (Windows 2003 R2 will include a brand-new version of FRS just for Dfs.) I provide the steps for configuring Dfs-based file replication in "Setting Up Dfs-Based File Replication." If you have standalone Dfs and require synchronization, you need to use a file-synchronization tool such as the Windows resource kit Robocopy utility to provide that capability.

Dfs Demystified
As you've seen, Dfs greatly simplifies access to network resources for end users and, with AD enabled, provides a measure of fault tolerance. To make sure Dfs works optimally for your organization, you'll need to decide what files need to be replicated and, if necessary, tweak Dfs's redirection. I've covered the essential information you need to get started with Dfs. For more in-depth information about Dfs, check out Microsoft's Distributed File System and File Replication Services Web site at http://www.microsoft.com//windowsserver2003/technologies/fileandprint/file/dfs/default.mspx.