Migrate FRS to DFSR

1.Migrate From FRS to DFSR #

Migrate From FRS to DFSR

This document is a manual and reference How to upgrade the replication used in active directory to a newer set of protocols.

Contents

First Checks before DFS migration

Guide to migrate FRS to DFSR

State configurations

Migration Steps

Prepared State

Redirected State

Eliminated State

Verify FRS is not in use anymore

What are the Domain Controller availability requirements during my migration?

Is there some super-secret way to return to using FRS after reaching the Eliminated phase of DFSR migration?

What are all the AD and Registry state values that will be set at a given point in the migration?

I’m not a huge fan of Ultrasound. Are there any other ways to validate the health of SYSVOL prior to and after migration?

Are there any migration KBs or bugs I need to worry about?

First Checks before DFS migration

Following checks must be carried out before attempting the DFSR migration. If any of the checks fail, do not perform the DFSR migration until the issue is resolved.

Check if Domain functional level is at least Windows Server 2008.

Check all domain controller’s operating system is at least Windows Server 2008.

Check if built-in Administrators group has the ‘Manage Auditing and Security Log’ user right assignment.

Check if all domain controllers have enough free disk space.

Check if Active Directory replication is working.

Check SYSVOL sharing is correct.

Valid system state backup.

Guide to migrate FRS to DFSR

For most users this article only applies if you have Window 2003/ 2003 R2 Domain Controller in your environment that you are planning to get rid off. Pretty soon I hope!

SYSVOL is a folder shared by domain controller to hold its logon scripts, group policies and other items related to AD. All the domain controllers in network will replicate the content of SYSVOL folder. The default path for SYSVOL folder is %SystemRoot%\SYSVOL. This folder path can define when you install the active directory.

Windows Server 2003 and 2003 R2 uses File Replication Service (FRS) to replicate SYSVOL folder content to other domain controllers. But Windows server 2008 and later uses Distributed File System (DFS) for the replication.  DFS is more efficient than FRS. Since windows server 2003 is going out of support, most people already done or still looking for migrate in to latest versions. However migrating FSMO roles WILL NOT migrate SYSVOL replication from FRS to DFS. Most of the engineers forget about this step when they migrate from windows 2003 to new versions.

For FRS to DFS migration we uses the Dfsrmig.exe utility. More info about it available on https://technet.microsoft.com/en-au/library/dd641227(v=ws.10).aspx

In my environment, I am using windows server 2012 R2 server and I migrated FSMO roles already from a windows server 2003 R2 server.

In order to proceed with the migration forest function level must set to windows server 2008 or later. So if your organization not done this yet first step is to get the forest and domain function level updated.

You can verify if the system uses the FRS using dfsrmig /getglobalstate , To do this

1)    Log in to domain controller as Domain admin or Enterprise Admin
2)    Launch powershell console and type dfsrmig /getglobalstate. Output explains it’s not initiated DFRS migration yet.

https://www.mowasay.com/wp-content/uploads/2017/06/dfrs1.png

State configurations

Before move in to the configurations we need to look into stages of the migration.

There are four stable states going along with the four migration phases.

1)    State 0 – Start
2)    State 1 – Prepared
3)    State 2 – Redirected
4)    State 3 – Eliminated

State 0 – Start

With initiating this state, FRS will replicate SYSVOL folder among the domain controllers. It is important to have up to date copy of SYSVOL before begins the migration process to avoid any conflicts.

State 1 – Prepared

In this state while FRS continues replicating SYSVOL folder, DFSR will replicate a copy of SYSVOL folder. It will be located in %SystemRoot%\SYSVOL_DFRS by default. But this SYSVOL will not response for any other domain controller service requests.

State 2 – Redirected

In this state the DFSR copy of SYSVOL starts to response for SYSVOL service requests. FRS will continue the replication of its own SYSVOL copy but will not involve with production SYSVOL replication.

State 3 – Eliminated

In this state, DFS Replication will continue its replication and servicing SYSVOL requests. Windows will delete original SYSVOL folder users by FRS replication and stop the FRS replication.

In order to migrate from FRS to DFSR its must to go from State 1 to State 3. This step cannot be reversed.

Migration Steps:

Prepared State

1.    Log in to domain controller as Domain admin or Enterprise Admin
2.    Launch powershell console
3.    Type dfsrmig /setglobalstate 1 and press enter

https://www.mowasay.com/wp-content/uploads/2017/06/dfrs2.png

4.    Type dfsrmig /getmigrationstate to confirm all domain controllers have reached prepared stat

https://www.mowasay.com/wp-content/uploads/2017/06/dfrs3.png

Redirected State

1.    Log in to domain controller as Domain admin or Enterprise Admin
2.    Launch powershell console
3.    Type dfsrmig /setglobalstate 2 and press enter

https://www.mowasay.com/wp-content/uploads/2017/06/dfrs4.png

4.    Type dfsrmig /getmigrationstate to confirm all domain controllers have reached redirected state

https://www.mowasay.com/wp-content/uploads/2017/06/dfrs5.png

Eliminated State

1.    Log in to domain controller as Domain admin or Enterprise Admin
2.    Launch powershell console
3.    Type dfsrmig /setglobalstate 3 and press enter

https://www.mowasay.com/wp-content/uploads/2017/06/dfrs6.png

4.    Type dfsrmig /getmigrationstate to confirm all domain controllers have reached eliminated state

https://www.mowasay.com/wp-content/uploads/2017/06/dfrs7.png

This completes the migration process and to confirm the SYSVOL share, type net

share command and enter.

https://www.mowasay.com/wp-content/uploads/2017/06/dfrs8.png

Verify FRS is not in use anymore

Make sure in each domain controller FRS service is stopped and disabled. This should happen automatically, but please verify.

https://www.mowasay.com/wp-content/uploads/2017/06/dfrs9.png

 

What are the Domain Controller availability requirements during my migration?

A: There are a couple.

The PDC Emulator must be online any time the DFSRMIG tool is being invoked for a read or write operation. If the PDC Emulator is offline or inaccessible for LDAP, the user of DFSRMIG will receive:

“Unable to connect to the Primary DC’s AD.

Please make sure that the PDC is reachable and try the command later.”

All DCs must remain online until they each complete their state steps. All DCs do not need to be accessible simultaneously. But the global state will never reach the Prepared, Redirected, or Eliminated state until all DCs have been able to complete their individual phases.

The PDC Emulator requirement is because by default, administrators always edit group policy on the PDCE, so in most environments it will have the most up to date knowledge of policy. That and we need to talk to someone unique, so it might as well be him.

It is recommended that a SYSVOL migration not be attempted unless all DCs are online and available. Change control blackouts should be scheduled to prevent modification to DCs that might impact their availability. This will minimize the window of time that the migration will take.

Is there some super-secret way to return to using FRS after reaching the Eliminated phase of DFSR migration?

A: Microsoft does not support returning your domain to using FRS for SYSVOL replication after a completed DFSR migration (except to rebuild the domain). This is why the steps are done in a phased approach with two checkpoints where you can revert back to FRS without any consequences. Once you trigger the ELIMINATED phase to start, there is no going back, period.

Q: When does Robocopy run during the migration and what does it do?

A: The DFSR service uses robocopy at several stages to synchronize SYSVOL directories outside of normal replication when it detects a SYSVOL migration is underway; a set of ‘pre-seeding’ and ‘save the GP admins from themselves’ operations.

When Prepared state (DFSRMIG /SETGLOBALSTATE 1) is invoked, all DC’s robocopy their FRS SYSVOL data locally into the new DFSR content set. This is equivalent to ‘pre-seeding’ data and ensures that minimal file replication occurs to converge the content set. This is triggered by the DFSR service itself when:

AD replication has converged between a DC and the PDCE.

The DFSR service on that DC has polled (this runs every 5 minutes) and picks up the state change from CN=dfsr-LocalSettings

When entering the Redirected state, the PDC Emulator (only) robocopies the local differences of FRS SYSVOL data into the new local DFSR content set, on itself. The other servers receive new data via replication.

If you undo the Redirected state back to Prepared, the reverse happens. The PDC Emulator robocopies its local DFSR content set data into its local FRS content set. FRS replication synchronizes all other servers… eventually. Allow more time for this than entering Redirected, as FRS is not as fast to synchronize as DFSR.

For sharp-eyed readers: we won’t run into any of the old pre-seeding issues (the file hash being changed by robocopy) here because DFSR correctly creates the SYSVOL_DFSR folder ACL, so there are no inheritance issues when the contents are copied in and replicated.

Q: Event 8004 says something about RODC’s. I don’t have any RODC’s. What the frak?

A: The following event is incorrectly written in the DFSR event log(s) on servers that are not Read-only Domain Controllers when setting elimination state using DFSRMIG.EXE:

Log Name: DFS Replication
Source: DFSR
Date: 9/28/2007 11:53:46 AM
Event ID: 8004
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: <WRITABLE DC>
Description:
The NTFRS member object for the Read-only Domain Controller <WRITABLE DC> was deleted successfully.

The text in the event log is completely cosmetic and benign. It is supposed be fixed in a later version of the OS. Just ignore it.

What are all the AD and Registry state values that will be set at a given point in the migration?

A: See below:

=============

Prepared Phase – DFSRMIG /SETGLOBALSTATE 1

DFSRMIG contacts the PDC Emulator directly.

Global objects are created under:

CN=DFSR-GlobalSettings,CN=SYSTEM,DC=<domain>
CN=DOMAIN SYSTEM VOLUME
CN=SYSVOL SHARE
CN=CONTENT
CN=TOPOLOGY

CN=DFSR-GlobalSettings now has msDFSR-Flags attribute set to 0.

As DC’s pick up the globalstate change via AD replication and DFSR service polling, they create and write to registry entry:

HKLMSystemCurrentControlSetServicesDFSRParametersSysvolsMigrating Sysvols
Local State = 4 [REG_DWORD]

The PDC Emulator creates the:

CN=dfsr-LocalSettings,CN=<servername>,DC=<domain>

objects for all DCs and sets this attribute to:

msDFSR-Flags = 80 (if RWDCs).
msDFSR-Flags = 64 (if RODCs – the RODC itself will set it to 80 later).

The DFSR service has now started and created the new local SYSVOL_DFSR structure. Robocopy has made a local copy of the FRS SYSVOL. All AD topology data has been written in to support the content set. Initial sync of the data has started (since robocopy has locally pre-seeded the data this should involve minimal replication data on the network). The registry on all DC’s is:

Local State = 5 [REG_DWORD]

Once initial sync is done on all DCs:

Local State = 1 [DWORD]
‘msDFSR-Flags’ (on CN=dfsr-LocalSettings) = 16

If DFSRMIG /GETGLOBALSTATE returns that all DCs are prepared, ‘msDFSR-Flags’ on CN=dfsr- GlobalSettings has changed to 16 because all DCs are prepared. All DCs are currently replicating DFSR and FRS content sets, with FRS being shared as SYSVOL.

=============

Redirected Phase – DFSRMIG /SETGLOBALSTATE 2

DFSRMIG contacts the PDC Emulator directly.

CN=DFSR-LocalSettings now has msDFSR-Flags attribute set to 96 on all DCs and this replicates out through AD.

As DCs pick up the attribute from AD replication, their DFSR service sets:

Local State = 6 [REG_DWORD]

On the PDC Emulator only, robocopy syncs any changes between the FRS and DFSR’s content sets, and this is replicated out through DFSR.

Once SYSVOL data is in sync, SYSVOL content set is set to be the active SYSVOL share on all servers. FRS and DFSR are both still replicating data.

When this is complete, for each DC:

Local State = 2 [DWORD]
‘msDFSR-Flags’ (on CN=dfsr-LocalSettings) = 32

If DFSRMIG /GETGLOBALSTATE returns that all DCs are redirected, ‘msDFSR-Flags’ on CN=dfsr- GlobalSettings has changed to 32 because all DCs are prepared. All DCs are currently replicating DFSR and FRS content sets, with DFSR being shared as SYSVOL.

==============

Eliminated Phase – DFSRMIG /SETGLOBALSTATE 3

DFSRMIG contacts the PDC Emulator directly. At this point it is not possible to undo the changes!

CN=DFSR-LocalSettings now has msDFSR-Flags attribute set to 112 on all DCs and this replicates throughout AD.

As DCs pick up the attribute from AD replication, their DFSR service sets:

Local State = 7 [REG_DWORD]

On the PDC, the FRS content set information is removed and this is replicated through AD. As each DC sees this change, their FRS service stops replicating the FRS content set. The FRS service is stopped (and restarted if custom FRS sets still exist on a given server).

When this is complete, for each DC:

Local State = 3 [DWORD]
‘msDFSR-Flags’ (on CN=dfsr-LocalSettings) = 48

If DFSRMIG /GETGLOBALSTATE returns that all DCs are eliminated, ‘msDFSR-Flags’ on CN=dfsr-GlobalSettings has changed to 48 because all DCs are prepared. All DCs are currently replicating DFSR only.

A final cleanup task on each DC will set their ‘msDFSR-Flags’ on CN=dfsr-LocalSettings to <NOT SET>. The same will happen from the PDC to CN=dfsr-GlobalSettings.

==============

If any ‘undo’ phases are entered (where an administrator has decided to go from redirected back to prepared, redirected back to start, or prepared back to start), the flow above happens in reverse, with the exception that the following two entries exist in the ‘Local State’ registry entries:

(Undo Redirecting)

(Undo Preparing)

I’m not a huge fan of Ultrasound. Are there any other ways to validate the health of SYSVOL prior to and after migration?

A: Sure thing – already discussed in a TechNet blog post here (Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style).

Are there any migration KBs or bugs I need to worry about?

A: One KB, with a simple solution to domains that have non-standard (and frankly, not any safer than default) security configurations: http://support.microsoft.com/kb/2567421 (Manage Audit and Security Logs user rights required)

CAUSE: The default user rights assignment “Manage Auditing and Security Log” (SeSecurityPrivilege) has been removed from the built-in Administrators group. Removal of this user right from Administrators on domain controllers is not supported, and will cause DFSR SYSVOL migration to fail. DFSR migration and must be run by a user who is a member of the built-in Administrators group in that domain. All DCs are automatically members of the built in Administrators group

 

Help Guide Powered by Documentor
Suggest Edit