Upgrading Your SYSVOL to DFS-R Replication

Many papers and KB articles have been posted about the "old-style" SYSVOL replication, or FRS, dealing with the various problems and the difficulty of recovering from an FRS disaster. In light of this, the product group has finally come up with a solution to the "woes of FRS": DFS-R SYSVOL replication. With Windows Server 2008, SYSVOL replication can now rely on DFS-R.

Why would you want this?

Let's look at some reasons why. First, the Branch Office Guide states a soft limit of 1200 DCs per domain due to a limitation of FRS. Not that it won't work, mind you, but that the difficulty of recovering from a disaster with that many or more DCs approaches impossibility... or at least extreme difficulty.

It's also much faster. FRS replicates the whole file when it changes, while DFS-R only replicates the changed bits. For example, if you have a 5MB file in which the spelling of a single word is changed, with FRS the whole 5MB must be copied. With DFS-R the copy would only be a few KB (I don't know exactly how much off-hand, but from what I've been told it's quite small).

Migrating to DFS-R is done in four stages: Start, Prepared, Redirected, and Eliminated. (The most detailed information is contained here: https://blogs.technet.com/filecab/archive/2008/02/08/sysvol-migration-series-part-1-introduction-to-the-sysvol-migration-process.aspx)

So: how do you do it? It's actually quite simple. First, your domain must be in native 2008 mode. This requires that all your DCs be upgraded to Windows Server 2008. Included in Windows Server 2008 is a utility called dfsrmig. The next thing you should do is check your SYSVOL replication health. Do this with the command:

 repadmin /ReplSum

You will need to deal with any issues that are shown before you proceed with migration to DFS-R. Once you're ready, you can begin the migration by typing:

 dfsrmig /SetGlobalState 1

What this does is set a flag on your DC (the one you started with) saying that you'd like to start the DFS-R migration process. This change then replicates out to all the other DCs in the domain. You cannot proceed to state 2 until all DCs have reached state 1. You can check this by running the command:

 dfsrmig /GetMigrationState

You can slowly go through the migration by issuing the command to set the state to 2 and then to 3 one at a time, or (I found this out recently) you can start the whole process by going straight to "2". I don't say "3", although you could do that, because you'll want to sit at 2 for a while and verify that your new "SYSVOL" redirection is working fine. Once you're fully satisfied that the redirection is working properly in the environment, you can issue the "3" command (or Eliminate) and this will clear all the information from the old SYSVOL directory.

The great thing is that at any stage prior to Eliminated, you can roll back to the beginning. For those procedures, you would simply step the state back to 0 and it will slowly trickle back to the original state. You can only do this if you haven't gone to the Eliminate stage. And of course, if you do roll back, you'll need to copy all the new or updated files back into the old SYSVOL directory from the SYSVOL_DFSR directory.

If you do decided to implement DFS-R for SYSVOL or any other purpose, be sure to manage and monitor the system - and configure it properly to begin with!

Here are some tips to avoid slow replication with DFS-R: https://blogs.technet.com/askds/archive/2007/10/05/top-10-common-causes-of-slow-replication-with-dfsr.aspx

Comments

• Anonymous
  January 01, 2003
  Sounds like a mouthful, doesn't it. Say it out loud and try to immitate Sean Connery while you say

• Anonymous
  January 01, 2003
  I'm not on the DFSR team, but I've done some implementations for customers. I'm a consultant based in the East Coast.

• Anonymous
  January 01, 2003
  Hello, NotesFromTheField Nice to see a new blogger around! So you work with DFSR? --Malu (from Filecab blog)

• Anonymous
  June 26, 2015
  Thank You, this was most helpful.