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):

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:

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

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:

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:

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.