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.
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