<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.</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>.</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 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 view larger.<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>
</ul>
More details about the Robocopy scripts are available <a href="http://redmondmag.com/Articles/2008/07/01/The-Secrets-of-Sysvol.aspx">at Redmondmag</a> and further discussion of the benefits of DFSR migration are available <a href="http://blogs.technet.com/b/askds/archive/2010/04/22/the-case-for-migrating-sysvol-to-dfsr.aspx">on Technet</a>.