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.

AD Upgrade Checklist and Procedure

AD migration checklist and procedure:
Technet Thread: "Migrating from AD 2003 to AD 2008 R2:"
http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/906266b9-62c9-462f-b16e-3b801c7e2fc3/

Here’s a quick summary from:
Transitioning your Active Directory to Windows Server 2008 R2
http://blogs.dirteam.com/blogs/sanderberkouwer/archive/2010/05/26/transitioning-your-active-directory-to-windows-server-2008-r2.aspx
 

ADPREP

Run adprep with the following switches.  
If you are running it on a 32 bit machine, use the adprep32.exe version.
 
adprep /forestprep
adprep /domainprep /gpprep      Run after the foresprep and in each domain on the IM Role (enable Resultant Set of Policy (RSOP) Planning Mode functionality)
adprep /domainprep              Run after the forestprep and in each domain
adprep /rodcprep                Run on the DNM Role. Optional only if you expect to install an RODC.
 
You can also use the /wssg switch so you can get a detailed result code instead of a 0 for success, or 1 for an error.
 
Alllow replication time. Go get a cup of coffee, cold refreshment, or a beer.

 

Then check your schema version:

repadmin /showattr * "cn=schema,cn=configuration,dc=domain,dc=tld" /atts:objectVersion

Run it on all DCs. You can use PSEXEC – Microsoft Technet to remotely run it in a command prompt, or create a script.
 
When all your Domain Controllers report Schema version 47, you’re good to go. If not, check the event logs and the C:\Windows\Debug\Adprep\Logs\adprep.log.

More info if needed:
Troubleshooting ADPREP Errors
http://blogs.technet.com/b/askds/archive/2008/12/15/troubleshooting-adprep-errors.aspx

 

Then raise the Domain Functional Level.

This adds two features:
1. Authentication Mechanism Assurance – Type of authentication is added to the user’s Kerb ticket.
2. Automatic SPN Management – Allows the use of Managed Service Accounts (MSAs) instead of Domain User accounts to run a service under.
Allow a bit of time to replicate. Go get a cup of coffee, a beer, whatever.
 

Then raise the Forest Functional Level.

This basically adds one thing:
1. The ability to enable the new Active Directory Recycle Bin feature.
 
If you want to enable it, go to Start, Programs AD Powershell, then run:
Enable-ADOptionalFeature –Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=domain,DC=tld’ -Scope ForestOrConfigurationSet -Target ‘domain.local’
 
Allow replication time, too. Go get another beer.
 

Run the AD BPA

1. Server Manager, expand the Roles node
2. Select the Active Directory Domain Services role.
3. Scroll down to the Best Practice Analyzer section.
4. Click on the Scan This Role link on the right hand side.

Windows Server 2008 R2 Upgrade Paths
http://technet.microsoft.com/en-us/library/dd979563(WS.10).aspx

How to upgrade Windows Server 2003 R2 to Windows Server 2008 on a computer that includes a Baseboard Management Controller and a root-enumerated IPMI device
http://support.microsoft.com/kb/953224

 

Ace Fekay

Corrections, suggestions, & comments are welcomed

Install a Replica DC with DNS AD Integrated Zones

 

This blog provides an overview to add an additional replica DC in the same domain. This assumes the operating system versions are the same and you are not upgrading to a newer operating system version or upgrading Active Directory.

If you are upgrading your AD domain, please see this:
Install a replica DC with DNS AD Integrated Zones

If you have multiple sites, read this article:
Best Practices for Adding Domain Controllers in Remote Sites:
http://technet2.microsoft.com/windowsserver/en/library/6405bc5f-b8bf-449e-b11a-f116d22f858a1033.mspx?mfr=true

Here’s a good article on promoting a machine to a DC and other factors:
How do I install Active Directory on my Windows Server 2003 server?:
http://www.petri.co.il/how_to_install_active_directory_on_windows_2003.htm

IF you have not done so, then install DNS. For assistance, read this article:
How To Install and Configure DNS Server in Windows Server 2003:
http://support.microsoft.com/kb/814591

Assuming the current zone is AD integrated, DO NOTHING ELSE.
Do NOT create it manually or you will cause numerous problems and headaches.
Sit there and wait. Go to lunch. Upon return, you will find the zone has
automatically populated. Because AD integrated zones are in the actual AD
database, it will automatically replicate to the new machine by the default
AD replication process. There is really nothing else to configure on this
part, that is assuming the zone is already AD integrated. Is it AD
integrated? If so, what scope is it set to on both machines?

More information on DNS AD Integrated Replication Scopes:
http://technet2.microsoft.com/windowsserver/en/library/6c0515cf-1719-4bf4-a3c0-7e3514cef6581033.mspx?mfr=true

More detailed information on how to change AD Integrated DNS zone replication Scopes:
http://technet2.microsoft.com/windowsserver/en/library/e9defcdc-f4e5-43cd-9147-104f9b9d015a1033.mspx?mfr=true

If there is a problem where you cannot change the scope, read this:
You cannot change the replication scope of an Active Directory integrated DNS zone in Windows Server 2003
http://support.microsoft.com/kb/842560

Change the ip properties of this DC to use one of the other DCs as the first
entry, the second as itself. That;s it for this part. I fnot sure how,
follow this article:
825036 – Best practices for DNS client settings in Windows 2000 Server and
in Windows Server 2003
http://support.microsoft.com/?id=825036

Go into DNS properties, configure a Forwarder to your ISP’s DNS. If not sure
how, this article will show you:
Configure a DNS Server to Use Forwarders – Windows 2008 and 2008 R2 (Includes info on how to create a forwarder)
http://technet.microsoft.com/en-us/library/cc754941.aspx

HOW TO Configure DNS for Internet Access in Windows Server 2003 (forwarding) :
http://support.microsoft.com/?id=323380

Configure a DNS Server to Use Forwarders – Windows 2008 and 2008 R2 (Includes info on how to create a forwarder)
http://technet.microsoft.com/en-us/library/cc754941.aspx

 

WINS

If you have a multi-segmented infrastructure (remote locations), install WINS.
This is done in Add/Remove, Windows Components, Network Services, click on WINS.
For assistance, read these article:

WINS – What Is It, How To Install It, WINS Replication Partner Design Guidelines, How to Configure DHCP Scopes For WINS Client Distribution, and more:
http://msmvps.com/blogs/acefekay/archive/2010/10/27/wins-what-is-it-how-to-install-it-and-how-to-configure-dhcp-scopes-for-wins-client-distribution.aspx

How To Install a WINS server:
http://technet2.microsoft.com/windowsserver/en/library/e4d3c3d8-a846-49b9-aac6-e04f2907aac51033.mspx

If using Windows 2003, when you install WINS, make sure you are using an SP2 integrated i386 source. With Windows 2008 and newer, it’s not necessary. The following will assist with Windows 2003:
How to slipstream SP2 into the i386 folder (good for XP, 2000 and 2003):
http://www.theeldergeek.com/slipstreamed_xpsp2_cd.htm

On the WINS server itself, go to IP properties, Advanced, WINS tab, ONLY point the WINS
address of itself to itself ONLY. Do not add any other WINS addresses. For assistance, see this article:
WINS Best Practices (Use ONLY itself in ip properties):
http://technet2.microsoft.com/windowsserver/en/library/ed9beba0-f998-47d2-8137-a2fc52886ed71033.mspx

This assumes you will be configuring RRAS properties to get client IPs from Windows DHCP and not a manual range or from your firewall/perimeter router (such as your Comcast, Linksys, etc., router).

Once that is done, in DHCP, change the WINS address to the new server in DHCP Option 046. Make sure you have DHCP Option 044 set to 0x8.

•DHCP Option 044: IpAddressOfYourWINSserver
•DHCP Option 046: 0x8

If not sure how to do the above, please read this article:
DHCP Options Not Set by SBS Setup (this is good for SBS and WIndows Server 2003, 2008, 2000, etc):
http://support.microsoft.com/kb/218636

FSMO roles

If you say the other DCs are that unreliable, transfer all the FSMO roles to
this new server.If not sure how, follow this article:
How to view and transfer FSMO roles in Windows Server 2003
http://support.microsoft.com/kb/324801

If you are not sure which server to set a FSMO role, read this:
FSMO placement and optimization on Active Directory domain controllers:
http://support.microsoft.com/kb/223346

Make this DC a GC. If you need assistance: follow this article:
http://technet2.microsoft.com/windowsserver/en/library/93ffc6d8-e4c9-4a5b-8b4c-7d426bcba5a11033.mspx?mfr=true

Matter of fact, make all DCs a GC. More on this:

Global Catalog and FSMO Infrastructure Master Relationship
Published by Ace Fekay, MCT, MVP DS on Oct 1, 2010 at 1:05 PM
http://msmvps.com/blogs/acefekay/archive/2010/10/01/global-catalog-and-fsmo-infrastructure-master-relationship.aspx

Phantoms, tombstones and the infrastructure master.
The GC role will conflict with a global catalog in a multi-domain forest. To overcome this conflict, all DCs are recommended to be GCs.
http://support.microsoft.com/kb/248047

Global Catalog vs. Infrastructure Master
"If a single domain forest, you can have all DCs a GC. If multiple domains, it is recommended for a GC to not be on the FSMO IM Role, unless you make all DCs GCs"
This is the recommendations by AD Microsoft engineers, AD MVPs, and other engineers.
http://msmvps.com/blogs/ulfbsimonweidner/archive/2005/03/08/37975.aspx 

 

Ace Fekay

Suggestions, comments, corrections, etc, are all welcomed.