On This Page

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.

Overview

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 \\showmehowtodoit.com\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\showmehowtodoit.com\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”.

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

  1. Check on you domain controllers under c:\windows if a new SYSVOL_DFSR folder has been created.

  1. Type dfsrmig /GetMigrationState to verify that the global state replication has reached a consistent level between domain controllers.

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

  1. Examine the migration process by typing dfsrmig /GetMigrationState. Once the domain controllers have reached a consistent state, proceed to the next step.

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

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

References

SYSVOL Migration Series. Technet blog http://blogs.technet.com/b/filecab/archive/2008/02/08/sysvol-migration-series-part-1-introduction-to-the-sysvol-migration-process.aspx

SYSVOL Migration Procedure. Technet article http://technet.microsoft.com/en-us/library/dd639860%28v=ws.10%29