Group Policy settings (in part) and logon scripts are stored in the subfolders of the C:\Windows\SYSVOL folder (unless Windows is installed on another drive of course). It is crucial that these settings and scripts are replicated among domain controllers so the settings are applied and the scripts executed regardless of the domain controller that authenticates the user (or computer).
The traditional mechanism for this replication, for Windows 2000 and 2003, was FRS (File Replication Service). FRS can still be used, even with Windows 2012 R2, but since Windows 2008, there is another possible mechanism: DFS-R. This system is considered more reliable than FRS.
The objective of this blog post is not to present either FRS or DFS-R in detail but to share my experience in migrating from the first to the second.
There are a number of resources that can be consulted for those interested in such a presentation, for example:
In the lines that follow, I'll presenting my experience with the migration process, using two domain controllers, one running Windows 2008 R2 (SP1) and the other Windows 2012.
Demonstration of the SYSVOL replication mechanism
First, I'll conduct a basic test of the SYSVOL replication mechanism and illustrate how it functions.
Let's create a logon script that should be available on all domain controllers - in our case, both domain controllers.
I'll create it on DC7 and see if it replicates to DC2.
DC2 and DC7 are simply the names of the test machines I had set up for the exercise. No need to worry about what happened to DC1 and DCs 3 to 6.
I'll also use this opportunity to illustrate some file management with Powershell. So everything will happen at the command line: no GUI, no images!
Creation of script on DC2 - and replication to DC7
PS C:\> sl windows
PS C:\windows> sl sysvol
PS C:\windows\sysvol> sl domain
PS C:\windows\sysvol\domain> sl scripts
PS C:\windows\sysvol\domain\scripts> ni logonscript1.txt -type file
Note (Powershell): "ni" is short for "New-Item". There is also a -Name parameter but this is "positional" so if we enter the name directly after the cmdlet, it is not required. There is a -Path parameter as well. If none is indicated, the current location is used.
Note (Powershell): "sl" is short for Set-Location. It is the equivalent of the old "cd" command (which would also function here as well, for that matter).
And yes, I realize a "logon script" with a .txt extension would never be executed. In reality, I would have to change it to .bat or .cmd (and add some content).
I will not press ENTER right away. Let's first look at the corresponding folder on DC7.
We'll initiate a remote session to view this:
PS C:\> New-PSSession dc2.mynet.lan
PS C:\> Enter-PSSession 1
Note: now I'm on DC2, via the remote session. I'll browse to the scripts folder...
[dc2.mynet.lan]: PS C:\Users\admin\Documents> sl \
[dc2.mynet.lan]: PS C:\>
[dc2.mynet.lan]: PS C:\> sl windows
[dc2.mynet.lan]: PS C:\windows> sl sysvol
[dc2.mynet.lan]: PS C:\windows\sysvol> sl domain
[dc2.mynet.lan]: PS C:\windows\sysvol\domain> sl scripts
[dc2.mynet.lan]: PS C:\windows\sysvol\domain\scripts> gci
[dc2.mynet.lan]: PS C:\windows\sysvol\domain\scripts>
Nothing... the Get-ChildItem cmdlet (or the abbreviated version "gci") produces no results.
Now let's press enter on DC7 so the file is created:
PS C:\windows\sysvol\domain\scripts> ni logonscript1.txt -type file
Directory: C:\windows\sysvol\domain\scripts
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 2/27/2015 8:41 PM 0 logonscript1.txt
Now... returning to DC2, we execute Get-ChildItem again and almost immediately the file appears:
[dc2.mynet.lan]: PS C:\windows\sysvol\domain\scripts> gci
Directory: C:\windows\sysvol\domain\scripts
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 2/27/2015 8:41 PM 0 logonscript1.txt
Preliminary verifications - introduction to the DFSRMIG tool
Before migrating SYSVOL from FRS to DFS-R, we can verify many aspects of Active Directory health and replication health in particular.
We can verify that the SYSVOL folder is shared with the NET SHARE command. Since the migration process changes the shared resource from the SYSVOL folder to a new folder named SYSVOL_DFSR, we can follow the evolution of this process by executing the command after each step. For readbility and "neatness", I may edit (remove) some of the other entries later.
Share name Resource Remark
---------------------------------------------------------------
C$ C:\ Default share
IPC$ Remote IPC
ADMIN$ C:\Windows Remote Admin
NETLOGON C:\Windows\SYSVOL\sysvol\mynet.lan\SCRIPTS [...]
SYSVOL C:\Windows\SYSVOL\sysvol Logon server share
We can run DCDIAG and REPADMIN /REPLSUM and REPADMIN /SHOWREPL.
These checks, while useful, are not the subject of this post.
There is, however, one prerequisite that must be met before we can migrate FRS to DFS-R:
The domain functional level (DFL) must be at Windows 2008 (or higher).
Let's verify that... with PowerShell.
PS C:\> Get-ADDomain | fl DomainMode
DomainMode : Windows2008Domain
Perfect.
Now we can begin the migration.
The process is gradual, following 4 "states":
- 0 - Start = FRS is used for replication.
- 1 - Prepared = FRS continues to replicate SYSVOL content. In addition, a copy of SYSVOL is created in a folder named SYSVOL-DFSR.
- 2- Redirected = the SYSVOL share, instead of referring to the folder SYSVOL\sysvol now refers to SYSVOL_DFSR\sysvol. However, the content of both folders continues to replicate.
- 3 - Eliminated = FRS is not longer used for replication.
DFSRMIG
The tool used is DFSRMIG. It has 3 primary commands:
- /setglobalstate = this migrates SYSOL replication between the states mentioned above: Start, Prepared, Redirected, Eliminated.
- /getglobalstate = this show the global or overall status of the migration
- /getmigrationstatus = this shows the migration status on particular domain controllers.
Migration to the "Prepared" State
We can check migration status with the two "get" commands presented above...
PS C:\> dfsrmig /getglobalstate
DFSR migration has not yet initialized. To start migration please set global state to desired value.
PS C:\> dfsrmig /getmigrationstate
DFSR migration has not yet initialized. To start migration please set global state to desired value.
Note: we can set the global state to 0 first. I proceeded directly to 1.
PS C:\> dfsrmig /setglobalstate 1
Current DFSR global state: 'Start'
New DFSR global state: 'Prepared'
Migration will proceed to 'Prepared' state. DFSR service will
copy the contents of SYSVOL to SYSVOL_DFSR
folder.
If any domain controller is unable to start migration, try manual polling
Or run with option /CreateGlobalObjects.
Migration can start anytime between 15 minutes to 1 hour.
Succeeded.
So where is the new SYSVOL_DFSR folder located? Right next to the SYSVOL folder:
PS C:\windows> gci *sysvol*
Directory: C:\windows
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 2/25/2015 7:12 PM SYSVOL
d---- 2/27/2015 7:22 PM SYSVOL_DFSR
Note that it has not yet been created on DC2:
[dc2.mynet.lan]: PS C:\windows> gci *sysvol*
Directory: C:\windows
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 8/19/2012 9:18 PM SYSVOL
We have to wait a while:
[dc2.mynet.lan]: PS C:\windows> gci *sysvol*
Directory: C:\windows
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 8/19/2012 9:18 PM SYSVOL
d---- 2/27/2015 10:25 PM SYSVOL_DFSR
We can verify that the migration state is now "Prepared" on all domain controllers:
PS C:\windows> dfsrmig /getglobalstate
Current DFSR global state: 'Prepared'
Succeeded.
PS C:\windows> dfsrmig /getmigrationstate
All domain controllers have migrated successfully to the Global state ('Prepared').
Migration has reached a consistent state on all domain controllers.
Succeeded.
At this point, the SYSVOL share is still associated with the SYSVOL folder.
PS C:\windows> net share
Share name Resource Remark
---------------------------------------------------------------
[snip]
NETLOGON C:\Windows\SYSVOL\sysvol\mynet.lan\SCRIPTS [...]
SYSVOL C:\Windows\SYSVOL\sysvol Logon server share
Note that although FRS is still used for replication (with the SYSVOL folder still the "target" of the share, the content has been copied - not moved - to the SYSVOL_DFSR folder)...
PS C:\windows\sysvol\domain\scripts> gci
Directory: C:\windows\sysvol\domain\scripts
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 2/27/2015 5:41 PM 0 logonscript1.txt
PS C:\windows\sysvol\domain\scripts> sl ..
PS C:\windows\sysvol\domain> sl ..
PS C:\windows\sysvol> sl ..
PS C:\windows> sl sysvol_dfsr
PS C:\windows\sysvol_dfsr> sl domain
PS C:\windows\sysvol_dfsr\domain> sl scripts
PS C:\windows\sysvol_dfsr\domain\scripts> gci
Directory: C:\windows\sysvol_dfsr\domain\scripts
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 2/27/2015 5:41 PM 0 logonscript1.txt
Migration to the "Redirected" state
Now let's proceed to state 2: Redirected...
PS C:\windows> dfsrmig /setglobalstate 2
Current DFSR global state: 'Prepared'
New DFSR global state: 'Redirected'
Migration will proceed to 'Redirected' state. The SYSVOL share
will be changed to SYSVOL_DFSR folder,
which is replicated using DFSR.
Succeeded.
Let's verify the status...
PS C:\windows> dfsrmig /getglobalstate
Current DFSR global state: 'Redirected'
Succeeded.
PS C:\windows> dfsrmig /getmigrationstate
The following domain controllers have not reached Global state ('Redirected'):
Domain Controller (Local Migration State) - DC Type
===================================================
DC2 ('Prepared') - Primary DC
Migration has not yet reached a consistent state on all domain controllers.
State information might be stale due to Active Directory Domain Services latency.
So it appears that the change has not yet replicated to DC2. We simply need to wait a moment (several minutes)...
PS C:\windows> dfsrmig /getmigrationstate
All domain controllers have migrated successfully to the Global state ('Redirected').
Migration has reached a consistent state on all domain controllers.
Succeeded.
Note that NET SHARE now shows the SYSVOL_DFSR folder as the resource for the SYSVOL share:
PS C:\> net share
Share name Resource Remark
---------------------------------------------------------------
[snip]
NETLOGON C:\Windows\SYSVOL_DFSR\sysvol\mynet.lan\SCRIPTS
SYSVOL C:\Windows\SYSVOL_DFSR\sysvol Logon server share
Let's see which folder is being used to replicate...
PS C:\windows>
PS C:\windows> sl sysvol
PS C:\windows\sysvol> sl domain
PS C:\windows\sysvol\domain> sl scripts
PS C:\windows\sysvol\domain\scripts> ni logonscript2.txt -type file
Directory: C:\windows\sysvol\domain\scripts
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 2/28/2015 4:54 PM 0 logonscript2.txt
So we've created another file on DC7 in the SYSVOL folder (one of its subfolders). Does it replicate to DC2?
[dc2.mynet.lan]: PS C:\windows\sysvol\domain\scripts> gci
Directory: C:\windows\sysvol\domain\scripts
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 2/27/2015 8:41 PM 0 logonscript1.txt
-a--- 2/28/2015 7:54 PM 0 logonscript2.txt
Observation: the contents of SYSVOL still replicate at this state (even though the share is now associated with SYSVOL_DFSR.
We'll create a file in the SYSVOL_DFSR folder (one of its subfolders) to verify that replication is taking place here as well...
PS C:\windows\sysvol_dfsr\domain\scripts> ni logonscript3.txt -type file
Directory: C:\windows\sysvol_dfsr\domain\scripts
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 2/28/2015 4:59 PM 0 logonscript3.txt
Does it replicate to DC2?
[dc2.mynet.lan]: PS C:\windows\sysvol\domain\scripts> sl \
[dc2.mynet.lan]: PS C:\>
[dc2.mynet.lan]: PS C:\>
[dc2.mynet.lan]: PS C:\> sl windows\sysvol_dfsr\domain\scripts
[dc2.mynet.lan]: PS C:\windows\sysvol_dfsr\domain\scripts> gci
Directory: C:\windows\sysvol_dfsr\domain\scripts
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 2/27/2015 8:41 PM 0 logonscript1.txt
-a--- 2/28/2015 7:59 PM 0 logonscript3.txt
Migration back to the "Prepared" state
(strictly optional - to demonstrate ability to revert to a previous state)
At this state, we can still turn back, which I'll demonstrate before irrevocably eliminating FRS from the replication process:
PS C:\> dfsrmig /setglobalstate 1
Current DFSR global state: 'Redirected'
New DFSR global state: 'Prepared'
Migration will proceed to 'Prepared' state. The SYSVOL share
will be changed to SYSVOL folder, which is replicated using FRS.
Succeeded.
However, the change back is not immediate as the following shows:
PS C:\> dfsrmig /getglobalstate
Current DFSR global state: 'Prepared'
Succeeded.
PS C:\> dfsrmig /getmigrationstate
The following domain controllers have not reached Global state ('Prepared'):
Domain Controller (Local Migration State) - DC Type
===================================================
DC2 ('Redirected') - Primary DC
DC7 ('Redirected') - Writable DC
Migration has not yet reached a consistent state on all domain controllers.
State information might be stale due to Active Directory Domain Services latency.
This takes some time (several minutes) and strangely, it is DC7 (the server on which I performed the operation) that reverts back to the "Prepared" state with the longest delay.
PS C:\> dfsrmig /getmigrationstate
The following domain controllers have not reached Global state ('Prepared'):
Domain Controller (Local Migration State) - DC Type
===================================================
DC7 ('Redirected') - Writable DC
Migration has not yet reached a consistent state on all domain controllers.
State information might be stale due to Active Directory Domain Services latency.
After several more minutes, the change is effective:
PS C:\> dfsrmig /getmigrationstate
All domain controllers have migrated successfully to the Global state ('Prepared').
Migration has reached a consistent state on all domain controllers.
Succeeded.
Migration to the "Eliminated" state
Now let's move forward and make DFS-R the one and only replication mechanism (for SYSVOL) on our domain controllers.
This should look familiar...
PS C:\windows> dfsrmig /setglobalstate 2
Current DFSR global state: 'Prepared'
New DFSR global state: 'Redirected'
Migration will proceed to 'Redirected' state. The SYSVOL share
will be changed to SYSVOL_DFSR folder, which is replicated using DFSR.
Succeeded.
Let's verify...
PS C:\> dfsrmig /getglobalstate
Current DFSR global state: 'Redirected'
Succeeded.
PS C:\> dfsrmig /getmigrationstate
All domain controllers have migrated successfully to the Global state ('Redirected').
Migration has reached a consistent state on all domain controllers.
Succeeded.
So we are once again back at "Redirected" state (2).
We are at the point of no return.
We would have to rebuild the domain to return to FRS.
So here we go....
PS C:\> dfsrmig /setglobalstate 3
Current DFSR global state: 'Redirected'
New DFSR global state: 'Eliminated'
Migration will proceed to 'Eliminated' state. It is not possible to revert this step.
If any read-only domain controller is stuck in the 'Eliminating' state for too long
run with option /DeleteRoNtfrsMember.
Succeeded.
It's better to know there is no turning back, because there is no "Are you sure you want to do this?" warning.
After several minutes, the transition is complete:
PS C:\> dfsrmig /getglobalstate
Current DFSR global state: 'Eliminated'
Succeeded.
PS C:\> dfsrmig /getmigrationstate
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 eliminated:
PS C:\windows> sl sysvol
sl : Cannot find path 'C:\windows\sysvol' because it does not exist.
[snip]
This completes the migration.
Thank you for reading the article about Windows Server 2012 - Active Directory - SYSVOL - migration from FRS to DFS-R on the blog NEW TECH If you want to disseminate this article on please list the link as the source, and if this article was helpful please bookmark this page in your web browser by pressing Ctrl + D on your keyboard keys.