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:

1. Start the Distributed File System snap-in (its shortcut is located in the Administrative Tools Start menu folder).
2. Right-click the Distributed File System heading in the snap-in's treeview pane and select New Root (if you're using the Windows 2003 version) or New DFS root (if you're using the Win2K Server version). The remaining steps use the Windows 2003 dialog boxes, although the process is basically the same for Win2K Server.
3. At the introduction screen, click Next.
4. Select the type of root you want to create (domain or standalone). Click Next.
5. If you selected a domain Dfs root, you'll need to enter the name of the domain that will store the Dfs information. If you selected a standalone Dfs root, enter the name of the server that will store the Dfs information. Click Next.
6. If you selected domain in step 4, you're now asked to select the server that will host the Dfs root. Select a server and click Next.
7. Enter the name for the new root and any comments to help identify the root, then click Next. When you enter the root name, you'll also see this name displayed as the share name and a preview of its corresponding UNC path, as Figure 2 shows. For example, for a domain-based Dfs share, the pathname is domain name\share. If the share doesn't currently exist, you're prompted to select a local folder on the machine to use for the share. This share doesn't store any real data; instead, it contains link-type objects that point to where the data physically resides. Select a folder to use for the share and click Next.
8. At the confirmation window, click Finish.

   Previous  [1]  2  Next