Using DFSR for SYSVOL replication in Windows Server 2008

With the release of Windows Server 2008, admins can now use DFSR for SYSVOL replication (instead of FRS). The catch? A tricky migration process when upgrading from Windows Server 2003.

File Replication Service (FRS)—with all its Burflags, cryptic logs and hotfixes— was a fly in the ointment for...

admins ever since its implementation with Windows 2000.When Microsoft released Windows Server 2003 R2, administrators finally found some relief with the improved, efficient and more reliable replication engine known as Distributed File System Replication (DFSR).

More on Windows
file system management

Key DFS improvements in R2

Troubleshoot NTFS permissions

Distributed File System Tutorial

Unfortunately in R2, Microsoft only had time to add DFSR to replicate DFS data, meaning that System Volume (SYSVOL) data still required the use of FRS for replication. In Windows 2008, users can now migrate SYSVOL to use the new DFSR engine and turn off FRS—once and for all.

DFSR (not FRS) is the replication engine used for SYSVOL upon initial installation of a Windows 2008 domain. But when you upgrade a Windows Server 2003 domain to Windows 2008, FRS will replicate SYSVOL, not DFSR. You must migrate from FRS to DFSR for SYSVOL; DFSR replication for DFS shares is the same as it was in R2.

SYSVOL migration to DFSR can be compared to the Domain Rename operation in Windows Server 2003. It uses a command-line utility, DFSRMig.exe. There are several phases you must initiate using the command-line tool, and this all must be initiated from a single machine. Like Domain Rename, it depends on Active Directory (AD) replication to transfer instructions to all DCs; however, SYSVOL migration to DFSR is more resilient and offers users an escape route. You can back out of the migration prior to implementing the final step.

Preparing for the migration

Every migration process involves some prior preparation. Following are some prerequisites that must be met before beginning the move.

  • Set the domain functional level to Windows Server 2008 using the same method that you did in Windows Server 2003.
  • Ensure that FRS is healthy. Tools such as Ultrasound, Sonar and FRSDiag can be used to monitor its health. Be sure that the staging directories are not backed up, and look for errors and warnings in the NTFRS event logs.
  • Be sure that AD replication is healthy. To perform a quick check, use the Repadmin/Replsum/bysrc/ bydest/sort:Delta command.
  • Understand replication latency in your forest to get an idea of how long DFSR migration will take.
  • Back up the existing SYSVOL folder. If FRS is healthy and staging directories are empty, you only need to back up one of the DC's SYSVOL. This should be done on the Primary Domain Controller (PDC).
  • DFSR should have started by default, but double check.
  • Locate the DFSRmig.exe tool in %windir%\System32. This only exists on DCs. Figure 1 shows the DFSRmig help file, which will be beneficial during migration.
  • The entire migration process will take place from within the PDC. Be sure that you have access to it.

FIGURE 1 (click to enlarge)

Four migration steps

There are four steps to this migration process, each of which is referred to as a "State."

State 0: Start—This is the default state for a domain that was upgraded to Windows Server 2008 domain functional mode. No actions have been performed.

NOTE: A newly installed Windows 2008 domain that has always been in domain functional mode will show an initial state of Expired.

State 1: Prepared—Creates a new SYSVOL_DFSR folder, and copies SYSVOL contents to it.

State 2: Redirected—Points the SYSVOL share path to the SYSVOL_DFSR folder, and then restarts Netlogon.

State 3: Eliminated—Deletes old NTFRS AD objects and the SYSVOL folder.

NOTE: This is the last point in the migration process in which you can revert back to FRS and SYSVOL. Moving to the next migration state is destructive.

In terms of the replication engine, this migration is a gradual move from FRS to DFSR (Table 1).


Global migration state and local migration state

The global migration state is a global "directive" that includes any instructions the PDC gives to other DCs in the domain to perform local operations and obtain a certain state. When using the dfsrmig/setGlobalState 1 command, the state directive is stored in Active Directory and then replicated to all DCs.When each DC obtains the state information, it begins a local migration process to bring itself up to that state.

Administrators performing this migration should know when all DCs have performed their local operations before transitioning to the next state. Two commands should be used to do this:

  • DFSRmig/getGlobalState—Returns what the global "directive" is. It's not a report of what the DCs have achieved, but it alerts you that you've instructed the DCs to get to a specific state using the /setGlobalState command.
  • DFSRmig/getMigrationState— Reports if all DCs have achieved a particular state. This command also reports which DCs haven't achieved a certain state. If DCs remain in this condition, investigate the cause (i.e., broken replication, network issue, etc.), and correct it. The DC will proceed once the condition is fixed.
  • NOTE: While these commands can be run on any DC, Microsoft recommends running them on the PDC to check the migration progress.

Migrating to DFSR

1. You should begin at Start State: No command needed. If you issue a DFSRmig/getGlobalState, it should read Start. If it denotes Eliminated, you have either achieved the migration, or it is a native domain and not an upgradedWindows 2008 domain.

2. Migrate to Prepared State: DFSRMig/setGlobalState 1.

  1. Create global settings and global AD objects.
  2. Create member objects for readonly domain controllers (RODCs).
  3. Create a SYSVOL_dfsr folder.
  4. Robocopy copies SYSVOL contents to SYSVOL_dfsr folder.
  5. Local AD objects are created.
  6. FRS remains as the SYSVOL replication engine.

3. DFSRMig/getMigrationState— Ensure that all DCs are at State 1.

  1. Netlogon stops sharing SYSVOL.
  2. SYSVOL path points to SYSVOL_dfsr.
  3. Netlogon shares SYSVOL.

4. DFSRMig/getMigrationState— Ensure that all DCs are at State 2.

5. Eliminated state—DFSRMig/ setMigrationState 3

  1. You cannot revert to FRS after this step.
  2. Delete NTFRS AD objects.
  3. Delete SYSVOL folder.
  4. NTFRS does not stop automatically if it's used to replicate non- SYSVOL (DFS) folders. An admin must stop and disable it manually.

6. Validate: DFSRMig/get MigrationState—Ensure that all DCs are in the Eliminated State.

7. Be sure that replication is healthy and that policies are replicating. Check the event log for errors.

Reverting back to FRS

The ability to revert back to FRS if something goes wrong makes this migration low risk. How this occurs is the interesting aspect.

During the migration process, at State 3: Redirected, you will replicate SYSVOL with DFSR, but FRS is still present.

Suppose you determine that the new DFSR structure, which has been replicated under the folder SYSOVOL_ DFSR, is not replicating properly. This may occur because one of the DCs isn't getting updates to the Redirected State or there is an AD replication problem. This also could mean that the maintenance window that administers this will expire in 30 minutes. There are several things that can happen, but you can try again.

To back out, use the /setMigrationState command and set the migration to an earlier state. For example, if you want to back all the way out of the migration at State 2: Redirected, instruct the system to go back to State 0 using the command:

DFSRmig/setMigrationState 0

This moves DCs back to the Start State. If you want to revert back one step, you could also move to State 1 using the command:

DFSRmig/setMigrationState 1

If AD replication fails, there may be a network outage. If so, fix the AD replication problem .When the global directive is sent to that DC, the migration will occur and no additional intervention is needed.

Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.

Dig Deeper on Windows Server troubleshooting