SYSVOL Migration Series

[patris1]

http://blogs.technet.com/filecab/archive/2008/02/08/sysvol-migration-series-part-1-introduction-to-the-sysvol-migration-process.aspx

Part 1 – Introduction to the SYSVOL migration process


The 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.
Why migrate?
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.

Migration States
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
0
‘START’ state
1
‘PREPARED’ state
2
‘REDIRECTED’ state
3
‘ELIMINATED’ state

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.

Transition States
4
‘PREPARING’ state
5
‘WAITING FOR INITIAL SYNC’ state
6
‘REDIRECTING’ state
7
‘ELIMINATING’ 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.
Migration:
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.

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

---

موضوعات مشابه:

• System Volume یا به اختصار Sysvol چیست ؟
• پوشه sysvol
• عدم دسترسی به sysvol دامین
• مشکل در gruop policy و sysvol permission
• مخفي كردن sysvol و netlogon و scheduled task

---

[patris1]

http://blogs.technet.com/filecab/archive/2008/02/14/sysvol-migration-series-part-2-dfsrmig-exe-the-sysvol-migration-tool.aspx

Part 2 – Dfsrmig.exe: The SYSVOL migration tool

In our first post in this series, we examined the SYSVOL migration process and understood how things work at a high level during the process of migration of the SYSVOL share from the FRS service to the DFS Replication service. Windows Server 2008 includes a command line tool called dfsrmig.exe which can be used by administrators to control the process of migrating replication of the SYSVOL share from FRS to the DFS Replication service. In this post, we take a closer look at this tool. The following posts in this series will explain how to migrate replication to each of the migration states in greater detail.
The DFS Replication service’s migration tool (dfsrmig.exe) is installed along with the DFS Replication service. This tool can be executed on any domain controller, however, any operations which perform AD object creation/manipulation tasks are only allowed on Read-Write capable domain controllers (not on RODCs). An example of such tasks is the creation/deletion of both FRS and DFSR global settings required for replication activity. In such cases, the tool will always try to connect to the Primary Domain Controller’s Active Directory for processing migration related directives, and will fail if it is unable to reach the Primary Domain Controller’s Active Directory.

Pre-requisites for running the tool
The dfsrmig.exe tool is supported only on domain controllers which are running in the Windows Server 2008 domain functional level. This is because SYSVOL migration from FRS replication to the DFS Replication service is possible only on domain controllers operating in the Windows Server 2008 domain functional level.
If the dfsrmig.exe tool is executed on domain controllers which are not running in Windows Server 2008 domain functional level, the error illustrated below is displayed.

Now, let’s take a look at the command line options for the dfsrmig.exe tool. At any point, help pertaining to the command line options for the dfsrmig.exe tool can be obtained by typing ‘dfsrmig /?’ on the command prompt.
Common command line switches
These are the set of command line switches which will be used frequently during the migration process. For the most part, the remaining command line switches (called Auxiliary/Optional switches) should not be required during the course of a typical migration process.
a) SetGlobalState
Format: dfsrmig /SetGlobalState [State]
- ‘State’ corresponds to the global migration state that the administrator intends to set for the domain.

This command line switch can be used to initiate and control the migration procedure by setting the migration global state (explained in this post) in Active Directory on the Primary Domain Controller. The value set for the migration global state drives the process of SYSVOL migration.
Active Directory replication enables the value of the global migration state to be replicated to the individual domain controllers in the domain. When the DFS Replication service on any of these individual domain controllers polls its Active Directory for configuration information, it notices the migration directive (value of the global migration state) and then takes steps locally to match its local migration state with the currently configured global migration state.
If the Primary domain controller is not available, this command fails. Since this command line switch is used to set the global migration state for the domain, the only permissible parameters to this switch are the global migration states detailed below.

Global Migration States
0
‘START’ state
1
‘PREPARED’ state
2
‘REDIRECTED’ state
3
‘ELIMINATED’ state

NOTE: The important thing to note is that since AD replication is what causes the global migration state to be propagated to each individual domain controller, there will be latencies associated with AD replication before this global state value is ‘visible’ on all domain controllers in the domain.

b) GetGlobalState
Format: dfsrmig /GetGlobalState

This command retrieves the current global migration state for the domain from the Primary Domain Controller’s Active Directory. Once the global migration state has been set, an administrator can use this command line switch on the primary domain controller to confirm that the correct global migration state has been set.
Since this command line switch is used to retrieve the global migration state for the domain, the results obtained correspond to any of the global migration states defined in the table above.
NOTE: Since AD replication causes the global migration state to be replicated to the replica domain controllers in the domain, for consistent results, it is recommended to run this command only on the primary domain controller. To check the status of each individual domain controller, it is recommended to use the ‘/GetMigrationState’ command line switch instead.

c) GetMigrationState
Format: dfsrmig /GetMigrationState
This command retrieves local migration state related information from all the domain controllers and matches it with the current global migration state that has been set for the domain on the primary domain controller. It then proceeds to summarize the results and displays whether migration is complete or pending on all domain controllers. It also mentions which domain controllers in the domain have not yet reached the global migration state set for the domain and specifies the local migration state those domain controllers are currently in.

When all domain controllers have not yet reached the global migration state, the following kind of output is displayed.

Auxiliary/Optional command line switches
These command line switches are not required during the course of a regular migration procedure from the FRS service to the DFS Replication service. However, there are some exceptional circumstances which are described below in which these command line switches come in handy for domain administrators performing SYSVOL migration. These command line options are for the most part applicable only to read only domain controllers.
d) CreateGlobalObjects
Format: dfsrmig /CreateGlobalObjects
This command line switch is useful for creating the DFS Replication service’s global settings in Active Directory manually. Usually, it is not necessary for the administrator to run this command manually since these actions are automatically performed by the DFSR Replication service when it migrates from the ‘START’ state to the ‘PREPARED’ state.
Situations where this command line switch comes in handy are:
i.New RODC Promotion during migration: Consider that a new RODC (Read Only Domain Controller) is promoted when the domain is in global migration state 1 or 2. On a Read Only domain controller, no Active Directory changes can be made since, quite simply, the domain controller is designated Read-only. Therefore, all active directory changes required for SYSVOL migration such as creating the DFS Replication service’s global settings for replicating the SYSVOL folder are made on the Primary Domain Controller in case of RODCs. These global settings contain information required by the DFS Replication service in order to replicate the SYSVOL folder’s contents between its peer domain controllers and in the absence of these settings replication activity will be stuck without progress.
The DFS Replication service automatically performs this operation (creation of global settings for the RODC) at the time of migrating from the ‘START’ state to the ‘PREPARED’ state. However, after this state transition is complete, if any new RODCs are promoted in the domain before the end to end migration process is completed (i.e. before ‘ELIMINATED’ state is reached), then the objects corresponding to that newly added read only domain controller are not added in Active Directory. In this sort of situation, the administrator needs to manually create the DFS Replication service’s global settings for the Read Only Domain Controller using this command line switch. When this command line switch is executed, settings will be created only for those read only domain controllers which do not already have them – i.e. it will not affect the domain controllers which already have the DFS Replication service’s global settings.
ii.Missing/Deleted DFS Replication service’s global settings: If the DFS Replication service’s global settings are missing for a particular domain controller, then migration will be stuck in the intermediate migration state ‘PREPARING’ without progressing to the ‘PREPARED’ state. In such cases, this command line switch can be used to manually create the DFS Replication service’s global settings.
NOTE: Since the DFS Replication service’s global settings are created on the Primary Domain Controller in case of Read Only Domain Controllers, it will take some time for these settings to be visible on the RODC. This is because these newly created settings need to replicate from the Active Directory of the Primary Domain Controller to the RODC in question, before the DFS Replication service on the RODC is able to see and consume these settings. Therefore, it is important to consider AD replication latencies when waiting for the newly created DFS Replication service’s global settings to show up on the RODC.
Following blog posts in this series will explain the DFS Replication service’s global settings in detail so administrators know what to look for.

e) DeleteRoNtfrsMember
Format: dfsrmig /DeleteRoNtfrsMember [Optional: RODC_Name]
- RODC_Name: Name of the Read Only Domain Controller whose FRS global settings are to be deleted.
This command line switch should also not be required in the course of a regular migration sequence. This command line switch is used in order to delete the FRS replication related global settings from Active Directory. This logic is also performed automatically by DFS Replication service during the transition from the ‘REDIRECTED’ state to the ‘ELIMINATED’ state. Since Read Only Domain Controllers cannot delete the FRS related global settings from their own Active Directory, this operation needs to be performed by the Primary Domain Controller in its Active Directory. When these changes eventually replicate in to the Read Only Domain Controller (after applicable AD Replication latencies), the DFS Replication service on the RODC is able to proceed with the process of migration.
For the most part, this automatic deletion of the FRS global settings on the Primary Domain Controller should be sufficient to handle all scenarios and migration should continue seamlessly. However, in the rare event that the automatic deletion failed for some reason, the system administrator needs to run this command manually. This command need only be run if the Read Only Domain controller is found to be stuck in the intermediate ‘ELIMINATING’ migration state for a long period of time without showing any signs of progress in migration.
If this command is run without any parameter, the FRS global settings for all RODCs are deleted. The administrator can also explicitly pass in the name of the RODC whose FRS global settings are to be deleted.

f) DeleteRoDfsrMember
Format: dfsrmig /DeleteRoDfsrMember [Optional: RODC_Name]
- RODC_Name: Name of the Read Only Domain Controller whose DFSR global settings are to be deleted.
This command line switch should also not be required in the course of a regular migration sequence. It is used in order to delete the DFS Replication service’s global settings from Active Directory. This logic is performed automatically by the DFS Replication service during the transition from the ‘PREPARED’ state to the ‘START’ state. Thus, this applies only in case of situations where replication is being rolled back from the ‘PREPARED’ state to the ‘START’ state. On Read Only Domain Controllers, since the DFS Replication service’s global settings cannot be deleted in Active Directory, this operation needs to be performed in the by the Primary Domain Controller in its Active Directory. When these changes eventually replicate in to the Read Only Domain Controller (after applicable AD Replication latencies), the DFS Replication service on the RODC is able to proceed with the rollback process.
For the most part, this automatic deletion of the DFS Replication service’s global settings on the Primary Domain Controller should be sufficient to handle all scenarios and migration (rollback) should continue seamlessly. However, in the rare event that the automatic deletion failed for some reason, the system administrator needs to run this command manually. This command need only be run if the Read Only Domain Controller is found to be stuck in the intermediate ‘UNDO_PREPARING’ migration state for a long period of time without showing any visible signs of progress in rollback.
If this command is run without any parameter, the DFS Replication service’s global settings for all RODCs are deleted. The administrator can also explicitly pass in the name of the RODC whose DFS Replication service settings are to be deleted.

[patris1]

http://blogs.technet.com/filecab/archive/2008/03/05/sysvol-migration-series-part-3-migrating-to-the-prepared-state.aspx

Migrating to the 'PREPARED' state


Previous articles in this series contained an introduction to the SYSVOL migration procedure and explained how the Dfsrmig.exe tool can be used for SYSVOL migration. Keeping this background information in mind, we’re now ready to start the actual SYSVOL migration process. This article explains how to migrate replication of the SYSVOL share to the ‘PREPARED’ state. If the term ‘PREPARED state’ draws a blank, head on over to this post for a quick review of the SYSVOL migration process.

Before we begin …
The domain functional level needs to be raised to ‘Windows Server 2008’ domain functional level before SYSVOL migration can commence. Therefore, the first step in the SYSVOL migration process is to upgrade all domain controllers to Windows Server 2008. This can be done in a phased manner. Once all domain controllers have been migrated to Windows Server 2008, the domain administrator is ready to raise the domain functional level to ‘Windows Server 2008’ domain functional level.
In order to raise the domain functional level to ‘Windows Server 2008’:
a)Open the ‘Microsoft Management Console’ (MMC).
b)Navigate to the ‘File’ menu and select ‘Add/Remove Snap-in…’.
c)Add the ‘Active Directory Domains and Trusts’ snap-in.
d)Select the domain whose functional level is to be raised from the left hand side pane and select ‘Raise domain functional level’ from the right click menu.
e)Select ‘Windows Server 2008’ from the drop down list and click the ‘Raise’ button to raise your domain functional level to Windows Server 2008.

Figure 1: Raise the domain functional level to 'Windows Server 2008'.

Ensure FRS is replicating fine
It is highly recommended to validate the health of the File Replication Service before commencing the migration process.
a)Ensure that SYSVOL is shared out by the domain controller. This can be done by typing ‘net share’ on the domain controller. The SYSVOL share is listed if it is being shared out by that domain controller.

b)Validate that FRS replication is healthy. Monitoring tools such as Ultrasound, Sonar and FRSDiag can be used for this purpose.

Figure 2: The 'SysvolReady' registry key.

The SYSVOL migration procedure does not begin if the SYSVOL share is not being shared out by the domain controller. If the File Replication Service has been successfully initialized to replicate the contents of the SYSVOL folder and replication is healthy, it sets the registry key ‘SysvolReady’ under ‘HKLM\System\CurrentControlSet\Services\Netlogon\Pa rameters\Sysvol’ to 1. When the Netlogon service running on that domain controller notices this registry key has been set to 1, it proceeds to share out the SYSVOL folder. The DFS Replication service will not proceed with SYSVOL migration unless SYSVOL is shared.

Take a backup
A couple of precautions are advised before starting the migration process. One amongst them is to perform a backup of the data in the SYSVOL folder on the Primary Domain Controller. Copy the contents of the existing SYSVOL folder to an alternate location. Windows Server 2008 also ships a new in box backup application called Windows Server Backup, which can be used to perform a System State Backup of the domain controller.

Migrating to ‘PREPARED’ state
Let’s look at how to go about migrating the domain to the ‘PREPARED’ state. Please follow the below mentioned steps and pay special attention to any caution or warnings that are mentioned below.
üSTEP 1: Verify that DFSR is installed and running on all domain controllers.
Launch the ‘Services’ MMC snap-in (services.msc) and check to see whether the DFS Replication service is installed and running on the domain controller. It is necessary for the DFS Replication service to be started and running on all domain controllers which need to be migrated since that is the only way the service will poll Active Directory and notice the migration directive.
·On a freshly installed Windows Server 2008 machine, the DFS Replication service is installed and started by DCPROMO when the machine is promoted to a domain controller. The DfsrMig.exe tool which is used for migration is also installed on the machine at that point in time.
·If an upgrade from Windows Server 2003 is done, the DFS Replication service is installed and started by the upgrade process.
The command ‘sc \\MACHINE_NAME query dfsr’ can be used to remotely query the Service Control Manager running on a domain controller to find out if the DFS Replication service is running.

üSTEP 2: Check health of Active Directory Replication.
Since the migration directive is set on the Primary Domain Controller and needs to be replicated to the Active Directory on each of the replica domain controllers in the domain, it is necessary to ensure that Active Directory replication is working fine. This can be done using the ‘RepAdmin /ReplSum’ command. This step assumes importance in case of remote domain controllers, since those domain controllers will participate in SYSVOL migration only after noticing the migration directive, which in turn is dependent on Active Directory replication between the two sites.

üSTEP 3: Set the migration directive.
On the Primary Domain Controller, run the dfsrmig.exe tool and set the migration global state to ‘PREPARED’ state (State 1). It is recommended not to directly set the migration state to 3 (‘ELIMINATED’) but to rather proceed through each of the migration states individually. This enables the possibility of rolling back migration in case things are not working as expected. Here’s how to migrate to the ‘PREPARED’ state.

Figure 3: Migrating to the 'PREPARED' state.

üSTEP 4: Monitor to ensure that all domain controllers have reached the ‘PREPARED’ state successfully.
Use the ‘dfsrmig /getMigrationState’ command line switch to ensure that all domain controllers have successfully migrated to the ‘PREPARED’ state. Ensure that the output for this command mentions that all domain controllers have reached the ‘PREPARED’ state before proceeding to migrate the domain to the ‘REDIRECTED’ state.

Figure 3: Migrating to the 'PREPARED' state.

When all domain controllers have successfully migrated to the ‘PREPARED’ state, the following kind of output is obtained as a result of executing the ‘/getMigrationState’ command line switch. When the DFS Replication service on each domain controller reaches the ‘PREPARED’ state, Information event 8014 will be registered in the event log.

What happens under the hood?
When the DFS Replication service notices the migration directive that has been set in Active Directory instructing it to migrate to the global migration state of ‘PREPARED’, it performs the following sequence of operations on each domain controller:

1. The SYSVOL migration tool then creates and populates the registry key ‘HKLM\System\CurrentControlSet\Services\DFSR\Parame ters\SysVols\Migrating SysVols’. This registry key contains the value of the local migration state for that domain controller. The local state is now set to 4 (‘PREPARING’).
2. The DFS Replication service creates a folder called ‘SYSVOL_DFSR’ at the same location as the original ‘SYSVOL’ folder that is being replicated by FRS. All immediate sub-folders of the original ‘SYSVOL’ folder are also created and their ACLs are duplicated within this newly created ‘SYSVOL_DFSR’ folder. In order to complete migration successfully, the volume hosting the SYSVOL folder must have enough space to hold a clone of the folder.
3. The DFS Replication service then copies the contents of the ‘SYSVOL\domain’ folder to the ‘SYSVOL_DFSR\domain’ folder using robocopy.exe. Note that the DFS Replication service replicates all files and folders under the ‘SYSVOL_DFSR\Domain’ folder only.
4. The SYSVOL junction point is then created under ‘SYSVOL_DFSR\sysvol’. This junction point points to the ‘SYSVOL_DFSR\domain’ folder.
5. The DFS Replication service creates global settings in Active Directory. These global settings configure the DFS Replication service running on that domain controller to replicate the ‘SYSVOL_DFSR’ folder amongst its peers. On the Primary Domain Controller, it creates member objects for each RODC that exists at that point in time in the Primary Domain Controller’s Active Directory.
6. The migration local state is set to 5 (‘WAITING FOR INITIAL SYNC’). Thereafter, the DFS Replication service performs initial sync and builds up entries for all files in the ‘SYSVOL_DFSR’ folder in its jet database.
7. When DFS Replication completes Initial Sync, the Local State is set to 1 (’PREPARED’).

During this migration process, the local migration state on the domain controller will cycle through the intermediate states of ‘PREPARING’ (State 4) and ‘WAITING FOR INITIAL SYNC’ (State 5). All domain controllers undergo this procedure until they reach the ‘PREPARED’ migration state. Thereafter, the administrator is ready to proceed with migrating to the ‘REDIRECTED’ state.

Can this migration step be rolled back?
Yes, absolutely! In order to rollback this migration step, an administrator can run the dfsrmig.exe tool and set the global migration state back to 0 (‘START’ state). This command will cause the DFS Replication service to cycle through the reverse set of steps and the ‘SYSVOL_DFSR’ folder will then be deleted.

Read-only Domain Controllers
The SYSVOL migration process is designed to automatically migrate replication of the SYSVOL share to the DFS Replication service on read-only domain controllers as well. However, there are certain important points to note in case of read-only domain controllers.
a)In case of migration to the ‘PREPARED’ state, the DFS Replication service needs to create settings corresponding to the ‘SYSVOL_DFSR’ replicated folder in Active Directory. However, read-only domain controllers are not allowed to modify their Active Directory. Therefore, in case of read-only domain controllers, the Primary Domain Controller will perform these activities on behalf of the read-only domain controller and will create these settings in its Active Directory. When these settings replicate out to the read-only domain controller, it is able to proceed with the SYSVOL migration process. Therefore, it is not uncommon to find a read-only domain controller taking a long time at the intermediate local state 4 (‘PREPARING’), while it is waiting for the Primary Domain Controller to create its DFSR settings.
b)In case of a rollback from the ‘PREPARED’ state, the DFS Replication service needs to delete the corresponding settings in Active Directory. Once again, since read-only domain controller cannot modify the objects in Active Directory it relies on the Primary Domain Controller doing so on its behalf. Therefore, it is not uncommon to find that the read-only domain controller takes a longer time at the intermediate local state 9 (‘UNDO PREPARING’), while it waits for the Primary Domain Controller to delete its DFSR settings.
Active Directory replication takes a little longer to replicate Active Directory objects and settings to a read-only domain controller as compared to a writable domain controller. Therefore, the SYSVOL migration process will take a little longer on the read-only domain controller as compared to a writable domain controller.
Monitoring things closely
SYSVOL migration is designed to automatically recognize the migration directive and take steps on each domain controller to comply with that directive. Therefore, for the most part, the ‘/getMigrationState’ command should be sufficient to monitor the progress of migration to the ‘PREPARED’ state.
However, it is also possible for an administrator to monitor the domain controller closely and ensure that the tasks performed by the DFS Replication service while migrating to the ‘PREPARED’ state have been completed successfully. There are also some troubleshooting steps that can be performed to speed up Active Directory replication and Active Directory poll induced delays in the migration process.
a)Verify that DFSR Global Settings have been created. Navigate using ADSIEdit to ‘CN=DFSR-GlobalSettings’ and check to see if the following DFSR settings have been created.
·Run adsiedit.msc.
·Connect to “Default naming context”
·Expand domain.
·Expand “CN=SYSTEM”
·There should be “CN=DFSR-GlobalSettings”. All DFSR global settings are stored below this.

b)Verify the current local state on each domain controller. Navigate through the registry to the location ‘HKLM\System\CurrentControlSet\Services\DFSR\Parame ters\SysVols\Migrating SysVols’ and check to see if the following registry keys have been created. The registry key ‘LocalState’ contains the current local state of migration on that domain controller.

c)Force Active Directory replication on a domain controller. In order to force Active Directory replication, issue the command ‘repadmin /syncall /AeD’ on the domain controller.


d)Force the DFS Replication service to poll Active Directory. In order to force an Active Directory poll, issue the command ‘dfsrdiag PollAd /Member:REPLACEWITHDCNAME’ on the domain controller.


e)If you find that migration is taking a long time to reach the ‘PREPARED’ state on a particular domain controller, the following set of monitoring steps may be taken:
·Issue the ‘dfsrmig /getGlobalState’ command to find the global migration state and ensure that it is indeed set to ‘PREPARED’. If this command is issued on the domain controller that is taking long, the administrator can figure out whether Active Directory replication has completed replication of the migration directive to that domain controller.
·Check to see the local migration state. The local state could take any of the values below:
·Local state 0 (‘START’ state)
·Local state 4 (intermediate ‘PREPARING’ state)
·Local state 5 (intermediate ‘WAITING FOR INITIAL SYNC’ state)
·Local state 1 (‘PREPARED’ state). This usually signifies that the domain controller has completed migration to the ‘PREPARED’ state.
·Note that there are possible reasons for delay. Ensure that you are cognizant of these and have given enough time for these latencies to ‘play out’.
-Read only domain controllers will take longer due to Active Directory replication latencies and when they’re waiting for the Primary Domain Controller to modify Active Directory objects on their behalf.
-The migration directive relies on Active Directory replication to be ‘visible’ on each individual domain controller. Therefore, the rate at which each domain controller notices and acts upon the migration directive is dependent on Active Directory replication latencies.
·Check to see the Eventlog for any events (Warning or Error) which the DFS Replication service logs during the SYSVOL migration process. These events will tell you more about what operations have completed and whether the service is stuck for any particular reason.


Taking stock
Now that we’ve completed migration of the domain to the ‘PREPARED’ state, it is time to take stock of things. In the ‘PREPARED’ state:

• Both FRS and DFSR are replicating their own copies of the contents of the SYSVOL folder. FRS is replicating the ‘SYSVOL’ folder while DFSR is replicating the ‘SYSVOL_DFSR’ folder.
• The SYSVOL share that is advertised by the domain controller is still the ‘SYSVOL’ folder that is replicated by FRS. Therefore, the main replication engine on the domain in the ‘PREPARED’ state is still FRS.
• It is recommended to wait until all domain controllers have reached the ‘PREPARED’ state before proceeding with migration to the ‘REDIRECTED’ state.
• If migration isn’t proceeding as expected, it is possible to rollback from the ‘PREPARED’ state to the ‘START’ state by setting the global migration state to ‘START’ (0) using the dfsrmig.exe tool.

In the next few blog posts in this series, we’ll complete the migration process first to the ‘REDIRECTED’ state and then finally on to the ‘ELIMINATED’ state.

[patris1]

http://blogs.technet.com/filecab/archive/2008/03/17/sysvol-migration-series-part-4-migrating-to-the-redirected-state.aspx

Part 4 – Migrating to the ‘REDIRECTED’ state


The previous article in this series explained how to migrate replication of the SYSVOL share to the ‘PREPARED’ state. In this article, we examine how to migrate all domain controllers to the ‘REDIRECTED’ state.


Before we begin …
Before migrating to the ‘REDIRECTED’ state, a couple of precautions are advised.

a)All domain controllers are in ‘PREPARED’ state: The most important precaution is to ensure that all domain controllers have successfully migrated to the ‘PREPARED’ state before changing the global migration state to the ‘REDIRECTED’ state. Depending upon Active Directory replication latencies and the amount of data present in the ‘SYSVOL’ share, it might take a while before all domain controllers in the domain successfully migrate to the ‘PREPARED’ state. As mentioned in the previous article, the dfsrmig.exe command line switch ‘GetMigrationState’ can be used to ensure that all domain controllers have reached the ‘PREPARED’ state.
b)Verify that the SYSVOL share is still being shared out: by all domain controllers. This can be done by typing ‘net share’ on the domain controller. The SYSVOL share is listed if it is being shared out by that domain controller. Verify that the SYSVOL share path is still pointing to the same location as before starting the entire SYSVOL migration process. This is because in the ‘PREPARED’ state, the ‘SYSVOL’ folder that FRS is replicating is still the one shared out on the domain controller. Please see the ‘Taking Stock’ section of the previous article for a quick recap.

Figure 1: The 'SysvolReady' registry key.

Migrating to ‘REDIRECTED’ state
Let’s look at how to migrate SYSVOL replication on the domain to the ‘REDIRECTED’ state. Please follow the below mentioned steps and pay special attention to any caution or warnings that are mentioned below.

üSTEP 1: Check health of Active Directory Replication.
Since the migration directive is set on the Primary Domain Controller and needs to be replicated to the Active Directory on each of the replica domain controllers in the domain, it is necessary to ensure that Active Directory replication is working fine. This can be done using the ‘RepAdmin /ReplSum’ command. This step assumes importance in case of remote domain controllers, since those domain controllers will participate in SYSVOL migration only after noticing the migration directive, which in turn is dependent on Active Directory replication between the two sites.

üSTEP 2: Set the migration directive.
On the Primary Domain Controller, run the dfsrmig.exe tool and set the migration global state to ‘REDIRECTED’ state (State 2). It is recommended not to directly set the migration state to 3 (‘ELIMINATED’) but to rather proceed through each of the migration states individually. This enables the possibility of rolling back migration in case things are not working as expected. Issue the command ‘dfsrmig /setGlobalState 2’ on the Primary Domain Controller to commence migration to the ‘REDIRECTED’ state.

üSTEP 3: Monitor to ensure that all domain controllers have reached the ‘REDIRECTED’ state successfully.
Use the ‘dfsrmig /getMigrationState’ command line switch to ensure that all domain controllers have successfully migrated to the ‘REDIRECTED’ state. Ensure that the output for this command mentions that all domain controllers have reached the ‘REDIRECTED’ state before the domain is migrated to the ‘ELIMINATED’ state.
When the DFS Replication service on each domain controller reaches the ‘REDIRECTED’ state, Information event 8017 will be registered in its event log.

What happens under the hood?
When the DFS Replication service notices the migration directive that has been set in Active Directory instructing it to migrate to the global migration state ‘REDIRECTED’, it performs the following sequence of operations on each domain controller:

a)The migration local state is set to 6 (‘REDIRECTING’).
b)Since the domain controller can be in the ‘PREPARED’ state for a while before migrating to the ‘REDIRECTED’ state, the ‘SYSVOL’ and ‘SYSVOL_DFSR’ folders can get out of sync. This is because any group policy changes that are made on the domain after migrating to the ‘PREPARED’ state will be made only on the SYSVOL share. Remember that in the ‘PREPARED’ state, the ‘SYSVOL’ folder that is being replicated by FRS is the one that is shared out by the domain controller. Therefore, any group policy changes are made only in the ‘SYSVOL’ folder and the ‘SYSVOL_DFSR’ folder is not in sync with it. In other words, the DFS Replication service ‘will not see’ such changes.
Therefore, the DFS Replication service updates the ‘SYSVOL_DFSR’ folder with the contents of the ‘SYSVOL’ folder before starting the migration to the ‘REDIRECTED’ state. Note that this happens only on the Primary Domain Controller, since these changes will then be replicated out to all other replica domain controllers by the DFS Replication service.

c)The DFS Replication service now performs the following set of actions on every domain controller:
·It sets the ‘SysvolReady’ registry key to ‘FALSE’ (0). This causes the Netlogon service to stop sharing out SYSVOL on that domain controller.
·It then updates the SYSVOL share path (‘SysVol’ registry key) to point to the new ‘SYSVOL_DFSR’ folder that is being replicated by the DFS Replication service. This is the operation that causes the redirection of SYSVOL replication from FRS to the DFS Replication service.
·Thereafter, it sets the ‘SysvolReady’ registry key back to ‘TRUE’ (1). This causes the Netlogon service to resume sharing out SYSVOL on the domain controller.
d)A dependency is added such that the NTDS service depends on the DFS Replication service. This ensures that after reboots of the domain controller, the DFS Replication service too is started along with Directory Services.

e)The migration local state is set to 2 (’REDIRECTED’). From this point onwards, the SYSVOL share advertised by the domain controller is the one that is replicated using the DFS Replication service.

During this migration process, the local migration state on the domain controller will cycle through the intermediate state of ‘REDIRECTING’ (State 6). All domain controllers undergo this procedure until they reach the ‘REDIRECTED’ migration state. Thereafter, the administrator is ready to proceed with migrating to the ‘ELIMINATED’ state.


Can this migration step be rolled back?
Yes, absolutely! In order to rollback this migration step, an administrator can run the dfsrmig.exe tool and set the global migration state back to 0 (‘START’ state) or 1 (‘PREPARED’ state). This command will cause the DFS Replication service to cycle through the reverse set of steps that were taken during migration. The intermediate states 8 (‘UNDO REDIRECTING’) and 9 (‘UNDO PREPARING’) will be encountered during this roll back process.

Note that if the domain controllers are in ‘REDIRECTED’ state for an extended period of time, and if any group policy changes are made on the domain in that time period, those changes are reflected only in the ‘SYSVOL_DFSR’ folder. Thus, the older SYSVOL folder which is being replicated by FRS will not be in sync with these changes. If the admin decides to roll back migration to the ‘PREPARED’ state, the DFS Replication service syncs the ‘SYSVOL’ folder with the contents of the ‘SYSVOL_DFSR’ folder on the Primary Domain Controller during the rollback process. FRS then replicates these updates to the other replica domain controllers.


Monitoring things closely
SYSVOL migration is designed to automatically recognize the migration directive and take steps on each domain controller to comply with that directive. Therefore, for the most part, the ‘/getMigrationState’ command should be sufficient to monitor the progress of migration to the ‘REDIRECTED’ state.
However, it is also possible for an administrator to monitor the domain controller closely and ensure that the tasks performed by the DFS Replication service while migrating to the ‘REDIRECTED’ state have been completed successfully. There are also some troubleshooting steps that can be performed to speed up Active Directory replication and Active Directory poll induced delays in the migration process.

a)Verify the current local state on each domain controller. Navigate through the registry to the location ‘HKLM\System\CurrentControlSet\Services\DFSR\Parame ters\SysVols\Migrating SysVols’ and check to see the value of the registry key ‘LocalState’. Ensure this registry key is set to 2 once the domain controller has migrated to the ‘REDIRECTED’ state.

b)Ensure that SYSVOL share replication has indeed been redirected. In order to ensure that the DFS Replication service is replicating the SYSVOL share that is shared out on the domain, check to see the value of the ‘SysVol’ and ‘SysvolReady’ registry keys mentioned above. Ensure that the ‘SysVol’ registry key is pointing to the location of the ‘SYSVOL_DFSR’ folder.
c)Force Active Directory replication on a domain controller. In order to force Active Directory replication, issue the command ‘repadmin /syncall /AeD’ on the domain controller.
d)Force the DFS Replication service to poll Active Directory. In order to force an Active Directory poll, issue the command ‘dfsrdiag PollAd’ on the domain controller. To force an Active Directory poll on another domain controller issue the command ‘dfsrdiag PollAd /MemberC_NAME’.
e)If you find that migration is taking a long time to reach the ‘PREPARED’ state on a particular domain controller, the following set of monitoring steps may be taken:
·Issue the ‘dfsrmig /getGlobalState’ command to find the global migration state and ensure that it is indeed set to ‘REDIRECTED’. If this command is issued on the domain controller that is taking a long time to migrate, the administrator can figure out whether Active Directory replication has completed replication of the migration directive to that domain controller.
·Check to see the local migration state. The local state could take any of the values below during this migration step:
·Local state 1 (‘PREPARED’ state)
·Local state 6 (intermediate ‘REDIRECTING’ state)
·Local state 2 (‘REDIRECTED’ state). This usually signifies that the domain controller has completed migration to the ‘REDIRECTED’ state.
·Note that there are valid reasons for delay. Ensure that you are cognizant of these and have given enough time for these latencies to ‘play out’.
-The migration directive relies on Active Directory replication to be ‘visible’ on each individual domain controller. Therefore, the speed with which each domain controller notices and acts upon the migration directive is dependent on Active Directory replication latencies.
·Check to see the Eventlog for any events (Warning or Error) which the DFS Replication service logs during the SYSVOL migration process. These events will tell you more about what operations have completed and whether the service is stuck for any particular reason.


Taking stock
Now that we’ve completed migration of the domain to the ‘REDIRECTED’ state, it is time to take stock of things. In the ‘REDIRECTED’ state:

a)Both FRS and DFSR are replicating their own copies of the contents of the SYSVOL folder. FRS is replicating the ‘SYSVOL’ folder while DFSR is replicating the ‘SYSVOL_DFSR’ folder.
b)The SYSVOL share that is advertised by the domain controller is now the ‘SYSVOL_DFSR’ folder that is replicated by the DFS Replication service. Therefore, the main replication engine on the domain in the ‘REDIRECTED’ state is DFSR.
c)It is recommended to wait until all domain controllers have reached the ‘REDIRECTED’ state before proceeding with migration to the ‘ELIMINATED’ state.
d)If things are not going as per expectation, it is possible to rollback from the ‘REDIRECTED’ state to the ‘PREPARED’ state or the ‘START’ state by setting the global migration state appropriately using the dfsrmig.exe tool.
In the next blog post in this series, we’ll complete the migration process to the ‘ELIMINATED’ state and eliminate the use of FRS for SYSVOL replication on the domain.

[patris1]

http://blogs.technet.com/filecab/archive/2008/03/19/sysvol-migration-series-part-5-migrating-to-the-eliminated-state.aspx

Part 5 – Migrating to the ‘ELIMINATED’ state


The previous article in this series explained how to migrate replication of the SYSVOL share to the ‘REDIRECTED’ state. In this article, we examine how to complete migration of all domain controllers to the ‘ELIMINATED’ state.



Before we begin …
Remember that the migration process to the ‘ELIMINATED’ state cannot be reverted under any circumstances. Therefore, ensure that SYSVOL replication using the DFS Replication service is healthy, before committing entirely to finalizing the migration process.
Before migrating to the ‘ELIMINATED’ state, a couple of precautions are advised.


a)All domain controllers are in ‘REDIRECTED’ state: The most important precaution is to ensure that all domain controllers have successfully migrated to the ‘REDIRECTED’ state before changing the global migration state to the ‘ELIMINATED’ state. As mentioned in the previous article, the command line switch ‘GetMigrationState’ can be used to ensure that all domain controllers have reached the ‘REDIRECTED’ state.

b)Verify that the SYSVOL share is still being shared out: by all domain controllers and that the SYSVOL share path points to the path that is being replicated by the DFS Replication service (the ‘SYSVOL_DFSR’ folder location). This can be done by typing ‘net share’ on the domain controller. The SYSVOL share is listed if it is being shared out by that domain controller.


Migrating to ‘ELIMINATED’ state
Let’s look at how to migrate SYSVOL replication on the domain to the ‘ELIMINATED’ state. Please follow the below mentioned steps and pay special attention to any caution or warnings that are mentioned below.


üSTEP 1: Check health of Active Directory Replication.
Since the migration directive is set on the Primary Domain Controller and needs to be replicated to the Active Directory on each of the replica domain controllers in the domain, it is necessary to ensure that Active Directory replication is working fine. This can be done using the ‘RepAdmin /ReplSum’ command. This step assumes importance in case of remote domain controllers, since those domain controllers will participate in SYSVOL migration only after noticing the migration directive, which in turn is dependent on Active Directory replication between the two sites.

üSTEP 2: Set the migration directive.
On the Primary Domain Controller, run the dfsrmig.exe tool and set the migration global state to ‘ELIMINATED’ state (State 3). Issue the command ‘dfsrmig /setGlobalState 3’ on the Primary Domain Controller to commence migration to the ‘ELIMINATED’ state.

üSTEP 3: Monitor to ensure that all domain controllers have reached the ‘ELIMINATED’ state successfully.
Use the ‘dfsrmig /getMigrationState’ command to ensure that all domain controllers have successfully migrated to the ‘ELIMINATED’ state. Ensure that the output for this command mentions that all domain controllers have reached the ‘ELIMINATED’ state.
When the DFS Replication service on each domain controller reaches the ‘ELIMINATED’ state, Information event 8019 will be registered in the event log.


What happens under the hood?
When the DFS Replication service notices the migration directive that has been set in Active Directory instructing it to migrate to the global migration state ‘ELIMINATED’, it performs the following sequence of operations on each domain controller:


a)The migration local state is set to 7 (’ELIMINATING’).

b)The DFS Replication service now performs the following set of actions on every domain controller:
·The dependency between the NTDS service and the FRS service is now removed.
·If the FRS service is running on the domain controller, it is then stopped. It deletes the Active Directory configuration settings required for the FRS service to replicate the SYSVOL share between domain controllers. Thus, all global settings of the FRS service that pertain to the SYSVOL content set are deleted.
·The ‘SYSVOL’ folder which was being replicated by the FRS service is now deleted. Note that if you have Windows Explorer or the command shell open on the domain controller and if the current directory corresponds to the ‘SYSVOL’ folder location, the DFS Replication service will be unable to delete this folder owing to sharing violations.
·If the FRS service is replicating any other content sets (apart from SYSVOL) on the domain controller, it is then started up again.
c)The migration local state is set to 3 (’ELIMINATED’). From this point onwards, the SYSVOL share advertised by the domain controller is the one that is replicated using the DFS Replication service. The FRS service no longer replicates any copy of the ‘SYSVOL’ folder on the domain controller.

During this migration process, the local migration state on the domain controller will cycle through the intermediate state of ‘ELIMINATING’ (State 7). All domain controllers undergo this procedure until they reach the ‘ELIMINATED’ migration state.


Can this migration step be rolled back?
No! At this point, the use of FRS on the domain controller for SYSVOL replication purposes has been eliminated.


Monitoring things closely
SYSVOL migration is designed to automatically recognize the migration directive and take steps on each domain controller to comply with that directive. Therefore, for the most part, the ‘/getMigrationState’ command should be sufficient to monitor the progress of migration to the ‘ELIMINATED’ state.
However, it is also possible for an administrator to monitor the domain controller closely and ensure that the tasks performed by the DFS Replication service while migrating to the ‘ELIMINATED’ state have been completed successfully. There are also some troubleshooting steps that can be performed to speed up Active Directory replication and Active Directory poll induced delays in the migration process.


a)Verify the current local state on each domain controller. Navigate through the registry to the location ‘HKLM\System\CurrentControlSet\Services\DFSR\Parame ters\SysVols\Migrating SysVols’ and check to see the value of the registry key ‘LocalState’. Ensure this registry key is set to 3 once the domain controller has migrated to the ‘ELIMINATED’ state.

b)Ensure that SYSVOL share replication has indeed been redirected. In order to ensure that the DFS Replication service is replicating the SYSVOL share that is shared out on the domain, check to see the values of the ‘SysVol’ and ‘SysvolReady’ registry keys mentioned above. Ensure that the ‘SysVol’ registry key is pointing to the ‘SYSVOL_DFSR’ folder location. Once the migration to the ‘ELIMINATED’ state is complete, ensure that the old copy of the ‘SYSVOL’ folder that was being replicated by FRS is deleted.
c)Force Active Directory replication on a domain controller. In order to force Active Directory replication, issue the command ‘repadmin /syncall /AeD’ on the domain controller.

d)Force the DFS Replication service to poll Active Directory. In order to force an Active Directory poll, issue the command ‘dfsrdiag PollAd’ on the domain controller. To force an Active Directory poll on another domain controller issue the command ‘dfsrdiag PollAd /MemberC_NAME’.

e)If you find that migration is taking a long time to reach the ‘ELIMINATED’ state on a particular domain controller, the following set of monitoring steps may be taken:
·Issue the ‘dfsrmig /getGlobalState’ command to find the global migration state and ensure that it is indeed set to ‘ELIMINATED’. If this command is issued on the domain controller that is taking a long time to migrate, the administrator can figure out whether Active Directory replication has completed replication of the migration directive to that domain controller.
·Check to see the local migration state. The local state could take any of the values below during this migration step:
·Local state 2 (‘REDIRECTED’ state)
·Local state 7 (intermediate ‘ELIMINATING’ state)
·Local state 3 (‘ELIMINATED’ state). This usually signifies that the domain controller has completed migration to the ‘ELIMINATED’ state.
·Note that there are valid reasons for delay. Ensure that you are cognizant of these and have given enough time for these latencies to ‘play out’.
-The migration directive relies on Active Directory replication to be ‘visible’ on each individual domain controller. Therefore, the speed with which each domain controller notices and acts upon the migration directive is dependent on Active Directory replication latencies.
-During this migration process, the DFS Replication service needs to delete the corresponding FRS settings in Active Directory. Since read-only domain controllers cannot modify objects in Active Directory they rely on the Primary Domain Controller doing so on their behalf. Therefore, it is not uncommon to find that a read-only domain controller takes a longer time at the intermediate local state 7 (‘ELIMINATING’), while it waits for the Primary Domain Controller to delete its FRS settings.
·Check to see the Eventlog for any events (Warning or Error) which the DFS Replication service logs during the SYSVOL migration process. These events will tell you more about what operations have completed and whether the service is stuck for any particular reason.


Taking stock
Now that we’ve completed migration of the domain to the ‘ELIMINATED’ state, it is time to take stock of things. In the ‘ELIMINATED’ state:


a)Only DFSR is replicating the SYSVOL share on the domain.
b)The SYSVOL share that is advertised by the domain controller corresponds to the ‘SYSVOL_DFSR’ folder that is replicated by the DFS Replication service. Therefore, the main replication engine on the domain in the ‘ELIMINATED’ state is DFSR.
c)New domain controllers that are promoted after reaching the ‘ELIMINATED’ state will default to using the DFS Replication service for replicating the contents of the SYSVOL share.
d)It is not possible to rollback from the ‘ELIMINATED’ state.
The author would like to thank Wakkas Rafiq, Jatin Shah, Christophe Robert on the DFS Replication Service product team for their help with these articles and indeed for building this feature in Windows Server 2008.