Get Going with Dfs

At this point, clients can connect to the Dfs namespace by using the UNC path \\dfstest.test\shared; 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:

1. In the Distributed File System snap-in, right-click the root you created and select New Root Target.
2. Enter the server name that will be the additional Dfs host for the namespace. Notice that the name of the share (e.g., shared) that Dfs will use to host this copy is set and can't be changed. Click Next.
3. If the share name doesn't exist on the target server, you're prompted to select the folder to use, or you can create a new folder on the server, then select it. Make your selection and click Next.
4. At the summary dialog box, click Finish.

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:

1. Right-click the Dfs root and select New Link from the context menu.
2. Enter the name of the link (i.e., the folder that clients will see) along with the share to which the link will redirect the client. (You can change this name or add names later.) You can also enter a comment and specify the amount of time that clients cache this redirection information before they requery the Dfs server, as Figure 4 shows.
3. Click OK.

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:

1. Right-click the link and select New Target from the context menu.
2. Browse to the new share that will also be a target for the link. You can optionally select the Add this target to the replication set check box, as Figure 5 shows. (For more information about replication, see the Web-exclusive sidebar "Setting Up Dfs-Based File Replication" at http://www.windowsitpro.com, InstantDoc ID 45622.)
3. Click OK.

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.