Step-by-Step FRS to DFSR Migration Guide for Windows 2008 and 2008 R2

This article is a step-by-step FRS to DFSR migration guide from FRS replication of domain controllers to the newer DFSR replication.


Domain controllers use a special shared folder named SYSVOL to replicate logon scripts and Group Policy object files to other domain controllers. Windows 2000 Server and Windows Server 2003 use File Replication Service (FRS) to replicate SYSVOL, whereas Windows Server 2008 uses the newer DFS Replication service when in domains that use the Windows Server 2008 domain functional level, and FRS for domains that run older domain functional levels. To use DFS Replication to replicate the SYSVOL folder, you can either create a new domain that uses the Windows Server 2008 domain functional level, or you can use the procedure that is discussed in this article to upgrade an existing domain and migrate replication to DFS Replication.

Applies To: Windows Server 2008, Windows Server 2008 R2

You may also be experiencing one or more of the following errors:

A. When running dcdiag /e /c on a domain controller, test: VerifyEnterpriseReferences fails with error:

Starting test: VerifyEnterpriseReferences The following problems were found while verifying various important DN references.  Note, that these problems can be reported because of latency in replication.  So follow up to resolve the following problems, only if the same problem is reported on all DCs for a given domain or if the problem persists after replication has had a reasonable time to replicate changes.    [1] Problem: Missing Expected Value     Base Object: CN=DC01,OU=Domain Controllers,DC=showmehowtodoit, DC=com     Base Object Description: “DC Account Object”     Value Object Attribute Name: msDFSR-ComputerReferenceBL     Value Object Description: “SYSVOL FRS Member Object”     Recommended Action: See Knowledge Base Article: Q312862

   [2] Problem: Missing Expected Value     Base Object: CN=DC02,OU=Domain Controllers,DC=showmehowtodoit, DC=com     Base Object Description: “DC Account Object”     Value Object Attribute Name: msDFSR-ComputerReferenceBL     Value Object Description: “SYSVOL FRS Member Object”     Recommended Action: See Knowledge Base Article: Q312862    LDAP Error 0x20 (32) – No Such Object. ……………………. LIBRARY failed test VerifyEnterpriseReferences B. You may get various Group Policy errors event viewer such as 1000,1001,1058,1030. For example:

Description: Windows cannot access the file gpt.ini for GPO CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=showmehowtodoit,DC=com The file must be present at the location \\\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9} (Access is denied) Group Policy processing aborted.

C. SYSVOL folder contents differ across domain controllers. All of the above problems are common errors that exist when domain controllers do not replicate correctly. The root cause according to Microsoft is that when you actually raise your domain and functional levels in an existing environment, active directory assumes that the replication is performed using DFSR between domain controllers even if the replication still happens using the FRS protocol. If you want to verify whether you are replicating using FRS or DFSR you may perform the following 3 checks.

Method 1

Open a PowerShell command and run the following cmdlet. If you are running FRS yet, you should get a warning that the migration has not been started yet. If you are running on DFSR you should get a return that the migration state is in the “Eliminated” step. > dfsrmig /getglobalstate Since we have not performed the migration steps, we will get the following error:1

Method 2

Log on to a domain controller and examine under c:\Windows whether a SYSVOL_DFSR folder exists. If it exists, it means you are already replicating using DFSR. In any other case, you should have a SYSVOL folder and replicate using FRS.

Method 3

You may notice “File Replication Service” service running under services snap-in. This service will be disabled once the migration is complete.

Migrating to the Prepared State

The first step of the migration state is to get into the “Prepared” state. However, before actually triggering the process, we should make sure that the active directory is in a healthy state.

  1. On each domain controller in your domain you wish to migrate, open up a command prompt and type net share to verify that SYSVOL folder is shared and maps to the correct folder. the output should be something similar to the following:
    Share name   Resource                        Remark
    NETLOGON     C:\Windows\SYSVOL\sysvol\\SCRIPTS
                                                 Logon server share
    SYSVOL       C:\Windows\SYSVOL\sysvol        Logon server share
  2. Use Registry Editor on each domain controller in the domain to navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters and verify that the value of the SysVol registry entry is [drive:\]Windows_folder\SYSVOL\sysvol, and that the value of the SysvolReady registry entry is 1.
  3. Verify that the DFS Replication service is listed with the values of Started in the Status column and Automatic in the Startup Type column.
  4. Open up a command prompt and type repadmin /ReplSum to get a status of replication between domain controllers.
  5. While having the command prompt window open, run dcdiag tool and examine the output for possible error.

Once you are confident that your active directory health is good, we may trigger the migration process. Log on to your primary domain controller (PDC).

  1. Open up a PowerShell or command prompt window and type dfsrmig /setglobalstate 1. You should get informed that the new global migration state is now set to “prepared”.
  2. Type dfsrmig /GetMigrationState. You will probably receive a warning that the global migration state has not reached a consistent state (yet). This is normal since domain controllers now have to perform various tasks related to the migration. Try re-running the command after some time.
  3. Check on you domain controllers under c:\windows if a new SYSVOL_DFSR folder has been created.
  4. Type dfsrmig /GetMigrationState to verify that the global state replication has reached a consistent level between domain controllers.
  5. Now we are ready to proceed to the next step, migrating to the “Redirected” state. Type dfsrmig /setglobalstate 2to go from the “Prepared” state to the “Redirected” state. Your output should be similar to:
  6. Examine the migration process by typing dfsrmig /GetMigrationState. Once the domain controllers have reached a consistent state, proceed to the next step.
  7. We are now ready to get to the final stage of the migration process. Once the migration process is set to the next ‘ELIMINATED’ state, it 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 and re-run the diagnostic commands shown earlier to verify active directory health. 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. This can be achieved by typing dfsrmig /getmigrationstate.
  8. Once you ensured that the replication health is good, type dfsrmig /setGlobalState 3. There will be a series tasks that now will be performed in the background such as: 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. You should have a similar result as below.
    You may notice that the SYSVOL folder is deleted. Instead, SYSVOL_DFSR is present.
    FRS service is disabled under services.


SYSVOL Migration Series. Technet blog

SYSVOL Migration Procedure. Technet article

3 thoughts on “Step-by-Step FRS to DFSR Migration Guide for Windows 2008 and 2008 R2”

  1. Hi Guy,

    I am in a situation where I need to migrate FRS sysvol to DFSR Sysvol.But My FRS Sysvol Contains _NTFRSxxxxxxxx (Morphed) folders.
    let me know if FRS Sysvol contains Morphed folders and If I initiate the FRS to DFSR migration, does DFSR will automatically take care of that ?
    OR do i need to remove them prior to Migration ?

    [email protected]

  2. Hello Mahesh,

    This happens usually when 2 changes happen on different replicas of DCs, leading to naming problems, therefore the _NTFRS is added as a prefix for distinguishing those objects. Do not delete the folders as it may lead you to group policy problems, or other GPO related task problems.

    A folder is created on multiple machines in the replica set before the folder has been able to replicate. The administrator or program may create duplicate folders on multiple FRS members. This may occur, for example, if the administrator is trying to make data consistent among all members with a manual copy.


    You initiate an authoritative restore (D4) on one server and:

    You did not stop the service on all other members of the reinitialized replica set before the NTFRS service restarts after the authoritative restore.
    You did not set the D2 registry key on all other members of the reinitialized replica set before such a server replicated outbound changes to reinitialized members of the replica set.

    1) Do a SYSVOL Backup
    2) Rename the original folders and the changed folders to different names, and then wait for the new names to propagate through the system.

    This makes sure the folder then has a common name throughout the SYSVOL, and that the names and GUIDs match on all members.

    Note Do not delete the undesirable folder and rename the other one. This can lead to even more naming conflicts.

    3) After the rename has propagated, choose the folder that you want to keep, and then rename it back to the original name. Other changed folders can then be safely deleted.

    If you still face problems, check this link:


Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.