Posted on

FRS to DFS-R Migration

Understand FRS to DFS-R Migration Stages
From MOC 6425C p12.70 – 12.73

Because SYSVOL is critical to the health and functionality of your domain, Windows does not provide a mechanism with which to convert from FRS to DFS-R replication of SYSVOL instantly. In fact, migration to DFS-R involves creating a parallel SYSVOL structure. When the parallel structure is successfully in place, clients are redirected to the new structure as the domain’s system volume. When the operation has proven successful, you can eliminate FRS.

Migration to DFS-R therefore consists of four stages or states:

0 (start). The default state of a domain controller. Only FRS is used to replicate SYSVOL.

1 (prepared). A copy of SYSVOL is created in a folder called SYSVOL_DFSR and is added to a replication set. DFS-R begins to replicate the contents of the SYSVOL_DFSR folders on all domain controllers. However, FRS continues to replicate the original SYSVOL folders and clients continue to use SYSVOL.

2 (redirected) SYSVOL share is redirected to SYSVOL_DFSR for client use.
SYSVOL is still replicated by FRS for failback.

3 (eliminated). Replication of the old SYSVOL folder by FRS is stopped. The original SYSVOL folder is not deleted. Therefore, if you want to remove it entirely, you must do so manually.

You move the DCs through these stages or states, by using the DFSMig command. You will use three options with dfsrmig.exe:

  • getglobalstate state
    The setglobalstate option configures the current global DFSR migration state, which applies to all domain controllers. The state is specified by the state parameter, which is 0–3. Each domain controller will be notified of the new DFSR migration state and will migrate to that state automatically.
  • getglobalstate
    The getglobalstate option reports the current global DFSR migration state.
  • getmigrationstate
    The getmigrationstate option reports the current migration state of each domain controller. Because it might take time for domain controllers to be notified of the new global DFSR migration state, and because it might take even more time for a domain controller to make the changes required by that state, domain controllers will not be synchronized with the global state instantly. The getmigrationstate option enables you to monitor the progress of domain controllers toward the current global DFSR migration state.

If there is a problem moving from one state to the next higher state, you can revert to previous states by using the setglobalstate option. However, after you have used the setglobalstate option to specify state 3 (eliminated), you cannot revert to the earlier states.

To migrate SYSVOL replication from FRS to DFS-R, perform the following steps:

1. Open the Active Directory Domains and Trusts snap-in.
2. Right-click the domain and choose Raise Domain Functional Level.
3. If the Current domain functional level box does not indicate Windows Server 2008, select Windows
Server 2008 or Windows Server 2008 R2 from the Select an available domain functional level list.
4. Click Raise. Click OK twice in response to the dialog boxes that appear.
5. Log on to a domain controller and open a command prompt.
6. Type dfsrmig /setglobalstate 1.
7. Type dfsrmig /getmigrationstate to query the progress of domain controllers toward the Prepared
global state. Repeat this step until the state has been attained by all domain controllers.
This can take 15 minutes to an hour or longer.
8. Type dfsrmig /setglobalstate 2.
9. Type dfsrmig /getmigrationstate to query the progress of domain controllers toward the
Redirected global state. Repeat this step until the state has been attained by all domain controllers.
This can take 15 minutes to an hour or longer.
10. Type dfsrmig /setglobalstate 3.
After you begin migration from state 2 (prepared) to state 3 (replicated), any changes made to the
SYSVOL folder will have to be replicated manually to the SYSVOL_DFSR folder.
11. Type dfsrmig /getmigrationstate to query the progress of domain controllers toward the
Eliminated global state. Repeat this step until the state has been attained by all domain controllers.
This can take 15 minutes to an hour or longer.
12. For more information about the dfsrmig.exe command, type dfsrmig.exe /?.

 

More info on migration steps:

SYSVOL Replication Migration Guide: FRS to DFS Replication
http://technet.microsoft.com/en-us/library/dd640019(WS.10).aspx

Migrate a Domain-based Namespace to Windows Server 2008 Mode – Applies To: Windows Server 2008 R2
“To migrate a domain-based namespace from Windows 2000 Server mode to Windows Server 2008 mode, you must export the namespace to a file, delete the namespace, recreate it in Windows Server 2008 mode, and then import the namespace settings. To do so, use the following procedure.”
http://technet.microsoft.com/en-us/library/cc753875.aspx

Why Migrate?

1. “Access-based enumeration– Access-based enumeration allows users to see only files and folders on a file server to which they have permission to access. This feature is not enabled by default for namespaces (though it is enabled by default on newly-created shared folders in Windows Server 2008), and is only supported in a DFS namespace when the namespace is a standalone namespace hosted on a computer running Windows Server 2008, or a domain-based namespace by using the Windows Server 2008 mode.”

Above quoted from:
Distributed File System – Why migrate?
http://technet.microsoft.com/en-us/library/cc753479(WS.10).aspx

Enable Access-Based Enumeration on a Namespace
http://technet.microsoft.com/en-us/library/dd919212(WS.10).aspx
 
2. Cluster support – DFS Namespaces in Windows Server 2008 supports creating stand-alone namespaces on a failover cluster from within the DFS Management snap-in. To do so, specify a failover cluster on the Namespace Server page of the New Namespace Wizard.

3. Improved command-line tools – DFS Namespaces in Windows Server 2008 includes an updated version of the Dfsutil command and the new Dfsdiag command, which you can use to diagnose namespace issues.

Changes and improvements to Dfsutil:
http://go.microsoft.com/fwlink/?LinkId=136572

Dfsdiag:
http://go.microsoft.com/fwlink/?LinkId=136571

4. Windows Server 2008 mode domain-based namespaces – Windows Server 2008 includes the ability to create a domain-based namespace in Windows Server 2008 mode. Doing so enables support for access-based enumeration and increased scalability. The domain-based namespace introduced in Windows® 2000 Server is now referred to as “domain-based namespace (Windows 2000 Server mode).”

To use the Windows Server 2008 mode, the domain and domain-based namespace must meet the following minimum requirements:
     – The forest uses the Windows Server 2003 or higher forest functional level.
     – The domain uses the Windows Server 2008 or higher domain functional level.
     – All namespace servers are running Windows Server 2008.

If your environment supports it, choose the Windows Server 2008 mode when you create new domain-based namespaces. This mode provides additional features and scalability, and also eliminates the possible need to migrate a namespace from the Windows 2000 Server mode.

For information about migrating a namespace to Windows Server 2008 mode, see
Migrate a Domain-based Namespace to Windows Server 2008 Mode.
http://technet.microsoft.com/en-us/library/cc753875(WS.10).aspx

5. Content Freshness – DFS Replication in Windows Server 2008 has a new feature called Content Freshness, which prevents a server that was offline for a long time from over-writing fresh data when it comes back online with stale (out-of-date) data.

6. Improvements for handling unexpected shutdowns – In Windows Server 2008, DFS Replication now allows for quicker recovery from unexpected shutdowns. Unexpected shutdowns can occur because of the following reasons:
     – Unexpected shutdown of DFS Replication: This could occur if the DFS Replication process crashes, is ended, or stops because there are insufficient resources.
     – Unexpected shutdown of the computer: This could occur if the computer crashes or loses power while DFS Replication is running.
     – Unexpected shutdown of the volume: This could occur if the volume hosting a DFS Replication content set loses power, is disconnected, or is forced to dismount.
Unexpected shutdowns of the computer and the volume can cause the NTFS file system to lose changes which have not been copied to disk. Therefore the DFS Replication database can become inconsistent with the on-disk file system state.

On Windows Server 2003 R2, an unexpected shutdown may force DFS Replication to perform a complete database rebuild, which can be very time consuming. DFS Replication in Windows Server 2008 usually does not need to rebuild the database following unexpected shutdowns, and thus recovers much more quickly.

7. DFS Replication performance improvements – DFS Replication in Windows Server 2008 includes the following performance improvements:
     – Faster replication both for small and large files.
     – Initial synchronization completes faster.
     – Better network bandwidth utilization on LANs and high latency networks such as WANs.

8. Propagation report – DFS Management in Windows Server 2008 includes a new type of diagnostic report called a propagation report. This report displays the replication progress for the test file created during a propagation test.

9. Replicate now – DFS Management now includes the ability to force replication to occur immediately, temporarily ignoring the replication schedule.
     To force replication immediately
       1. In the console tree, under the Replication node, select the appropriate replication group.
       2. Click the Connections tab.
       3. Right-click the member you want to use to replicate, and then click Replicate Now.

10. Support for Read-Only Domain Controllers – In Windows Server 2008, DFS Replication supports Read-Only Domain Controllers (RODCs).
For more information about RODCs, see http://go.microsoft.com/fwlink/?LinkId=96517.

11. SYSVOL replication using DFS Replication – DFS Replication replaces the File Replication Service (FRS) as the replication engine for replicating the AD DS SYSVOL folder in domains that use the Windows Server 2008 domain functional level.

=================================================================

Summary

I hope this helped you to easily configure your time service and what to do if it didn’t work.

Ace Fekay
MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2008/R2, Exchange 2013, 2010 EA & 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP – Directory Services

clip_image002[6][2] clip_image004[6][2] clip_image006[6][2] clip_image008[6][2] clip_image010[6][2] clip_image012[6][2] clip_image014[6][2]

Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

Posted on

How to Recover a Journal Wrap Error (JRNL_WRAP_ERROR) and a Corrupted FRS SYSVOL from a Good DC – What option do I use, D4 or D2? What’s the Difference between D4 and D2?

Original: 11/21/2013
Updated 8/30/2014

Errata

Ace here again. I’ working on updating all of my blogs. If you see any inconsistencies, please let email me and let me know.

Prologue

Are you seeing Event ID 13508, 13568, and anything else related to SYSVOL, JRNL_WRAPS, or NTFRS?

Note – I will not address Event ID 2042 or 1864. That’s an issue with replication not working beyond the AD tombstone. If you are seeing them, you’re best bet is to forcedemote the machine, run a metadata cleanup, and re-promote it, and make sure you configure your firewall and/or AV to allow replication traffic or stop using the ISP’s or router as a DNS address, or disable IP routing and WINS Proxy, to prevent this in the future. And while you’re at it bump up your AD tombstone to 180 days,

As for the NTFRS, after talking to numerous folks whether directly assisting a customer, or through the TechNet forums, there seems to be some confusion associated with how to handle Journal Wrap errors, what caused them, and what are the differences between the D2 and D4 options. I’ll try to quell this confusion in this blog, as well as provide an easy step-step and providing an explanation for the steps, to get out of this error. Note: The steps are from Microsoft KB290762. I just thought to further break it down so a layman will understand them.

Reference KB: Using the BurFlags registry key to reinitialize File Replication Service Replica Sets
http://support.microsoft.com/kb/290762

For Windows 2008/2008 R2/2012/2012 R2 with DFSR

Follow this KB to fix it:

How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like “D4/D2” for FRS)
http://support.microsoft.com/kb/2218556

Backing Up and Restoring an FRS-Replicated SYSVOL Folder
http://msdn.microsoft.com/en-us/library/windows/desktop/cc507518(v=vs.85).aspx 

What Caused the Journal Wrap?

First you have to ask yourself, what caused this error on my DC? What did I do to get here? In a nutshell, JRNL_WRAPS are caused by SYSVOL corruption.

The usual culprit can be a number of things:

  • Abrupt shutdown/restart. I don’t usually see this unless there are power issues in the building with not power protection or UPS battery system.
  • Disk errors – corrupted sectors. This is a common issue with a DC on older hardware.
  • AV not configured to exclude SYSVOL, NTDS and the AD processes. This is the typical culprit I’ve seen in many cases.

Ok, So what do I have to do to fix this?

To get yourself out of this quandary, it’s rather simple. Yea, you might say yea, right, this is not so simple, but it really isn’t that hard. It just requires a little understanding of what you have to do, which is all it’s doing is simply copying a good SYSVOL folder and subfolders from a good DC to the bad DC (the one with the errors.

Basically, you first choose which DC is the good DC to be your “source” DC for the SYSVOL folder. Then you you stop the NTFRS service on all DCs. Yes, NTFRS must to be stopped on all DCs to perform this. Then set the registry key on the good DC and the bad DC. That’s it. The process will take care of itself and reset the keys back to default after it’s done.

  • If you only have one DC, such as an SBS server, and SYSVOL  appears ok, or restore just the SYSVOL from a backup. Then just follow the “Specific” steps I’ve outlined below.
  • If more than one DC, but not that many where you can’t shutdown the NTFRS on all of them, such as if you have 40 DCs, pick and choose the best one and set Burflags to D2 on the bad and D4 on the good.
  • If there are numerous DCs, such as a large infrastructure, simply run dcpromo /forcedemote the DC with the error, run a metadata cleanup, then re-promote to a DC back into the domain. If you unplug the DC and run a metadata cleanup, then you will have to rebuild the DC from scratch. The forcedemote switch removes the AD binaries off the machine allowing you to re-promote it.

 

To summarize:

You have two choices as to a restore from a good DC using FRS:

  1. D2 is set on the bad DC: Non-Authoritative restore: Use the D2 option on the DC with the empty SYSVOL folder, or the SYSVOL folder with the incorrect data. This way it will get a copy of the current SYSVOL and other folders from the good DC that you set the BurFlags D4 option on.
  2. D4 is set on the good DC: Authoritative restore: Use the BurFlags D4 option on the DC that has a copy of the current policies and scripts folder (a good, not corrupted folder).

 

The BurFlags option – D4 or D2? What do I use?

The steps refer to changing a registry setting called the BurFlags value. If the BurFlags key does not exist, simply create it. It’s a DWORD key.

More importantly, it references change the BurFlags to one of two options: D4 or D2. Therefore, before going further, I would like to squelch the confusion on what the D2 and D4 settings mean:

D2/D4 – Which is which?

  • D2, also known as a Nonauthoritative mode restore – this gets set on the DC with the bad or corrupted SYSVOL
  • D4, also known as an Authoritative mode restore – use this on the DC with the good copy of SYSVOL.
  • You must shut the NTFRS service down on ALL DCs while you’re doing this until instructed to start it.
  • You’ll probably want to copy the current SYSVOL structure on the good DC to another folder as a backup prior to doing this.

The D2 option on the bad DC will do two things:

  1. Copies the current stuff in the SYSVOL folder and puts it in a folder called “Pre-existing.” That folder is exactly what it says it is, it is your current data. This way if you have to revert back to it, you can use the data in this folder.
  2. Then it replicates (copies) good data from the GOOD DC (D4) to the bad guy (D2).

Once again, simply put:

  • The BurFlags D4 setting is “the Source DC” that you want to copy its good SYSVOL folder from, to the bad DC.
  • The bad DC BurFlags is set to D2, which tells it to pull from the source DC, the one you set D4 on.

 

Here are the steps summarized:

  1. For an Authoritative Restore you must stop the NTFRS services on all of your DCs
  2. In the registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process
    1. Set the BurFlags setting to HEX “D4” on a known DC that has a good SYSVOL (or at this time restore SYSVOL data from backup then set the Burflag to D4)
    2. Then start NTFRS on this  server.
    3. You may want to rename the old folders with .old extensions prior to restoring good data.
  3. Clean up the folders on all the remaining servers (Policies, Scripts, etc) – renamed them with .old extensions.
  4. Set the BurFlags to D2 on all remaining servers and then start NTFRS.
  5. Wait for FRS to replicate.
  6. Clean up the .old stuff if things look good.
  7. If the “D4” won’t solve the problem try the “D2” value.

 

So circling back, to fix this and make it work, just copy the contents of SYSVOL to another location, then follow the KB, which simply states you must stop the NTFR service on ALL DCs. Then pick a good one to be the “Source DC.”

Of course, as I’ve stated above, if you have a large number of DCs, the best bet is to forcedemote the bad DC, run a metadata cleanup to remove its reference from AD, then re-promote it.

If you have a small number of DCs, and if you have a good DC and a bad DC, on the good DC, you would set the BurFlags to D4, and on the BAD DC you would set the Burflags to D2.

Example run:

In the example below, if you set BurFlags to D4 on a single domain controller and set BurFlags to D2 on all other domain controllers in that domain, you can rebuild the SYSVOL from the D4 DC (the source DC).

I’ve also heard of admins manually copying the SYSVOL folder, then set the BurFlags options as mentioned, which works too. But no, I haven’t tested it. That would be for a lab on another day. 🙂

Authoritative Restore Example

Use the BurFlags D4 option on the DC that has a copy of the current policies and scripts folder (a good, not corrupted folder).

  1. Stop the FRS service on all DCs. To do this to all DCs from one DC, you can download PSEXEC and run “psexec \\otherDC net stop ntfrs” one at a time for each DC.
  2. On a good DC that you want to be the source, run regedit and go to the following key:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
    In the right pane, double-click “BurFlags.” (or Rt-click, Edit DWORD)
       Type D4 and then click OK.
  3. On the bad DC, run regedit and go to the following key:   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
       In the right pane, double-click “BurFlags.” (or Rt-click, Edit DWORD)
       Type D2 and then click OK.
  4. Quit Registry Editor, and then switch to the Command Prompt (which you still have opened).
  5. On the good DC, start the FRS service, or in a command prompt, type in “net start ntfrs” and hit <enter>
  6. On the bad DC, start the FRS service, or in a command prompt, type in “net start ntfrs” and hit <enter>
  7. On the bad DC, check the Sysvol folder to see if it started populating.
  8. Check for EventID 13565 which shows the process started
  9. Check for EventID 13516, which shows it’s complete
  10. Start FRS on the other DCs.

The following occurs after running the steps above after you start the FRS service (NTFRS):

  • The value for BurFlags registry key returns to 0.
  • Files in the reinitialized FRS folders are moved to a <var>Pre-existing</var> folder.
  • An event 13565 is logged to signal that a nonauthoritative restore is started.
  • The FRS database is rebuilt.
  • The member replicates (copies) the SYSVOL folder from the GOOD DC.
  • The reinitialized computer runs a full replication of the affected replica sets when the relevant replication schedule begins.
  • When the process is complete, an event 13516 is logged to signal that FRS is operational. If the event is not logged, there is a problem with the FRS configuration.
     
    Note: The placement of files in the <var>Pre-existing</var> folder on reinitialized members is a safeguard in FRS designed to prevent accidental data loss. You can copy this stuff back if it didn’t work, but I have not yet seen when this has not worked!

Summary

I hope this helps cleaning up your FRS and SYSVOL replication issues.

Ace Fekay
MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2008/R2, Exchange 2013, 2010 EA & 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP – Directory Services
Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

This blog is provided AS-IS with no warranties or guarantees and confers no rights.