DFS Replication not right for all environments

Despite the many improvements made to DFS in Windows Server 2003 R2, there are still limitations to the service, and you should keep these in mind in order to be certain that DFS is appropriate for your environment.

Requires Free Membership to View

Perhaps the most important limitation is this: DFS Replication is suitable for environments that can tolerate a certain loose consistency between different copies of a particular document. Even given the performance enhancements of the Remote Differential Compression (RDC) replication, there will still be a slight amount of inconsistency between servers in a replication group as a change is replicated between them.

Consider the following situation. You've configured a replication schedule that only allows for DFS replication between 11 pm and 5 am for a site whose WAN link is nearly saturated during the day. If a user makes a change to a file stored on SERVERA at 1 pm on a Tuesday, and another user accesses the copy of that file that's stored on SERVERB at 2 pm on the same day, the second user will not see the changes that were made on SERVERA. The changes have not replicated yet.

Even if you allow DFS replication to take place 24x7, limitations of network transmission speed mean that SERVERA's copy of a document might not be precisely in sync with SERVERB's copy at any given second. If you're working with documents that have zero tolerance for this type of loose consistency, you might want to consider a document collaboration solution (one that allows for document check-in and check-out) such as Microsoft Sharepoint. But in most cases, the replication improvements offered by R2 DFS will provide an easy means of synchronizing files across multiple locations.

But what happens if two people create a replication conflict by managing to modify the same file at the same time while working from two separate servers? Similar to Active Directory replication, the RDC algorithm resolves conflicts by taking the "last writer wins" approach: Whichever file was modified most recently is the one that will win the conflict and be replicated throughout the namespace. The "losing" file will be renamed and stored in a Conflict and Deleted folder on the server that processed the conflict, and details of the file will be stored in a ConflictandDeletedManifest.xml file. This folder has a default quota of 660MB, and will be automatically purged when its size reaches 90% of that limit.

About the author: Laura E. Hunter (CISSP, MCSE: Security, MCDBA, Microsoft MVP) is a senior IT specialist with the University of Pennsylvania where she provides network planning, implementation and troubleshooting services for business units and schools within the university. Hunter is a two-time recipient of the prestigious Microsoft "Most Valuable Professional" award in the area of Windows Server-Networking. She is the author of the Active Directory Field Guide (APress Publishing).

More information on this topic:


This was first published in December 2006

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.