DFS-R: The new replication engine in Windows Server 2003 R2

This year at TechEd I did two presentations: One on DFS-R and the other on host hardening in Windows Server 2003 SP1.

DFS-R I think is great. It replaces FRS as the replication engine for file level replication with a block mode replicator thats very efficient in replicating only the changes to the file rather than the whole file itself. An important note to make is that in R2 its not doing SYSVOL but will in Longhorn Server timeframe along with "On demand" replication of files etc. A word of warning: Dont even try to get it to do SYSVOL as it will screw things up and PSS wont be able help you when it does! 🙂

Other than that the whole UI has been improved with more of a direct UI linkage between DFS and DFS-R even though under the covers they're essentially mutually exclusive tools with loose linkages. In R2, DFS hasnt essentially changed as all the improvements to it were made in SP1, but the UI improvements in combination with DFS-R as the replicator of files makes it much more usable and way more efficient.

It works like this:

1. Change is made to the NTFS USN Change Journal

2. DFS-R reads this changes and filters out any files you dont want to replicate

3. It writes the entry into the DFS-R ID table to manage the change

4. It notifies sync and sends the change.

5. The target server's sync engine recieves the update and compares it with the DB on its end and computes (via MD4 hashes) the changes

6. It fetches a staging file based on changes in the staging location (Under the hidden DFSR Private directory)

7. Rebuilds the file based on what it already has of the file and the computed changes from the staging directory into the preinstall dir (again in the DFSR Private directory)

8. Once its done with the new file it overwrites it into the final location.

Important Note: Last Writer Wins! If a change is made while this process is occurring then a Conflict is triggered and instead of this file being written to the target location its written to the Conflict directory (in DFSR Private) instead. For this reason we do not recommend scenarios where multiple concurrent writes are occuring. The main scenarios are data replication to branch sites and data replication for backup purposes to central hubs.

If an NTFS journal wrap occurs, which can happen and caused FRS to have problems, is no longer an issue in DFS-R. All DFS-R does in this instance is to work out whats changed on both ends and rebuild its DB.

More to come!


Comments (0)

Skip to main content