File Replication Service has detected that the replica set “DOMAIN SYSTEM VOLUME (SYSVOL SHARE)” is in JRNL_WRAP_ERROR
Are you getting this error in your File Replication Service?
The File Replication Service has detected that the replica set “DOMAIN SYSTEM VOLUME (SYSVOL SHARE)” is in JRNL_WRAP_ERROR.
Replica set name is : “DOMAIN SYSTEM VOLUME (SYSVOL SHARE)”
Replica root path is : “c:\windows\sysvol\domain”
Replica root volume is : \\.\C:
A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to read from the NTFS USN journal is not found. This can occur because of one of the following reasons.
[1] Volume “\\.\C:” has been formatted.
[2] The NTFS USN journal on volume “\\.\C:” has been deleted.
[3] The NTFS USN journal on volume “\\.\C:” has been truncated. Chkdsk can truncate the journal if it finds corrupt entries at the end of the journal.
[4] File Replication Service was not running on this computer for a long time.
[5] File Replication Service could not keep up with the rate of Disk IO activity on \\.\C:.
Setting the “Enable Journal Wrap Automatic Restore” registry parameter to 1 will cause the following recovery steps to be taken to automatically recover from this error state.
This is caused when the Sysvol gets currupted and is simple to fix. I will walk you through the steps.
First off before we do anything lets backup by taking a Shadow Copy of the C: Drive. To do this we will open MyComputer and select the C:Drive, right click it and select properties. Now find the ShadowCopy Tab, highlight the C: Drive and click the “Create Now” button to create a backup point on the drive. You do not need to “Enable” ShadowCopy to take a 1 time snapshot.
Now that we have a backup point to go to if all hell breaks loose we can safely move on to the next step. Open up REGEDIT and navigate to the RegKey -> System\CurrentControlSet\Services\NtFrs\Parameters and create a new REG_DWORD key called Enable Journal Wrap Automatic Restore and place a 1 as the hex value.
Now launch a Command window(DOS) and run the following commands:
NET STOP NTFRS
NET START NTFRS
This will then cause the following to appear in your File Replication Service Event Log:
The File Replication Service is deleting this computer from the replica set “DOMAIN SYSTEM VOLUME (SYSVOL SHARE)” as an attempt to recover from the error state,
Error status = FrsErrorSuccess
At the next poll, which will occur in 5 minutes, this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set.
This will be followed by the following Event Log:
File Replication Service is scanning the data in the system volume. Computer MyDomainServer cannot become a domain controller until this process is complete. The system volume will then be shared as SYSVOL.
This will be followed by the following Event Log:
The File Replication Service moved the preexisting files in c:\windows\sysvol\domain to c:\windows\sysvol\domain\NtFrs_PreExisting___See_EventLog.
Now we need to wait a bit and allow the replication to complete. This has taken anywhere from 5 minutes to 20 minutes for me based on server and what is being replicated. You will know it is complete when you get the Event Log:
The File Replication Service is no longer preventing the computer MyDomainController from becoming a domain controller. The system volume has been successfully initialized and the Netlogon service has been notified that the system volume is now ready to be shared as SYSVOL.
Once you get this log your replication is complete and the Journal Wrap issues are fixed. We now need to go back to REGEDIT and change the entry we placed in there from a 1 to a 0.
You are all done.
May this help someone out there..
Cubert
Cubert
Please add a big NOTE to your post , if people have only ONE DC in their environment , above procedure removes the entire SYSVOL and leads them to a total disaster.
thanks Cubert, that worked perfect for me today.
gary
It solved my problem, Thanks
What affect will there be trying to shadow copy a raid 1+0. For that matter on any RAID volume.
WORK !!!
Thanks Cubert!
This helped us..!
It worked but with one caveat. I hade to disjoin and rejoin the workstations from the domain.
Thanks Cubert, worked perfectly for me.
Thanks worked a charm.
Genius, thanks for the help!!!
Cubert, this article was exactly what was required with my DC. I imagine the SYSVOL wasn’t right on mine because this DC is unstable and has been unexpectedly rebooting. Anyway, I can now go chase that problem since you have helped me fix the SYSVOL issue. Many thanks again!!!
Thank you that fixed my issue for Windows Server 2008 SBS to Windows Server 2012R2 Migration.
Thanks for details steps , was able to save my 48 hrs of time.
My problem was solved. Thanks for useful article.
I’ve tried everything for an automatic restore mentioned above, to a D2 non-authoritive restore and even a D4 authoritive restore before I made it to this website. I thought for the first time I’d throw my issue out there like a net to see if I have any suggestions. My forest is currently in 2003 mode because I have 1 2003 DC and 2 2012 DC’s. I swapped all FSMO roles to the first and good 2012 DC way before I decided to purchase my second 2012 DC to eventually replace my old 2003 DC and in effect raise my forest functional level. The FSMO role transfers went fine by the way. The issue lies with my third DC which is the second 2012 DC. It constantly enters the journal wrap error state despite what recovery method I use. Sometime it enters 1 -3 1/2 hours after a restore is successfully performed. I’ve reached out to those more versed at the MS Stack then myself and even they are stumped. I also demoted the bad DC and changed its name as well. Any suggestions?
Dear Cubert,
Let me buy you a drink, any time you come to Benin (Africa).
I owe you all Guinness you wish for your Greatness sharing this article!
Thank you dear.
Question, does this retrieve information from another server to replace what is on the server with the issue? The reason I ask is this. I have a 2003 DC which I want to migrate over to a 2012 R2 server. I have noticed that the 2012 server will not allow logins if the 2003 server is down. So I was going to use Burflags to move the info over. However I have noticed that the 2003 server has the journal wrap error. It is the one with all the info so if it is delete all of my data is gone since the other server does not have that info. So I guess my question is this: Can I do this on the main server that has the current information? If not, what is my next step?
This messed up my primary DC. I waited for about 45 minutes and I still don’t have the netlogon share I have lost my whole sysvol and reverting to C: from the shadow copy cannot be done! it gives an error stating that it is on a clutered disk and contains OS files. What can I do????
You’re a legend. This has been beating me up for weeks. A failing DC is now back online.
For people who have a single domain and broke it (like me), they should use Burflags.
https://support.microsoft.com/en-nz/kb/290762
Fixed the deleted domain for me.
Dear Cubert, I usually don’t leave feedback on web but this time I have to. You have solved my problem which has been bothering me for months. I have googeled it through web and tryed many, many wonderful “fixes” but this one has finally done it. So simple, yet effective.
Thank You very much !
Dear Cubert, thanks for the solution. Very smooth and detailed post.
It worked for me.
Thank you very much
Many thanks for your help and effort.
you are the best.
Alright so this gave me a mini nightmare scenario that had me scrambling around for a few hours due to running it on a single DC domain.
However, if you did manage to accidentally nuke out your sysvol, you can still grab the files that are kept in the Shadow Copy you took. To do so, just browse to your server’s network shares on the server, then right click on the SYSVOL share. You’ll be able to restore a ‘Previous Version’. Luckily I was able to stop the ntfrs service and make a local backup of sysvol before it was wiped clean, but if I didn’t, I would have caused myself even more stress! Good luck.
My colleague has tried the suggested steps but it didn’t help
Hi Cubert, great article! This solved my problem! Big Thank You to you!
Works like a charm! Was preventing migration from 2k8 SBS to 2k12
First I had a doubt to implement your solution, it worked like a charm.
I have multiple sites with the same domain, one site wasn’t replicating the Sysvol folder but after your solution everything back to track
thanks man, it worked for me too. it saved my day
@AK
I did this on a single domain controller.
It did not remove sysvol for me.
I would reccomend backing up c:\winodows\sysvol, in preparation.
thanks very much fixed my issue
Hi Cubert, It seems that this article continues to help the poor IT even years later! It solved my replication problem as a bullet. I owe you a beer 🙂
[…] [Solved] NTFRS – Journal Wrap Errors detected on Domain Controller – Sep 9, 2011. Setting the “Enable Journal Wrap Automatic Restore” registry parameter to 1 will cause the following recovery steps to be taken to automatically recover from this error state. This is caused when the Sysvol gets currupted and is simple to fix. I will walk you through the steps. First off before we do anything lets. […]
Great success!!
Not so lucky as all the other comments, did this and it wiped all AD on both domain controllers.
Owe you a few beers for this worked perfectly cheers
This worked perfectly. Thanks!
Excellent article… 🙂 finally i’ve managed to sort out customer’s issue …thanks a lot man .
Thanks, especially for which intermediate event logs to expect!
Worked like a charm!
I don’t understand all the kudos for this post since the eventlog viewer actually species those exact steps for this issue. I assume the author posted most of these and only those who lost data because of the single DC issue are real.
-ed
Dear Cubert, thanks for the solution and the detailed post
It worked for me.
Thank you very much
sam
Thank you, it worked for me.
performed is on the 2 DC and problem was solved.
saved me a lot of time.
Perfect!
Excellent document, helped us solve the situation.
Thank you.
Nailed it – thanks so much. Your information was much clearer than the Microsoft documentation on this matter.
Excellent document,
I was nervous has heck doing this based on some of the comments but it fixed my issues and can now do group policy pushes again (mixed 2003/2008 environment). Needless to say, after 5 minutes, everything worked perfectly.
Once caveat is any GPO’s you’ve created when the DC is in this state will not be accessible and give an error when you try to edit them. You’ll need to delete these GPO’s and recreate them so make notes of what they do before you start this process.
I had been manually fixing things with icacls as the permission where whacked on the one DC. A few GPOs would not replicate even though the permissions where identical.
This worked perfectly and fixed all of the permissions issues!
Many thanks!!!
Glad to see that this fix is still a primary repair after all these years… I am surprised Microsoft has not created a quick fix for this issue yet.
@ed, That’s was a funny post! I do not think I would have the time and patents to to post a bunch of success posts just to deceive technical engineers.
hi
very helpful you solution
thanks you very much