<div>Along with the Active Directory Recycle Bin, a tremendous benefit to upgrading your Active Directory functional levels to 2008 R2 is the ability to use DFSR replication between domain controllers. With 2003 and earlier, domain controllers used File Replication Services to replicate directories like SYSVOL. FRS has several drawbacks such as having to retransmit entire files and minimal self-healing capabilities.</div>
<div></div>
<div>With 2008 and later versions, you can migrate from FRS to DFSR (Distributed File System Replication). DFSR can replicate only changed bits (useful for large logon scripts, company wallpaper, install files, and other items commonly found in the SYSVOL directory) and has more robust self-healing capabilities for conflict resolution.</div>
<div></div>
<div>Domains that are installed with 2008 or later functionality will have DFSR enabled by default. This procedure is only necessary for domains and forests that have been upgraded from 2003.<!--more--></div>
<ul>
	<li>Run <strong>repadmin /replsum</strong> to verify replication health. Troubleshoot any problems found before proceeding. We'll want a clean bill of health for FRS replication before we retire it. Ideally you'll want all aspects of your domain controllers to be happy (<strong>dcdiag /e /v</strong>), but to check just FRS health on all of them at once, you can run <strong>dcdiag /e /test:FRSEvent</strong>.</li>
	<li>Upgrade all domain controllers to Windows Server 2008 or 2008 R2 and raise your domain functional level to 2008 or higher. Enabling DFSR replication is a per-domain setting and will not affect other domains in a forest. Also be aware that enabling DFSR is not a reversible change, but once you begin you will have several opportunities to stop if you change your mind.</li>
	<li>Make your coworkers aware that during the migration there should be no changes made to Group Policy, logon scripts, application deployments, or anything else that lives in SYSVOL or NETLOGON. Realistically nothing bad should happen if they forget and edit something like Group Policy, but it's highly probably that the change they make could be overwritten or rolled back. A DFSR migration can take less than an hour for a small environment or an afternoon or more for a larger environment. All operations can be performed during normal business operations so <strong>a maintenance window is NOT required</strong>. AD users and groups can still be created, modified, and deleted normally since those don't live in SYSVOL.</li>
	<li>First we can verify that we're still using FRS with <strong>dfsrmig /getglobalstate</strong>. This is a command we'll come back to several times. You'll see the message below when FRS is still in use.<a href="http://egroup.jasonmangone.com/wp-content/uploads/2012/03/1.png"><img class="alignnone size-full wp-image-6164" src="http://egroup.jasonmangone.com/wp-content/uploads/2012/03/1.png" alt="" width="532" height="108" /></a></li>
	<li>To start the migration run <strong>dfsrmig /setglobalstate 1</strong>. By default SYSVOL lives in C:\Windows\SYSVOL. Setting the migration state to Step 1 instructs all domain controllers to create a C:\Windows\SYSVOL_DFSR directory and run robocopy scripts to copy the contents over.<a href="http://egroup.jasonmangone.com/wp-content/uploads/2012/03/2.png"><img class="alignnone size-full wp-image-6165" src="http://egroup.jasonmangone.com/wp-content/uploads/2012/03/2.png" alt="" width="506" height="186" /></a></li>
	<li>The file copy operations can take some time, especially if you use SYSVOL as a deployment share for software installations. You can run <strong>dfsrmig /getmigrationstate</strong> to list the status of each domain controller. It will list the names of any domain controller that isn't in sync with the global state we set before (state 1, "Prepared"). Click to expand.
<a href="http://egroup.jasonmangone.com/wp-content/uploads/2012/03/3.png"><img class="alignnone size-medium wp-image-6166" src="http://egroup.jasonmangone.com/wp-content/uploads/2012/03/3-300x76.png" alt="" width="300" height="76" /></a></li>
	<li>Keep spamming the <strong>dfsrmig /getmigrationstate</strong> until you get the message below which tells you the environment has stabilized at state 1. Click to expand.<a href="http://egroup.jasonmangone.com/wp-content/uploads/2012/03/4.png"><img class="alignnone size-medium wp-image-6167" src="http://egroup.jasonmangone.com/wp-content/uploads/2012/03/4-300x32.png" alt="" width="300" height="32" /></a></li>
	<li>Now you're ready to run <strong>dfsrmig /setglobalstate 2</strong>. This will change the \\&lt;domain controller&gt;\SYSVOL share from C:\Windows\SYSVOL to C:\Windows\SYSVOL_DFSR.<a href="http://egroup.jasonmangone.com/wp-content/uploads/2012/03/5.png"><img class="alignnone size-full wp-image-6168" src="http://egroup.jasonmangone.com/wp-content/uploads/2012/03/5.png" alt="" width="501" height="130" /></a></li>
	<li>Run <strong>dfsrmig /getmigrationstate</strong> some more to track domain controllers as they update their SYSVOL shares. Click to expand.<a href="http://egroup.jasonmangone.com/wp-content/uploads/2012/03/6.png"><img class="alignnone size-medium wp-image-6169" src="http://egroup.jasonmangone.com/wp-content/uploads/2012/03/6-300x72.png" alt="" width="300" height="72" /></a></li>
	<li>This message means the environment has stabilized at state 2. The new SYSVOL is live at \\&lt;domain controller&gt;\SYSVOL with the same contents and replicating with DFSR. The old SYSVOL still exists and is still replicating with FRS. Click to expand.<a href="http://egroup.jasonmangone.com/wp-content/uploads/2012/03/7.png"><img class="alignnone size-medium wp-image-6170" src="http://egroup.jasonmangone.com/wp-content/uploads/2012/03/7-300x38.png" alt="" width="300" height="38" /></a></li>
	<li>Now we're ready to complete the final step. Up until this point, the whole process is reversible, but now we'll be making some permanent changes. <strong>dfsrmig /setglobalstate 3</strong> tells domain controllers to go ahead and delete the old SYSVOL folder and stop running FRS completely. If you're using FRS to replicate anything else besides SYSVOL and NETLOGON (and you'll know if  you are - you can't do it by accident) that replication will also stop. If you're not comfortable moving to state 3 just yet feel free to wait a while and reassure yourself that nothing has blown up. Technically your environment can live in state 2 forever, but you won't reap any of the benefits such as lower bandwidth replication until you reach state 3 (in fact bandwidth will be a bit wasted since you're replicating everything twice). When you're ready, move to state 3.<a href="http://egroup.jasonmangone.com/wp-content/uploads/2012/03/8.png"><img class="alignnone size-full wp-image-6171" src="http://egroup.jasonmangone.com/wp-content/uploads/2012/03/8.png" alt="" width="527" height="143" /></a></li>
	<li>Your domain controllers are now in state 3. Any new domain controllers you promote will automatically use DFSR by default. This is the same message you'll see on domains that were natively installed with domain functional levels at 2008 or higher since they use DFSR out of the box. Click to expand.<a href="http://egroup.jasonmangone.com/wp-content/uploads/2012/03/9.png"><img class="alignnone size-medium wp-image-6172" src="http://egroup.jasonmangone.com/wp-content/uploads/2012/03/9-300x38.png" alt="" width="300" height="38" /></a></li>
</ul>
More details about the Robocopy scripts this process runs are available from <a href="http://redmondmag.com/Articles/2008/07/01/The-Secrets-of-Sysvol.aspx">Rhonda Layfield at Redmondmag</a> and further discussion of the benefits of DFSR migration are available from <a href="http://blogs.technet.com/b/askds/archive/2010/04/22/the-case-for-migrating-sysvol-to-dfsr.aspx">Ned Pyle on Technet</a>.