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\Parameters\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:
-
The SYSVOL migration tool then creates and populates the registry key ‘ HKLM\System\CurrentControlSet\Services\DFSR\Parameters\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’).
-
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.
-
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.
-
The SYSVOL junction point is then created under ‘SYSVOL_DFSR\sysvol’. This junction point points to the ‘SYSVOL_DFSR\domain’ folder.
-
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.
-
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.
-
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\Parameters\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.
More articles on SYSVOL Migration Series:
1:
SYSVOL Migration Series: Part 1 – Introduction to the SYSVOL migration process
2:
SYSVOL Migration Series: Part 2 – Dfsrmig.exe: The SYSVOL migration tool
4:
SYSVOL Migration Series: Part 4 – Migrating to the ‘REDIRECTED’ state
5:
SYSVOL Migration Series: Part 5 – Migrating to the ‘ELIMINATED’ state
-------