Section 3.10. The Distributed File System

3.10. The Distributed File System

The Distributed File System (DFS) is a technology that allows several distinct filesystems, potentially on multiple servers, to be mounted from one place and appear in one logical representation. The different shared folders, which likely reside on different drives in different server machines, can all be accessed from one folder, known as the root node. Link nodes serve to point from shared folder to shared folder to mimic a directory tree structure, which can be rearranged and altered according to a particular implementation's needs. DFS also allows the clients to know only the name of the share point and not the name of the server on which it resides, a big boon when you field help-desk calls asking, "What server is my last budget proposal located on?"

DFS root nodes come in two basic flavors: standalone root nodes, which store the folder topology information locally, and fault-tolerant root nodes, which store the topology structure in Active Directory and thereby replicate that information to other domain controllers. In this case, if you have multiple root nodes, you might have multiple connections to the same datait just so happens that they appear in different shared folders. You even can set up two different share points to the same data on two different physical servers, because DFS is intelligent enough to select the folder set that is geographically closest to the requesting client, saving network traffic and packet travel time. (The redundant share points also replicate around the network, which is another layer of backup protection.) In either case, you can replicate a DFS root by creating root targets on other servers in the domain. This provides file availability when the host server becomes unavailable.

First, let's look at some definitions used in DFS. A DFS root can exist either as a standalone entity or as a member of a domain. In either case, the root collects links to all shared paths in the network and publishes those links to users. The childlike links maintain a mapping of a friendly name to a concrete path in a server's filesystem. When a user accesses the DFS link, the service navigates the mapping and points the user to the destination path. A DFS target, also known as a replica, refers to either roots or links and serves to combine two identical shares on different servers into one link automatically, with synchronization and replication all a part of it.

The major difference between domain-based roots and standalone roots is that of replication. By default, fault-tolerant roots publish their information in Active Directory into the Partition Knowledge Table (PKT) . The PKT is distributed to all domain controllers in a domain, which makes it easier for users to connect to shares. In a standalone root environment, only a single server can keep track of the DFS topology, so if that server is unavailable for any reason, user interruption will occur.

You can expand a DFS topology by adding a link to the root. There's no functional limitation on the number of levels your topology can have, although Windows permits no more than 260 characters in any file path. A new DFS link can refer to a target (with or without subfolders) or to an entire disk. If you have adequate permissions, you also can access any local subfolders that exist in or are added to a target.

DFS clients, as mentioned earlier, get referrals to the closest server that houses a copy of the data they request. These referrals are "sticky," meaning that they persist until the next system restart. This is done to protect data integrity in environments where replication takes place over great geographic distancesbecause it can take hours or even days before all DFS changes are replicated to all servers within a domain. If a user had a referral to data stored on a server in Chicago, and then caught a flight home to New York and plugged his laptop back in, the most up-to-date data might not be available to him if changes to DFS in Chicago had not replicated back to New York at that point. The bottom line is that it's safer for the client to go back from where he came from to get data, at least until system reboot.

Windows Server 2003 Standard Edition supports only one DFS root per server. Other editions, namely the Enterprise and Datacenter editions, support multiple DFS roots on the same machine.

3.10.1. Adding a DFS Root and Link

The following procedure creates a simple DFS share (which consists of a root node and a child link):

Click Start, and then select All Programs Administrative Tools Distributed File System.
Select the Create a standalone DFS root radio button, and enter the server name on which the DFS root should be located.
To make an existing share participate in the DFS system, select the Use Existing Share button and select the share from the list. To construct a new share that will use DFS, select the Create New Share option, and complete the path to the share and the share's official name. Click Next.
Enter the name for the DFS root volume on this screen. (Note that if you selected Use Existing Share on the previous screen, this option will be grayed out, and you'll be able to enter only a comment.) Click Next.
Verify the settings on the screen, and click Finish to create the new DFS root.
To create the child link, highlight the root node and press the New Child button.
Enter the friendly name you want users to see for this link in the Link Name box. Enter the path to the folder in the Send the user to this shared folder link, and add an optional comment for the users in the Comment box.
Click OK to finish.

3.10.2. Adding DFS Links and Targets

You should not use the steps I outlined earlier for adding a target in a DFS system: that is added when you first create the DFS link.

The folder you specify as the target in step 3 of the following procedure must be an existing shared folder. Additionally, if a link points to another domain's DFS, it cannot point to any other targets. To add a target in this case, you must add it to the targeted DFS system, and not to the link itself.

To add a DFS link, follow these steps:

Click Start, and then select All Programs Administrative Tools Distributed File System.
Enter a name for the link, and then enter the path for the new link. Use the Browse button to navigate through a list of your existing shared folders.
Enter a comment for administrative purposes to help identify the purpose of this link.
Enter a value for the length of time this link should be cached on the client side, and then click OK when finished.

To add a target to a DFS link, follow these steps:

Click Start, and then select All Programs Administrative Tools Distributed File System.
Enter the path to the target. Use the Browse button for a list of existing shared folders.
If you are using a domain-based DFS system, to enable Windows to automatically replicate files for the target, check the Add this target to the replication set checkbox. (If you do not check this checkbox, you need to manually migrate files to your target from other targets.)
Click OK when complete.

3.10.3. The Basics of DFS Replication

During the previous wizard, you might be prompted to configure replication. By clicking Yes, the Configure Replication Wizard is opened. Hold that thought for a moment while we look at how DFS replication works; then we'll come back to the wizard and step through it.

If you have a nondomain-based DFS system, replication is purely a manual exercise for the administrator, pushing files from a master to slaves in a single-master fashion. (One link replica is designated the master.) On the other hand, in a domain-based DFS system, if your data resides in shares on servers running Windows 2000 Server or Server 2003 with NTFS drives, replication is automatic and is multimaster. This means changes are pushed from all servers to all servers, and are orchestrated by an algorithm that takes into account server load, geography, and network link costs.

Now, back to the wizard. Bypass the welcome screen and come to the master selection page. Here, you choose a temporary "master" share to start replicationtemporary because, as I just described, all subsequent replications within Server 2003 are a multimaster process, much like domain controllers. Click Next, and the next screen enables you to choose the replication strategies available. You can choose from the following:

Ring
Hub and spoke
Full mesh
A custom topology of your construction, where you map connections yourself at a later point

DFS automatically configures the first three for you, so they're simple and likely to work better with DFS than any other custom topology. You should use the fourth strategy only if you really know what you're doing. Click Finish once you've made your selection, and you will return to the DFS Management console screen.

3.10.4. Managing DFS Systems

You might need to perform a few common administrative tasks on your DFS structure. This section will describe the procedure for each task.

3.10.4.1. Connecting to different roots

Inside the DFS management console, click the Action menu, and then select Show Roots. The Show Root dialog box will open. You can either directly type in the name of the DFS root or the name of the server that hosts it, or you can browse in the bottom box through a list of the current domain and all domains that trust your current domain to find the server or root.

3.10.4.2. Checking DFS node status

From within the management console, open the root and expand it so that you can see the shares under it. Right-click the share in which you're interested, and select Check Status. The icon in the right pane will change depending on the status; you also can look in the table under the Status field for an update as well. The two possible values are Online and Offline, represented by a green checkmark icon and a red "X" icon, respectively.

3.10.4.3. Removing child nodes

If you have a failed node, you can remove the link from your DFS system so that clients will not get a faulty referral. This does not remove the actual data or the physical share from the server; in effect it just takes the share out of the DFS table of contents so that users aren't pointed to a broken link. To do so, just right-click the share in the left pane from within the management console and choose Delete Link.

3.10.4.4. Downing replica members

You can enable and disable DFS referrals so that users aren't pointed to a server that's unavailable or malfunctioning. This is useful for server maintenance periods when you don't want users to have their own connections terminated, but you don't want to remove the entire replica set from the DFS and readd it when your maintenance window is complete. To disable referrals to a replica, just right-click the share and select Enable/Disable Referral. This action will set the status to whatever is the opposite of the current setting.

3.10.5. DFS in Windows Server 2003 R2

DFS in Windows Server 2003 R2 is broken up into two components:

DFS Namespaces , which is basically everything you knew of DFS before R2 came along, minus replication. With DFS namespaces, you can group shared folders stored on different servers and present them to users in one coherent tree, making the actual location of the files and folders irrelevant to the end user.
DFS Replication , which revolutionizes replication in the original version of DFS and is almost a complete and total rewrite of the File Replication service (FRS) introduced in Windows 2000 Server. DFS Replication is a multimaster replication engine that supports scheduling, bandwidth throttling, and compression. Most notably, DFS Replication now uses an algorithm known as Remote Differential Compression (RDC), which efficiently updates files over a limited-bandwidth network by looking at insertions, removals, and rearrangements of data in files, and then replicating only the changed file blocks. There is substantial savings to this method.

Figure 3-27 shows a basic flow that DFS transactions proceed through in R2.

Figure 3-27. The basic flow of DFS in Windows Server 2003 R2

Let's walk through this. When an end user wants to open a folder that's included within a DFS namespace, the client sends a message to the namespace server (which is simply a machine running the R2 version of DFS). That machine will then refer the client to a list of servers that host copies of those shared folders (these copies are called folder targets). The client machine stores a copy of that referral in its cache and then goes down the referral list in order, which is automatically sorted by proximity so that a client is always using servers within his Active Directory site before traversing to machines located outside of his current location. That's mostly DFS as you know it now, with some improvements in terminology and target selection.

But let's crack the nut a little further and see the sparkling technology in R2 that is DFS replication. At first it seems normal: you can store a folder on a server in New York and the same folder on a server in London, and replication will take care of keeping the copies of the folders synchronized. Users, of course, have no idea that these folders are kept in geographically disparate locations.

However, the replication mechanism is incredibly optimized: it determines what has changed about two files and then, using remote differential compression, only sends the differences between the files and folders over the wire. Over slow WAN links and other bandwidth-metered lines, you'll see a real cost savings. You really see the benefits when relatively minor changes to large files are made. According to Microsoft, a change to a two megabyte PowerPoint presentation can result in only 60 KB being transmitted across the wirewhich equates to a 97% percent savings in terms of amount of data sent. Delving a bit further: according to the product team, they "ran a test on a mix of 780 Office files (.doc, .ppt, and .xls) replicating from a source server to a target server using DFS Replication with RDC. The target server had version n of the files and the source server had version n+, and the two versions differed with significant edits. The percent savings in bytes transferred was on average 50 percent and significantly better for large files."

Of course, with DFS you also get the fault tolerance benefit of "failing over" to a functional server if a target on another server isn't responding. Prior to R2, there wasn't a simple way for you to instruct clients, after a failure, to resume back to their local DFS servers once the machines came back online. A new hotfix, which works in conjunction with R2 and Windows XP and Windows Server 2003 as a client, allows you to specify that clients should fail back to a closer, less costly server when services are restored.

Although R2's DFS components are two separate technologies, when they're used in tandem they solve some real problems companies face. Take branch office backup, for instance. Instead of tasking your administrators in these offices with tape drive maintenance, backing up, storing data off site, and everything else associated with disaster avoidance, simply configure DFS to replicate data from the servers in the branch office back up to a hub server in the home office or another data center. Then, run the backup from the central location. You are more efficient in three ways:

You save on tape hardware costs.
You save time through the efficiencies in DFS replication.
You save manpower costs because your IT workers at the branch offices can move onto other problems and not spend their time babysitting a backup process.

What about software distribution? The new version of DFS really excels at publishing documents, applications, and other files to users that are separated geographically. By using namespaces in conjunction with replication, you can store multiple copies of data and software at multiple locations throughout the world, better ensuring constant availability and good transfer performance while still making it transparent to users where they're getting their files from. DFS replication and namespaces automatically look at your AD site structure to determine the lowest cost link to use in the event that a local namespace server isn't available to respond to requests.

The UI for managing DFS has also improved over the more clunky and less put-together MMC snap-in in Windows 2000 and the original version of Windows Server 2003. The new snap-in offers you the ability to configure namespaces and other abilities that previously only existed through the command-line interface.

DFS Replication is not supported for SYSVOL replication in Windows Server 2003 R2, so don't try to disable FRS and create replication group for SYSVOL. At this point, FRS and DFS Replication can coexist on the same member server or domain controller.

3.10.5.1. Creating a namespace

In the MMC snap-in for DFS in R2, the Namespaces node in the left pane contains any namespaces you may create as well as any existing namespaces you add to the console display. Beneath each namespace in the tree you'll find a hierarchical view of folders. Folders with targets use a special icon to differentiate them from ordinary folders without targets. We'll use this UI to create a new namespace, add some folders and folder targets, and then eventually set up replication between two machines to demonstrate the functionality.

In order to create a new namespace, the following conditions must be met:

You need at least two servers, both running Windows Server 2003 R2. You'll need the DFS system installed, which you can do through Add/Remove Windows Components as described earlier in this chapter.
If you want an AD-integrated topology, you will need to have deployed Active Directory on your network. For the purposes of this exercise, I'll assume that you have NOT deployed AD yet, and we will focus on the non-AD specific DFS features.

To deploy a new namespace, launch the DFS Management snap-in, and then right-click on the Namespace node in the left pane and select New Namespace from the context menu. Then:

On the Namespace Server page, shown in Figure 3-28, enter the name of the server which will host the namespace. Then click Next.

Figure 3-28. The Namespace Server screen
On the Namespace Name and Settings page, enter a name for your new namespace. I've named my new namespace Files, as you can see in Figure 3-29.

Figure 3-29. The Namespace Name and Settings screen
The Namespace Type screen appears, as shown in Figure 3-30. Choose Standalone namespace from the list, and then click Next.

Figure 3-30. The Namespace Type screen
On the Review Settings and Create Namespace screen, depicted in Figure 3-31, verify the settings you've chosen and then click Next.
The Completion screen appears; this is shown in Figure 3-32. Close the wizard after confirming that there were no errors during the completion process.

3.10.5.2. Adding and managing folders and folder targets in a namespace

It's very simple to add a folder to an already existing namespace. In the left pane, right-click on the name of the namespace and choose New Folder. You'll see the New Folder screen, as shown in Figure 3-33. Enter the name of the folder you'd like to add in the Name box.

If you'd like, you can go ahead and add some folder targets to this folder at the same time you're creating the folder. Recall that folder targets allow you to redirect a specific DFS namespace folder to a physical location on a shared folder structure. For example, if I wanted to have the "Office" folder appear in my DFS namespace structure, I could create a folder target, attached to a DFS folder, that pointed to the actual location where Office resides. Folder targets are just a way to clean up and simplify the appearance of files and folders within your network.

Figure 3-31. The Review Settings and Create Namespace screen

Figure 3-32. The Confirmation screen

If you want to move or rename a particular folder, simply right-click on the folder within the left pane in the console and select Move or Rename and complete the appropriate action. The DFS service handles the rest; moving is a particularly seamless action.

Figure 3-33. Adding a folder

To add a folder target, click the Add button, and then the Add Folder Target screen will appear, as shown in Figure 3-34. Enter the correct path to the location you want to folder target to reference, and then click OK.

Figure 3-34. Adding a folder target

You can add multiple folder targets to any one folder as a way of maintaining fault tolerance. That way, if a user is directed to a particular machine that is down, the client will work down the referral list it received from the namespace server and try another server that hosts a copy of the folder target. You can adjust how this referral is done, within or outside of a site, by right-clicking on the name of the namespace in the left pane of the console and selecting Properties. Navigate to the Referrals tab, and then select the appropriate option from the Ordering Method box. You can choose "lowest cost," which takes into account sites and site links as configured within Active Directory, "random order," which does exactly as it sounds, or "exclude targets outside of the client's site," which simply removes the ability for clients to access targets exterior to their current site.

Note that when you try and add an additional target to a folder that already has just one target, the DFS MMC snap-in will prompt you and ask if you'd like to create a replication group to keep the two targets synchronized. And that's what the next section is all about.

3.10.5.3. Creating a replication group for a folder

Again, if you have more than one folder target for fault tolerance purposes, you'll want to configure a replication group so that the contents of the folders are kept synchronized and users have a transparent interface to the items contained therein. A replication group is a set of servers that sends or receives updates of replicated folders. When you enable DFS Replication on a folder with targets, the servers that host the folder targets are automatically made members of the replication group, and the folder targets are associated with the replicated folder. All other properties, like the name of the group and the name of the folder, are identical as well.

You can use DFS Replication in both stand-alone and domain-based namespaces. Therefore, you can complete this task regardless of the type of namespace you created in "Task 1: Create a Namespace." You do, however, need to have Active Directory deployed and you need to be a member of the Domain Administrators group. (I'll cover AD in Chapter 5; if you want to wait until you've read there before continuing with this section and procedure, that's not a problem.)

To create a replication group for a folder:

In the left pane of the console, right-click on the folder in the namespace you created, and select Replicate Folder.
The Replication Group and Replicated Folder Name screen appears, as shown in Figure 3-35. Enter a name for the replication group (most people keep this as the same name as the namespace folder path) and then also enter the name of the replicated folder. Click Next to continue.
The Replication Eligibility screen appears, as shown in Figure 3-36. In this step, the Replicate Folder Wizard determines which, if any, folder targets are able to participate in replication. Make sure that at least two of these targets, located on different servers, are eligible, and then click Next.
The Primary Folder Target screen appears, as shown in Figure 3-37. Here, specify the folder target that will be used as the primary member of the replication groupi.e., the member whose content is authoritative; the master copy of the content. Click Next to continue.
The Topology Selection screen appears, as shown in Figure 3-38. On this screen, you can choose how the connections among the server members of the replication group will be deployed. If you have three or more members in your replication group, you can choose the hub and spoke methodology, in which hub members are connected to other members and data originates from the center and moves outward to the spokes. Your other choices are full mesh, in which each member replicates all data with all other members; and no topology, where you can create your own topology. For this example, choose full mesh, and then click Next to continue.

Figure 3-35. The Replication Group and Replicated Folder Name screen

Figure 3-36. The Replication Eligibility screen

Figure 3-37. The Primary Folder Target screen

Figure 3-38. The Topology Selection screen
The Replication Group Schedule and Bandwidth screen appears, as shown in Figure 3-39. Here, you can choose whether to replicate full-time (24/7) or on a specific schedule. To set the schedule, click the Edit Schedule button. You can also choose how much bandwidth to use during replication, which helps keep more bandwidth available for regular usage. You can choose Full from the list to drop all bandwidth concerns and replicate everything as fast as possible. Click Next to continue.

Figure 3-39. The Replication Group Schedule and Bandwidth screen
The Review Settings and Create Replication Group screen appears, as shown in Figure 3-40. Verify all of the settings you have chosen; if you need to change something, click the Back button. Otherwise, click Next, and the wizard will set off creating your replication group.
The Confirmation screen appears. Make sure there are no errors, and then click Close.
The Replication Delay screen appears, as shown in Figure 3-41. This message appears to let you know that there may be an initial delay while the configuration of the replication group is propagated among all of the members of the group. Click OK to acknowledge.

Your replication group is now set up. If you add a file or make other changes to the folder target location on one machine, DFS Replication will pick up the change and replicate it to all of the other folder targets on the other machines within the replication group, thus enabling a seamless interface to files and folders for your users as long as they use Explorer to find files through the namespace you created.

Figure 3-40. The Review Settings and Create Replication Group screen

Figure 3-41. The Replication Delay screen

From the Replication node, you can manage all of the properties and settings of DFS Replication, such as the schedule, bandwidth throttling, the topology, and others. On the Replicated Folders tab in the details pane of the MMC console, you can also view the namespace path that corresponds to the replicated folder or folders.