Friday, February 28, 2014

Windows Server 2012 - Active Directory - SYSVOL - migration from FRS to DFS-R

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/2014   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/2014   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/2014   7:12 PM            SYSVOL
d----         2/27/2014   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/2014  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/2014   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/2014   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/2014   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/2014   8:41 PM          0 logonscript1.txt
-a---         2/28/2014   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/2014   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/2014   8:41 PM          0 logonscript1.txt
-a---         2/28/2014   7:59 PM          0 logonscript3.txt

Yes, replication functions in both locations.


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.


2 comments:

  1. This is very awesome. Thanks for the step-by-step and explaining what is happening. Worked like a charm.

    ReplyDelete
  2. This comment has been removed by the author.

    ReplyDelete