he File Replication Service (FRS) is used for replicating the contents of the SYSVOL share between Windows domain controllers. However, Windows Server 2008 domain controllers, which are operating in the Windows Server 2008 domain functional level, can use the DFS Replication service for replicating the contents of the SYSVOL share. A new Windows Server 2008 feature makes it possible for administrators to migrate replication of the SYSVOL share from FRS to the more reliable and efficient DFS Replication service.
This series of blog posts describe the procedure for migrating the replication of the SYSVOL share on Windows Server 2008 domain controllers from FRS replication to the DFS Replication service.
|NOTE: The Windows Server 2008 SP2 release includes a couple of important bug-fixes in DFS Replication that address a few customer reported issues in SYSVOL migration. If you plan to migrate replication of the SYSVOL share to DFS Replication, it is highly recommended that you upgrade to Windows Server 2008 SP2 first.
The RTM release of Windows Server 2008 R2 includes these bug fixes.
The DFS Replication service offers several advantages over the older File Replication Service (FRS). Some of the advantages that accrue from using the DFS Replication service are:
a) Efficient, scalable and reliable file replication protocol which has been tested extensively to ensure data consistency in multi-master replication scenarios.
b) Differential replication of changes to files using the Remote Differential Compression (RDC) algorithm, which enhances efficiency in branch office scenarios.
c) Flexible scheduling and bandwidth throttling mechanisms.
d) Self-heals from USN journal wraps and database corruptions – end user intervention and monitoring requirement is minimal.
e) Provides a new UI management tool (MMC snap-in) for ease of administration.
f) Provides built in health monitoring tools for ease of monitoring deployments.
g) Improved support for Read Only Domain Controllers.
It is hence highly recommended that customers migrate replication of the SYSVOL share to the DFS Replication service.
Migration – in a nutshell
Windows Server 2008 ships a command line tool called ‘dfsrmig.exe’ which can be used by an administrator to initiate migration of SYSVOL replication from FRS to the DFS Replication service. This tool essentially sets migration related directives in Active Directory. Thereafter, on each of the domain controllers in the domain, when the DFS Replication service running polls Active Directory for configuration information, it notices this migration directive and takes steps to migrate replication of SYSVOL to the DFS Replication service. The following section explains the various migration states that are possible during this migration process in more detail.
Thus migration directives are set only once (globally) and all domain controllers in the domain notice this directive and automatically take steps to attain the selected migration state, thus resulting in migration of SYSVOL replication from FRS to the DFS Replication service.
Figure 1: SYSVOL Migration in a nutshell.
An analogy …
Let’s use a conventional analogy to understand the process of SYSVOL migration better. Joe is an old timer who is due to retire from his job at the packaging plant this month end. Alex is supposed to take over Joe’s responsibilities once Joe retires. Normally, the transition of responsibilities from Joe to Alex would work out in four phases as shown in Figure 1.
Initially, before the transition begins, Joe is responsible for the day-to-day work where he mans the packaging assembly line. In Stage 2 of the transition plan, Alex shadows Joe and ‘learns the ropes’. He helps package a few units here and there, but Joe is still responsible for ensuring that daily production goals are met. In Stage 3, Alex begins to take over more of the day-to-day responsibilities from Joe right up to the point where Alex only consults with Joe when he needs help. Finally, when Alex is ready to take on all responsibilities, Joe is ready to retire.
Figure 2: SYSVOL Migration – an analogy.
If we extend this analogy to the process of migration of SYSVOL replication from FRS to the DFS Replication service, we can define four states in the migration process. These are:
a) ‘START’ state: In this state, FRS is responsible for replicating the contents of the SYSVOL share between domain controllers. The main replication engine for the SYSVOL share on each of the domain controllers in the domain is FRS.
b) ‘PREPARED’ state: In the ‘PREPARED’ state, the DFS Replication service makes a copy of the contents of the SYSVOL share for itself. It then proceeds to initiate replication of its copy of the SYSVOL folder with the DFS Replication service running on other peer domain controllers which have migrated to the ‘PREPARED’ state. At this stage of the migration process, the main replication engine for the SYSVOL share on each of the domain controllers in the domain is still FRS.
c) ‘REDIRECTED’ state: In the ‘REDIRECTED’ state, the replication responsibility is shifted to the DFS Replication service. The copy of the SYSVOL folder which was being replicated by the DFS Replication service is now the one that is shared out by the Netlogon service and advertized by the domain controller. FRS is, in the meantime, replicating the old SYSVOL folder with the FRS service running on other peer domain controllers. At this stage of the migration process, the main replication engine for each of the domain controllers in the domain is the DFS Replication service.
d) ‘ELIMINATED’ state: In the ‘ELIMINATED’ state, once the domain administrator has ensured that replication is working fine, the FRS service is retired and the DFS Replication service assumes sole responsibility for replicating the contents of the SYSVOL share between all domain controllers in that domain.
Figure 3: Migrating from FRS replication of SYSVOL to the DFS Replication service.
Stable States: There are four migration states which are defined as ‘Stable Migration States’ as alluded to above. During the process of migration, the administrator uses the migration tool (dfsrmig.exe) to set a migration directive in Active Directory. This directive essentially sets a domain wide migration state (also called global migration state) in Active Directory. This global migration state can be any one of the four stable migration states shown in the table below.
|Stable Migration States|
Transition States: During migration, each domain controller takes appropriate actions locally so that it can attain the migration stable state which has been selected for the domain by the administrator. This operation causes the domain controller to cycle through intermediate states called ‘Transition States’. These transition states are shown in the table below.
|5||‘WAITING FOR INITIAL SYNC’ state|
|8||‘UNDO REDIRECTING’ state|
|9||‘UNDO PREPARING’ state|
How migration works
The domain administrator uses the dfsrmig.exe tool to trigger the process of SYSVOL migration. This tool sets a migration directive in the Active Directory of the Primary Domain Controller, which is what directs the DFS Replication service to perform SYSVOL migration the next time it polls Active Directory for configuration information. The migration directive is an outcome of setting what is known as the global migration state in Active Directory. This is a domain wide migration state which can assume any of the values of the stable migration states detailed above.
When the DFS Replication service polls Active Directory for configuration information, it notices the global migration state and takes suitable actions to bring its local migration state in sync with this global migration state. This action is what causes the process of migration to take place. During the process of migration, when the DFS Replication service is trying to bring the local migration state in sync with the global migration state, the local migration state will cycle through the intermediate migration states before settling at the desired stable migration state. This is illustrated in the state transition diagrams that follow.
The process of moving forward through the stable migration states in order to eliminate the FRS service and replace it with the DFS Replication service for replicating the contents of the SYSVOL share is known as migration. The state transition diagram corresponding to the migration process is as shown below:
Figure 4: State transition diagram for the migration process.
Before domain controllers migrate to the ‘ELIMINATED’ state, it is possible to roll back migration to the ‘PREPARED’ or ‘START’ states. This facility is provided so that administrators can commit to the SYSVOL migration procedure only once they are fully confident that the DFS Replication service is replicating SYSVOL properly in their environment. It is possible to use the rollback functionality to move to the previous stable state. When the dfsrmig.exe tool is used and the global migration state is set to the previous stable migration state, rollback is caused. For instance, if the current global migration state is ‘REDIRECTED’ and the administrator wants to rollback migration to the ‘PREPARED’ state, he can use the dfsrmig.exe tool to set the global migration state to ‘PREPARED’. The DFS Replication service on all domain controllers will follow this directive and rollback migration state to the ‘PREPARED’ state. The state transition diagram corresponding to the rollback process is as shown below:
Figure 5: State transition diagram for the rollback process.
NOTE: It is not possible to rollback once migration has reached the ‘ELIMINATED’ state. Therefore, it is recommended to migrate to this state only when you are sure that SYSVOL replication is working fine using the DFS Replication service.
Features of the SYSVOL migration process
The SYSVOL migration procedure is designed to provide the following features:
a) A robust mechanism to migrate replication of the SYSVOL share from FRS to the DFS Replication service, with reduced risk, minimal need for down-time and near zero end-user impact. This mechanism is resilient to domain controller crashes, reboots, promotions and demotions.
b) Sufficiently granular control over the migration procedure for administrators. This empowers administrators to control the process one step at a time so as to verify correct operation before changes are committed.
c) Allow rollback of the migration procedure at any point in time until the last step (‘ELIMINATED’ state) where the FRS service is eliminated. This feature enables administrators to roll back changes in case something was to go wrong during the migration process.
d) Works despite Active Directory replication latencies and is hence suited to branch office domain controller migration scenarios. In particular, the process is designed to work in instances where some domain controllers may not know that migration has been initiated owing to Active Directory replication latencies, since it does not assume that all domain controllers will be simultaneously reachable during migration.
e) Provides mechanisms by which a domain administrator can monitor the progress of migration.