Dfs vs. FRS

Admin wants to maintain snappy performance with user profiles and home folders with a Windows 2003 network upgrade.

Bill: We have three sites that are their own Windows NT 4.0 domain and subnet. One connection between sites is a 11Mbps WLAN, and the other a 2Mbps fibre link. Some staff remain at one site and others move among all three.

We are upgrading to Windows Server 2003 and would like to change to a single domain over the entire company and sites. We will have a DC at each site. We know this can be done, but what I want is some assistance with user profile and home folder management.

Using Distributed File System and File Replication Service, can we maintain all user profiles and home folders at each site? What if a user creates a 100MB file at one site? Might this cause congestion over the WAN links?

This may be a very simple task to get what we want, but I greatly appreciate any assistance you can lend me.

Get Help from Bill

Got a Windows or Exchange question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to Bill at mailto:boswell@101com.com; the best questions get answered in this column.

When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message but submit the requested information for verification purposes.)

Ben: It is certainly possible to maintain local copies of user home folders and profiles on different servers, then use Dfs to point the users at local copies of the files. This localization relies on Active Directory sites defined in DNS, and properly configured IP subnet objects, so make sure your site configuration is correct and that all Service Locator (SRV) records are present in DNS. Also, Windows Server 2003 Dfs does a much better job of corralling Dfs users into the correct site. Windows 2000 sometimes points Dfs users at a randomly selected site rather than the local site.

Using FRS to replicate the files is also possible, but there are some drawbacks. FRS is a perfectly acceptable replication engine for the small files in Sysvol, but when you ask it to replicate large volumes of data across slow or congested WAN links, the results can get a little problematic.

Take that 100MB file you mentioned as an example. Not only would FRS replicate the file when it's first created, each time a user modifies the file in any way, FRS will replicate a full copy of the file again. If a user opens and closes the file a dozen times in 10 minutes, then 10 copies of the file will replicate across that 2Mb link. FRS is a little simpler to configure in Windows Server 2003 because you can define custom replication topologies, but the engine just isn't intended for moving many, many MBs of files.

One way to avoid the problem of replicating very large files is to impose fairly drastic quotas on home folders and profiles. This forces users to save their data files in the production environment somewhere, such as their department folder. You can argue that this is the best use of storage, but users often want their own little cubbyhole and they don't believe that you can protect their privacy in a folder under the main department folder. Also, it tends to defeat the advantage of using local copies of files via Dfs.

Some organizations have tried to make FRS work for large volumes and then turned around and deployed a third-party solution for replication. Here are some examples (and, by no means, extensive):

The other thing to watch out for in Dfs is file locking. If User A opens a file on one server and User B opens the same file on a different server, then the last user to save the file will overwrite the work done by the other user. For this reason, Dfs works well for user home folders and profiles, but don't use it for common data. And keep the file locking in mind if you come in as an administrator and make changes to profiles or home folders while users are logged on.

Hope this helps.

About the Author

Contributing Editor Bill Boswell, MCSE, is the principal of Bill Boswell Consulting, Inc. He's the author of Inside Windows Server 2003 and Learning Exchange Server 2003 both from Addison Wesley. Bill is also Redmond magazine's "Windows Insider" columnist and a speaker at MCP Magazine's TechMentor Conferences.

comments powered by Disqus

Reader Comments:

Wed, Oct 28, 2009

DFS lacks a central feature important for a collaborative environment where inter-office file servers are mirrored and data is shared: File Locking. Without integrated file locking, using DFS to mirror file servers exposes live documents to version conflicts. That is, a colleague in Office A can open and edit a document at the same time a colleague in Office B is working on the same document. In such a scenario, DFS will only save the changes made by the person closing the file last. The surest and simplest way of eliminating version conflicts when using DFS is to add a true file locking solution - one that offers, at a minimum, real-time detection of file use and immediate remote locking. Such as Peerlock. This assures that when a file is open at location A, all other versions - say local copies at various branch offices - are locked down, preventing anyone from opening and revising it. When the file closes, the file lock is immediately released and ready for synchronization. PeerLock Software adds file locking to your DFS environment eliminating Version Conflict. Below is the link to this solution: http://dfsfilelocking.com While many customers enjoy the benefits of adding file locking to DFS, please bear in mind the potential synchronization backlogs while using DFS. For a true solution that offers both real-time file locking AND real-time replication, thus eliminating version conflict and providing a fail-safe collaborative framework, evaluate our complete PEER Collaboration Package. PeerSync Collaboration is a Full File Collaboration solution including Real-Time file Synchronization and Real-Time File Locking. For more info go to: http://www.peersoftware.com/solutions/high_availability/server_collaboration_for_file_systems.aspx

Thu, Feb 9, 2006 Danny Brea, CA

The author is correct regarding DFS replicates entire file, that's Windows Server 2003 Release 1. For block level replication that danniel mentioned, it's a new function in the Windows Server 2003 Release 2. Also, I am having trouble with user profiles in DFS, so Ben, you might want to test the configuration before hand.

Tue, Jun 8, 2004 Howard Marks Anonymous

What you didn't discuss was that the questioner really wanted DFS with MUILTI-MASTER replication. If the user creates a 100MB file when working at site a it should replicate to site b AND if heshe creates a new 50MB files whjile working at site b it should replicate to site A.

FRS can't do this. Neither can double-take

Sun, Jun 6, 2004 Gill S'Pore

The article did not provide a definite answer to the question.

Wed, Jun 2, 2004 NCDOT SA Anonymous

I am unable to find any information regarding file locking and DFS statements made in the article 'DFS vs. FRS'. The statement in questions is "The other thing to watch out for in Dfs is file locking. If
User A opens a file on one server and User B opens the same
file on a different server, then the last user to save the file
will overwrite the work done by the other user. For this reason,
Dfs works well for user home folders and profiles, but don't
use it for common data." This implies that DFS is the culprit for data loss due to file locking when the actual problem lies with FRS. Please correct me if I am wrong.

Wed, Jun 2, 2004 Yehoshua Anonymous

Microsoft has many theories about upgrading domains but I wouldn't bet that they all work. We had a rough time upgrading domains to one forest.

We reused the same exact domain name only that the top of our hierarchy now became just another tree in the forest. For example, "x.y.com", which was the top of the hiearchy now joined the domain "y.com"

We found thaty the most practical way around the problem of retaining the old large local user profiles was to go to each computer (thousands), disjoin them from the old domain, rejoin them to the new domin, then copy their old user profiles to their new current profile. All of this since the old SID was replaced by the new one, and as stated in the article, "users often want their own little cubbyhole" .

It's tedious work and takes much time, but it works. All other utilities we tried didn't work. I just wonder if, when push comes to shove, either DFS or FRS would make any difference anyway and it might be necessary to reconfigure each computer.

Add Your Comment Now:

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

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.