Migrating from FRS to DFSR
You’ve migrated your domain to the latest version, but did you really? I’m asking this question because I’ve seen a lot of Active Directory environments migrated but not at 100%. Before making my point here, let me start with a little refresher for those that forgot about SYSVOL.
As you know, domain controllers have a special folder called SYSVOL which holds all the logon/logoff scripts and Group Policy files that you as an administrator create from the Group Policy Management console. The content of this folder replicates to all domain controllers in the domain using a technology called File Replication Service (FRS), or at least it used to in server 2000 and 2003. FRS is gone for a long time now, because starting with Windows Server 2008, Microsoft updated this service to a newer version called Distributed File System Replication (DFSR). As you can probably imagine, Windows 2000 and 2003 domain controllers are not compatible with DFSR. And now you might ask, why do we even bother because those systems are obsolete for a long time?
Well…they are, but if you migrated your domain controllers from a Windows 2003 domain there is a good chance you are still using the old replication service. In order to make use of DFSR, there is a migration path that needs to be followed in order to get rid of FRS from the newer systems. If the domain you have or inherited was built from scratch using server 2008 or later, then no migration is needed because you are already replicating using DFSR.
Identifying the environment
There are a few methods that can be used to identify if your Active Directory environment is still using FRS or is using DFSR.
The first method will be to check if there is any SYSVOL_DFSR folder in the Windows directory. If there is, then you are using DFSR replication service. This method is fast, but is not that accurate because if newer domain controllers were promoted after the migration, they will have the SYSVOL folder here, but replicating using DFSR.
The second method will be to check if the File Replication Service is still running and enabled, and if it is, then you are still replicating using FRS. Here I have a 2016 domain controller which is still using FRS because the migration to the newer service (DFSR) was not done after all the 2003 domain controllers were decommissioned from the domain.
And the third method which I recommend using, is to type the bellow command line:
If you are still using FRS, the following message will be displayed:
DFSR migration has not yet initialized. To start migration please set global state to desired value.
In case DFSR is running then you will get:
Current DFSR global state: ‘Eliminated’
Like everything in IT, before making a move on the infrastructure we need to make sure it is free from errors and working properly. Since we are talking about Active Directory here, we need to make sure the domain controllers are healthy and we don’t have replication problems.
- Check the local state of every domain controller using dcdiag. Use the bellow command to go remotely, so you don’t have to log in on every domain controller. If any errors are displayed, fix them before moving forward.
dcdiag /e /c
- Check replication status between domain controllers.
repadmin /replsum repadmin /showrepl
- Use net share from elevated command prompt on all DCs to check Netlogon and SYSVOL share status.
- Change the domain functional level to be at least at server 2008, or you will not be able to start the migration and a message will be presented when trying to do that.
The current domain functional level is not at least Windows Server 2008. DFSRMig is only supported on at least Windows Server 2008 level domains.
- Backup your domain controllers, especially those that are holding the FSMO roles so you have a roll-back method in case the migration fails somehow.
Migrating FRS to DFSR
Now that we meet the pre-requisites we can move along with the migration, which is done in separate steps that Microsoft calls STATES, and there are four of them:
- State 0 (START state) – This is the actual state on which SYSVOL is replicating right now trough the infrastructure before any migration activities. In this state, SYSVOL is still replicating using FRS.
- State 1 (PREPARED state) – In this state, the content of the SYSVOL folder is copied by the DFSR service into a newly created folder called SYSVOL_DFSR. This is also located under the Windows root. At this stage of the migration process, the main replication engine for the SYSVOL share is still FRS.
- State 2 (REDIRECTED state) – In this state the SYSVOL share is redirected to SYSVOL_DFSR for client use. The DFSR service takes over the old service and becomes the main replication engine for all domain controllers in the domain. FRS is still running and replicating the SYSVOL share.
- State 3 (ELIMINATED sate) – In this state the SYSVOL share is removed and the FRS service is stopped and set to disabled on all domain controllers in the domain.
Before actually starting, make sure all your domain controllers are up and running because if only one of them is off, the migration will get stuck in one of the states mentioned above. Is not that the migration will fail, is just that it will not go on, and you will be waiting a long time to finish and it never will. In case where one of the domain controllers are powered off during the SYSVOL migration, just power it back on and the migration process will catch up. The only exception here is the PDC, which needs to be online all the the time or the migration will fail or not start at all.
To begin the migration, log in on one of the domain controller in the domain -preferably the one that holds the PDC role- and start state 1. This is done by issuing the bellow command:
dfsrmig /setglobalstate 1
After a few minutes, or even a few hours -depending on the number of DCs, the size of the SYSVOL, and the latency between your sites- we will have the SYSVOL_DFSR folder created in the Windows root directory on every domain controller in the domain. If we open it, we can see the SYSVOL share content being copied here.
We can check the migration state using the command:
As you can see, the migration process is still running and before moving to the next state, this one needs to finish successfully.
Check the migration state every now and then, and once we get the bellow message, we can move to state 2.
All domain controllers have migrated successfully to the Global state (‘Prepared’). Migration has reached a consistent state on all domain controllers. Succeeded.
To begin with state 2, run this command:
dfsrmig /setglobalstate 2
Again, we need to check every now and then the migration status using the dfsrmig /getmigrationstate command.
Once step 2 of the migration process is finished, move to the last step, step 3.
This is the last step of the migration process. This is where the SYSVOL share is eliminated and the FRS service is set to Disabled. To begin, run the command:
dfsrmig /setglobalstate 3
This process takes less time compared to the previous two, so we should have our domain controllers in the eliminated state pretty quickly. Again you can check the migration state by using the dfsrmig /getmigrationstate command.
If it’s all good we get the following message:
All domain controllers have migrated successfully to the Global state (‘Eliminated’). Migration has reached a consistent state on all domain controllers. Succeeded.
The SYSVOL folder is also gone from the Windows directory, and only the SYSVOL_DFSR one is left.
If we take a look at the File Replication Service it should be stopped and set to Disabled. There is an exception though. I noticed on 2008 domain controllers that the File Replication Service still remains on and set to Automatic start. If that’s the case, you will have to manually stop it and disable it. But again, only if it’s the case, if you still have 2008 domain controllers in your environment.
All that is left now is making sure DFSR service is up and running on all domain controllers and replication is working. You can create a test GPO and use the repadmin commands in the pre-requisites section to check everything is in order.
The SYSVOL migration is pretty straight forward, but it needs to be done in a proper order or it will do more damage than good. As noted at the beginning of the article, having healthy domain controllers and a working Active directory environment are two of the most important things, if not a lot of problems will pop-up. Hope this helps, and until next time…all the best.
Want content like this delivered right to your
23 thoughts on “Migrating from FRS to DFSR”
I have 4 DCs at 3 sites, 2 of them are at the moment site where the primary DC sits. Replication is instant between them 2 but it takes 6 minutes to replicate to the other 2 sites. I have taken over the network which the previous IT manager didnt upgrade the forest (currently 2003) nor migrate to DFSR. All the servers are 2012 but i am now brining a 2019 server into DCs which as you know cannot be made a DC whilst the forest is 2003.
I am very reluctant to do the migration as 6 minutes is a long time and i dont want the migration to crash. Can you please advise.
Kind regards, Ash
If you know there are no apps impacted by raising the forest and domain level, go ahead and upgrade. Also, for DCs, do one a time and you will be fine.
If you need more help, just use the contact since I am also doing IT consulting.
Thank you, i didn’t know you could do one at a time?
Thank you very much for this, best tutorial on the internet !
Especially the begining when do you clearly explained everything from the scratch
On to the next one, adding W2019 server 🙂
Thank you and thanks for passing by.
I’m preparing to do this but I’m verifying FRS health first. I don’t have any journal wrap errors (Event ID 13568), but I do have lots of event ID 13567.
The event text is:
“File Replication Service has detected and suppressed an average of 15 or more file updates every hour for the last 3 hours because the updates did not change the contents of the file. The tracking records in FRS debug logs will have the filename and event time for the suppressed updates. The tracking records have the date and time followed by :T: as their prefix.
“Updates that do not change the content of the file are suppressed to prevent unnecessary replication traffic. Following are common examples of updates that do not change the contents of the file:
“ Overwriting a file with a copy of the same file.
“ Setting the same ACLs on a file multiple times.
“ Restoring an identical copy of the file over an existing one.”
I’ve done my research so i think I understand what’s going on, although I don’t know what’s causing it. Something is regularly overwriting the files (or setting ACLs on them), but no actual data is changed in the write so FRS suppresses the unnecessary replication. I haven’t been able to determine what is doing that. It’s typically something like AV software or a disk defragmenter, but my server has neither of those. It’s only happening on one DC, which we are going to decommission soon.
Is it safe to migrate from FRS to DFSR while event ID 13567 is happening frequently on that server? My hunch is that I should be ok, since DFSR is more advanced than FRS, and FRS very capably handles the suppression of unneeded replication events in cases like this. If we planned to keep the server around I would be motivated to find and remedy the root cause, but since I hope to have it out of service within a month, I can live with the issue as long as DFSR won’t freak out or be unable to handle the duplicate frequent writes to SYSVOL the way FRS has been doing.
I will not start the migration having error in my Event Viewer. My recommendation is to clear/fix the problems first than do the migration. Trust me, better work this from the start than going crazy after.
I don’t know what this event ID is actually telling because it is impossible to know every error and message, but for sure if you do a little digging you can find and fix the problem. Once again, do not start the migration if you have FRS and other errors and warning on your servers.
Can this be done during the day?
Do the older domain controllers still function?
Yes and Yes to both of your questions.
You don’t need a maintenance window for this. The only thing that it will not work is adding or removing new domains.
I will not do any change to the AD environment until I’m finished with the migration.
How many domain controllers do you have?
Fantastic write up! Thank you so much!
Thanks a lot, i migrated this morning.
Some fix of the command,
you mentionned many time dfsrmig /getmigrationstatus, but it is dfsrmig /getmigrationstate
On the screens it’s OK but now I have fixed the text also. Glad it worked.
Great article. Congratulations!!!
Here everything has been successful !!!
Only one fix in state 2, the command is incorrect:
dfsrmig / setgblobalstate 2
The word setgblobalstate
Thank you and success.
Done. Thanks for the correction.
Thanks for this idiot proof article. The migration process is very well explained and the steps are well defined.
Thanks. This is how I intend my articles to be, easy and well explained.
Hello, thanks for article! I have 2008 R2 level domain with single 2012 R2 DC. Domain was upgraded from 2003 level.
Does it make any sense / benefits upgrade to DFSR when I have only one DC?
Well…first of all, you should promote a second domain controller even if it’s on a VM or a low end computer to have it as failover. I will migrate to DFSR just for the sake of it, to know that everything is up to date.
Great article, thanks! Useful TechNet link about the same: https://blogs.technet.microsoft.com/qzaidi/2012/01/16/quickly-explained-migrate-your-sysvol-replication-from-frs-to-dfsr/
About the same…:-)
Thanks for passing by.