Migrating FRS replicated Sysvol to DFSR

This post will be all about getting rid of the old FRS stuff and updating to the new DFSR. The first question I hear in my mind is “Why do I care when Sysvol is replicating just fine right now?” While that may be true, the real reason would be security, efficiency and scalability that DFSR offers. FRS replicated Sysvol was introduced with 2000 and carried forward into 2003. When Microsoft introduced 2008, the default replication technology was changed to DFS-r. So FRS is only used on domains that have been upgraded from 2000 or 2003. Unfortunately that’s somewhere between 80% to 90% of all domains still using FRS. Even if all of your domain controllers are 2012R2 and your forest and domain functional levels are at 2012, unless you have gone through the process of migrating to DFSR, you are still using FRS.

It has been stated that the version of Windows released after July 2015 when 2003 is permanently retired will no longer have the FRS binaries included. To watch the TechEd on Channel 9 http://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B333#fbid= I have watched it several times and is a really easy and humorous video to watch. It covers DFSR in general but does touch on SYSVOL towards the end.

So what I will walk through is the actual process of doing the conversion and the checks involved with validating the steps, and I will provide the screenshots for my environment.

Overview

Domain Name: DFSRMig.local

Domain and Forest Functional Level:

Servers in the lab environment

Step 1.

In the first step I will demote the 2003 domain controller, and raise the Domain and Forest functional level. If there are more than one 2003 DC’s you will need to demote all of them. The required domain functional level is 2008, but I will go ahead and do the jump to 2012, and you can’t raise the domain functional level while there are still 2003 DC’s in the mix.

*NOTE: Validate that sysvol has been replicated to your other dc’s prior to removing the last 2003 DC and that AD replication is not having any issues. Generally I would transfer the fsmo roles to a new server prior to demoting a DC. This will allow me to validate that the remaining DC’s are aware of the new fsmo role holder.

Step 2. Validate

After a DC is demoted I like to validate a few things just to make sure nothing will come up later.

1. FSMO Role Holder

This is done to make sure the remaining DC’s are aware of any FSMO role holder change that has occurred. As stated this is usually done ahead of time.

1. Replication is successful for all naming contexts

This should be done from each remaining DC or alternatively run the command “repadmin /showrepl * /CSV >> repl.csv” which will create a csv file that can be opened with Excel that will give you the replication status of all naming contexts on all domain controllers. If there are errors, now is the time to address them before any other changes are made.

1. FRS Eventlog

In my lab the warning was caused by the fact that DC1 was still pointing to the 2003 DC for DNS, once corrected everything came back clear:

Running “net share” validates that Sysvol and netlogon is shared

1. Validate DNS

This is done because we demoted a dc and want to validate that the dns records were successfully removed for the DC we just demoted – this is really a cleanup step.

1. Raise domain and forest functional level to at least 2008
   
   
   In my lab I raised them both, in practice domain functional level should be raised and replication will need to occur before doing the forest functional level.

Step 2. Start the Migration

Run the command “DFSRmig /SetGlobalState 1” on the server acting as the PDC emulator. In my case that is 2012R2DC02.

Check the other DC’s for its current state

Check the DFS Replication log for Event 8014

Check the new folder structure:

Step 3. Switch to the Redirected State

At the point that you want to continue the migration, there should be a moratorium on Group Policy changes. Otherwise changes made will not be replicated to the new SYSvol_DFSR folder.

Run the command “dfsrmig /SetGlobalState 2”

Validate the other dc’s are aware of the change

Run “net share” and notice where sysvol is now pointed to

Check for event 8017 on all domain controllers

Step 4. Switch to the Eliminated State

Note: Up to this point it is possible to revert back, running the next step will complete that process and you will no longer be able to revert to FRS. That’s a good thingJ

Validate the other dc’s know the current state

Check the eventlogs on the dc’s for the presence of Event 8019

Validate that the original Sysvol folder has been deleted

Notice that the File Replication Service log that the FRS service has event 13503 stating that the FRS service is stopped. This is expected behavior unless there are other folders other than sysvol being replicated via FRS. In that case the FRS service would start back up.

Additional Reading:

1. The storage blog at TechNet. The Storage Team has a lot more detail about the under the covers of what is happening. All 5 parts are really good.
2. FRS deprecated – http://msdn.microsoft.com/en-us/library/windows/desktop/ff384840(v=vs.85).aspx
3. AskDS Ned Pyle Blog on the case for migrating Sysvol to DFSR http://blogs.technet.com/b/askds/archive/2010/04/22/the-case-for-migrating-sysvol-to-dfsr.aspx

Closure:

While I did mine in an afternoon, mine was in a lab environment and I would expect in a real environment with multiple sites and DC’s that this process will take a few days depending on convergence and topology of Active Directory. The key is to take it slow and verify along the way that everything is working as designed.
Hopefully this blog will help get you through the migration of Sysvol from FRS to DFSR. As always if there are questions or any feedback, comments are welcome.

 

 

 

 

 

 

‹ MOFComp.exe Could not be Found!

How to Get Rid of ADFS Event 415 ›

Tagged with: Active Directory, DFSR, FRS, SYSVOL
Posted in Active Directory, DFS, Migrating, Windows 2012, Windows 2012 R2