• Run repadmin /replsum 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 (dcdiag /e /v), but to check just FRS health on all of them at once, you can run dcdiag /e /test:FRSEvent.
• 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.
• 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 a maintenance window is NOT required. AD users and groups can still be created, modified, and deleted normally since those don’t live in SYSVOL.
• First we can verify that we’re still using FRS with dfsrmig /getglobalstate. This is a command we’ll come back to several times. You’ll see the message below when FRS is still in use.
• To start the migration run dfsrmig /setglobalstate 1. 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.
• The file copy operations can take some time, especially if you use SYSVOL as a deployment share for software installations. You can run dfsrmig /getmigrationstate 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.
  
• Keep spamming the dfsrmig /getmigrationstate until you get the message below which tells you the environment has stabilized at state 1. Click to expand.
• Now you’re ready to run dfsrmig /setglobalstate 2. This will change the \\<domain controller>\SYSVOL share from C:\Windows\SYSVOL to C:\Windows\SYSVOL_DFSR.
• Run dfsrmig /getmigrationstate some more to track domain controllers as they update their SYSVOL shares. Click to expand.
• This message means the environment has stabilized at state 2. The new SYSVOL is live at \\<domain controller>\SYSVOL with the same contents and replicating with DFSR. The old SYSVOL still exists and is still replicating with FRS. Click to expand.
• 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. dfsrmig /setglobalstate 3 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.
• 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.

More details about the Robocopy scripts this process runs are available from Rhonda Layfield at Redmondmag and further discussion of the benefits of DFSR migration are available from Ned Pyle on Technet.

The post ENABLING ACTIVE DIRECTORY DFS REPLICATION appeared first on eGroup.