[{"document_url": "https://searchwindowsserver.techtarget.com/tip/Using-DFSR-for-SYSVOL-replication-in-Windows-Server-2008", "unformatted_src": "https://cdn.ttgtmedia.com/rms/onlineImages/olsen_gary.jpg", "src": "https://cdn.ttgtmedia.com/rms/onlineImages/olsen_gary.jpg", "formatted_filename": "olsen gary"}, null, {"document_url": "https://searchwindowsserver.techtarget.com/tip/Using-DFSR-for-SYSVOL-replication-in-Windows-Server-2008", "unformatted_src": "https://cdn.ttgtmedia.com/digitalguide/images/Misc/FRSFigure-sm.JPG", "src": "https://cdn.ttgtmedia.com/digitalguide/images/Misc/FRSFigure-sm.JPG", "formatted_filename": "FRSFigure sm"}, null, {"document_url": "https://searchwindowsserver.techtarget.com/tip/Using-DFSR-for-SYSVOL-replication-in-Windows-Server-2008", "unformatted_src": "https://cdn.ttgtmedia.com/digitalguide/images/Misc/FRSTable.JPG", "src": "https://cdn.ttgtmedia.com/digitalguide/images/Misc/FRSTable.JPG", "formatted_filename": "FRSTable"}, null]

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).

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 introduced 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.

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.

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.

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:

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.

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

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

5. Eliminated state—DFSRMig/ setMigrationState 3

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 first.When the global directive is sent to that DC, the migration will occur and no additional intervention is needed.



Dig Deeper on Windows Server troubleshooting




