Tips and Tricks

DFS to the Rescue

The power of this simple, useful tool is more evident when used during server consolidations or migrations.

Many organizations use Windows’ Distributed File System (DFS) to replicate certain shared folders or to make accessing user directories more straightforward (after all, \\DFS\ Users\Don is easier to remember than \\NT254LAS\DJONE$). But DFS can also be a useful tool during server migrations and server consolidation.

The idea behind DFS is to allow users access shared folders using a consistent namespace that has nothing to do with where the data actually resides. So a friendly UNC, such as \\DFS\Projects\Marketing\BigSale might really point to a shared folder named \\ServerA\MktSaleShare.

Ease-of-use is nice, but DFS has some internal trickery going on that makes it even more useful. For instance, DFS doesn’t act as a gateway for clients; it simply provides a referral. In other words, clients who access \\DFS\Projects\Marketing\BigSale hit the DFS server, and are redirected to \\ServerA\ MktSaleShare. Because of that redirection, DFS can provide references to any shared data, not just Windows shared folders. For example, \\ServerA\MktSaleShare might really be a NetWare server or Linux file server; clients don’t care, so long as they have the software necessary to access that type of data.

During a migration, you can use DFS to maintain a consistent namespace: After you migrate the data in \\ServerA\MktSale Share to a Windows server, simply update the reference in DFS to point to the new Windows-based shared folder (which might be \\WinServer2\Marketing5). Users can continue to access the same UNC they did before, and DFS handles the redirect to the new server, all behind the scenes.

DFS can serve a similar purpose during a server consolidation. By having users access DFS-based UNCs, rather than accessing server UNCs directly, you can play the old shell game behind the scenes: Users get their data from \\DFS\Users\DonJ, even though today that data physically resides at \\NTServer\Don and tomorrow it’ll be moved to \\Win2003A\DonJ. Shuffle files and shared folders around all you want—DFS maintains an orderly façade and prevents you from having to notify users of the change.

DFS can also provide easier access to frequently used Read-only files (such as Microsoft Office network installation points). A single DFS UNC can point to multiple, identical UNCs on the back end. Since DFS is site-aware, users are directed to the UNC that’s physically closest to them whenever possible. So all of your Office users can get their software from \\DFS\Applications\Office, and they’ll be automatically referred by DFS to the nearest copy.

One caveat: Don’t put a copy (called a DFS replica) on the server that’s actually hosting the DFS root. DFS has a hardcoded preference for replicas on the root, and users will always be directed to that copy, no matter how many others exist on the network.

Installing DFS
Make sure your clients have the latest DFS client installed, and you’ll get the best performance. Doing so can be tricky, though, because the DFS client is usually embedded in other software. On Windows 9x and NT systems, install the Directory Services Client; Windows 2000, XP and Windows Server 2003 contain the latest code either in the base OS or in the most recent service pack.

The one point of failure in this system, of course, is the DFS root server: If it goes down, it can’t hand out referrals to clients, so the whole system collapses. You can get better odds on a stable DFS environment by installing the DFS root on a small Windows cluster. DFS is natively built for clustering, and the cluster will ensure that even a fairly massive hardware failure won’t take your DFS system offline for long.

About the Author

With more than fifteen years of IT experience, Don Jones is one of the world’s leading experts on the Microsoft business technology platform. He’s the author of more than 35 books, including Windows PowerShell: TFM, Windows Administrator’s Scripting Toolkit, VBScript WMI and ADSI Unleashed, PHP-Nuke Garage, Special Edition Using Commerce Server 2002, Definitive Guide to SQL Server Performance Optimization, and many more. Don is a top-rated and in-demand speaker and serves on the advisory board for TechMentor. He is an accomplished IT journalist with features and monthly columns in Microsoft TechNet Magazine, Redmond Magazine, and on Web sites such as TechTarget and MCPMag.com. Don is also a multiple-year recipient of Microsoft’s prestigious Most Valuable Professional (MVP) Award, and is the Editor-in-Chief for Realtime Publishers.

comments powered by Disqus

Reader Comments:

Sat, Apr 30, 2005 Reiner Saddey Berlin, Germny

Don cautions to the effect of the server hosting the dfs root going down. Well, thats not a real problem, as the root itself can (and should) be distributed to several servers. This feature (and quite reliable automatic data replication as well) is available when the root is created within the Active Directory. The DFS root then no longer resides on a particular server, but is being hosted within an AD domain instead, with root replicas ready to be spread to domain members.

Mon, Aug 2, 2004 Matthew Richmond, VA, USA

Goo article, could be more detailed in explanation of intersite transports (FRS) and could be more clear on differentiating AD and Standalone DFS roots, particularly in explaining the advantages of AD integration

Fri, Jul 23, 2004 Anonymous Anonymous

this is great information, however a few things failed to get mentioned. (1) macintosh operating systems do not have a native DFS client and (2) DNS issues arise via VPN connections.
Yes, there is a reg-hack for the DNS issue, but unless you're lucky enough to run into someone that has had the issue, documentation is shoddy. As for the Macs. ADmitMAC is a real help with this as well as AD integration with the macs into a 2000 environment.

Fri, Jul 23, 2004 SBWorks Anonymous

You can't use offline files from DFS share in a Windows 2000 server environment. Unless they fixed that in 2003, that is limitation in a highly-mobile, laptop equiped office.

Fri, Jul 23, 2004 SBWorks Anonymous

You can't use offline files from DFS share in a Windows 2000 server environment. Unless they fixed that in 2003, that is limitation in a highly-mobile, laptop equiped office.

Fri, Jul 23, 2004 johan belgium

can anyone explain this caveat?
can anyone tell how to read this out of the DFS 'blob'
One caveat: Don’t put a copy (called a DFS replica) on the server that’s actually hosting the DFS root. DFS has a hardcoded preference for replicas on the root

Tue, Jul 6, 2004 charmx Anonymous

get tips & tricks

Fri, Jul 2, 2004 Anonymous Anonymous

Installing Dfs as AD-based rather than standalong means that the replicas as registered in AD. Should one Dfs root server go down, clients are redirected to other replicas automatically for that root tree. This is very useful in presenting end-users across a domain with a single share to mount (\\blah.com\global) so that they only have to remember a single drive letter to go to.

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.