What is DFS?

DFS, or the Distributed File System, is a feature of Windows Active Directory which allows you to create virtual pathways to file shares. The purpose of which is to obfuscate from the end-user the location of the actual file share.

Why is this a good thing?

1. Provides a consistent pathway/experience for the end-user: by creating this virtual pathway, the end-user can always use the same pathway for all of their file needs.
2. Hide the server shares: by camouflaging the location of the actual file share, and allowing the DFS system to link to it behind the scenes, you give yourself the ability to repoint those links at will. Should a file server go down, or need to be replaced, you simply repoint the link. The end-user continues to use the same file path they always do, not realizing that the file server they’re accessing today is different from the one yesterday. This is a CRITICAL element of software packaging – applications deployed via Group Policy *do not* like it when the location of their installation path changes. Anyone publishing their own packages *needs* to understand DFS and be using it.
3. Redundancy: each DFS file path can be linked to multiple file shares. Should one of those file shares go down, the end-user is simply pointed at the remaining file shares. Rebooting one of your file servers suddenly no longer affects your end-users.
4. Replication: DFS has the built-in ability to monitor the different links to a particular DFS pathway and replicate changes amongst them. So when user X goes to your DFS path and ends up changing a file in ShareA, DFS will make sure that the same changes are made in ShareB and ShareC. You don’t have to worry about keeping the files on your redundant file shares consistent.

DFS is actually two components now – DFS Namespaces and DFS-R. In the original version of DFS, which was released with Server 2003, file replication was managed as a part of the FRS (file replication system; this is now dedicated to replication of the SYSVOL content on the domain and nothing else). While this system was pretty good, it had some serious flaws, ones which tended to bite system administrators at one point or another, and it bit hard. The FRS system could replicate lots of large files; but give it hundreds of thousands of tiny ones (most scientific applications – Matlab, for example) and it freaked out. When it died, it got confused and died big-time, usually taking over a large chunk of your disk space. Most of us gave up on DFS replication after we were forced to try and fix replication on any share holding any number of gigabytes of data. It just wasn’t worth the grief. We switched to Robocopy, a replication utility that found a lot of favor once we all got fed up with DFS. Most of us are still using it.

With the release of Windows 2003 R2 (and continued, and I’m told improved, in Windows 2008), DFS was split into DFS Namespace and DFS-R, which replaced FRS as the replication agent. The flaws were found and corrected. A few of us thought that simply upgrading to R2 gave us the use of this new engine. As it turns out, that’s not the case. New DFS roots will automatically use it. The rest of us will need to convert – though we may wait for the DC upgrades to 2008 this summer, and skip a step.

It needs to be noted that DFS doesn’t store files – its not a file server. It’s merely a way for Active Directory to guide your users to your file shares. To give an example, \\wolftech.ad.ncsu.edu\files\ is one of the DFS roots on the WolfTech domain (\\wolftech\files\ will get you to the same space as workstations on the domain are aware of the full path, but software packagers should always use the full, rather than shorter path – but that’s a completely different topic to discuss later). It was the first actually. On it you’ll find many links, one of which is \\wolftech.ad.ncsu.edu\files\ncsu\packages\. The \packages\ folder doesn’t actually exist – it points to three of my file servers (two physical, one virtual VM server), each of which contain a hidden file share. I’m able to keep these shares hidden from the world because I know their true path will never be needed by our workstations nor end-users – they both follow the public DFS pathway. In addition, this allows me to reboot any of my file servers and not worry that I might prevent, or interrupt, one of your workstation from installing the newest Matlab software package.

Each of the member colleges of WolfTech have been granted a DFS root. \\wolftech.ad.ncsu.edu\engr\, \\wolftech.ad.ncsu.edu\cnr\, etc. The DFS root is the only level of the DFS tree that can truly be delegated. In the past, we were going to provide paths under the \\wolftech\files root for each of the units that joined the domain. Administration of that design proved flawed, however, as more and more of you joined – without delegation, I would have to create and maintain your DFS links for you. After fielding a few of those requests for CNR, it became clear it wasn’t a scalable option. So each college instead have been provisioned a root which they have full control over. There are some performance limitations on DFS, though, so it is not recommended at this time to create DFS roots for every unit in WolfTech. Colleges will be expected to manage the DFS links for their departments. Many of you have small enough colleges that this may have already been the plan. For the larger of you, it will require some coordination on your part. Sorry to have passed the buck, but I think you’ll find that having this control is worth the responsibility for your department’s needs. I’ll note that it’s not a large burden -- you’ll find that DFS paths don’t change often; mostly only when a server needs to be replaced, or a file share needs to be moved, which don’t tend to occur frequently.

The OU Admins for each college have been granted permissions over the domain DFS Replication groups (some colleges were not on the domain at the time of this writting -- should you find yourself without the permissions mentioned here, please just drop the Domain Administrators an email). This will allow the College OU Admins to create and manage these as needed. Should a department require DFS Replication to be setup for them, the College OU Admins will create the group, then can delegate the management of the group to the departmental OU Admins – so day to day updates can still be delegated down to the departmental level.

After some basic testing, it doesn’t look like the colleges will have the ability to step on each other’s toes, so no worries there. I will note that should OU Admin “A” creates a new replication group for CALS, the first thing he’ll need to do is delegate control of that group to the entire CALS OU Admin group – otherwise only s/he and the Enterprise Admin (aka, me and Billy) will have access to edit that group.

How do you control your DFS root? In your MMC you’ll find a snapin for “DFS Management”. Here you’ll find the controls for both your DFS Namespaces and DFS Replication. Remember that the Replication is optional. I would encourage new users of DFS to use it rather than Robocopy – it’ll be simpler to manage, and you shouldn’t run into the same issues I mentioned earlier. When you first open this snapin, you’ll not see your namespace. Right click on Namespaces and choose to “Add Namespaces to Display”. You’ll be shown a list. I believe you’ll only see your own. Select it and off you go.

Rather than stepping you through all the steps, I’ll leave you with some reading materials. These articles should get you off and running.

• http://www.windowsnetworking.com/articles_tutorials/Implementing-DFS-Namespaces.html (I’ve already handled everything in “Creating a Namespace”; follow the steps after).
• http://www.windowsnetworking.com/articles_tutorials/Implementing-DFS-Replication.html