>

File Replication Journal Wrap and Sysvol errors with Small Business Server migration

When doing a migration from Small Business Server (SBS) 2003 to SBS 2008, SBS 2011 or Windows server standard version, one of the first things you should do is run the SBS 2003 Best Practices Analyzer and of course check your event log for known problems.

One of the issues I see often is the sysvol, journal wrap Event ID 13568, Source NtFrs in the File Replication Eventlog.

———————————————————————————————————————————–
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.
[1] At the first poll, which will occur in 5 minutes, this computer will be deleted from the replica set. If you do not want to wait 5 minutes, then run “net stop ntfrs” followed by “net start ntfrs” to restart the File Replication Service.
[2] At the poll following the deletion this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set.

WARNING: During the recovery process data in the replica tree may be unavailable. You should reset the registry parameter described above to 0 to prevent automatic recovery from making the data unexpectedly unavailable if this error condition occurs again.

To change this registry parameter, run regedit.

Click on Start, Run and type regedit.

Expand HKEY_LOCAL_MACHINE.
Click down the key path:
   “System\CurrentControlSet\Services\NtFrs\Parameters”
Double click on the value name
   “Enable Journal Wrap Automatic Restore”
and update the value.

If the value name is not present you may add it with the New->DWORD Value function under the Edit Menu item. Type the value name exactly as shown above.———————————————————————————————————————————–

Fixing this issue is in most cases relative simple just add the “Enable Journal Wrap Automatic Restore” registry key noted in the event log and change the value to “1” and restart the “File Replication Service” service.

Before changing the registry key I would recommend to make a backup from the C:\Windows\Sysvol folder.

But after doing that there appeared a new warning message in the File Replication Eventlog, Event ID 13566, Source Ntfrs.

———————————————————————————————————————————–
File Replication Service is scanning the data in the system volume. computer <domain name> cannot become a domain controller until this process is complete. The system volume will then be shared as SYSVOL.

To check for the SYSVOL share, at the command prompt, type:
net share

When File Replication Service completes the scanning process, the SYSVOL share will appear.

The initialization of the system volume can take some time. The time is dependent on the amount of data in the system volume.———————————————————————————————————————————–

As stated you have to wait a while, but I could wait as long as I want but the sysvol share doesn’t appear.

Solution: At the end the solution seems to be that the ntfrs jet database was corrupted. To solve the problem:

Stop the “File Replication Service” service

Rename the “C:\windows\ntfrs\jet” folder

Start the “File Replication Service” service

One other thing that could happen is the folders under Windows\Sysvol are moved to a subfolder called “NtFrs_PreExisting_See_EventLog”. If you have more than one domain controller this is no problem and the folders will be replicated from another domain controller, but if you only have one domain controller which is mostly the case when using SBS. You can copy the right folders back from the backup you made before, or just move them out of the “NtFrs_PreExisting_See_EventLog” folder to one level up.

Solve these problems before you are starting your migration otherwise you will run into replication errors.

Posted in Blog, SBS 2008, SBS 2011 by ronnypot at April 7th, 2011.
Tags: , , , , , ,

29 Responses to “File Replication Journal Wrap and Sysvol errors with Small Business Server migration”

  1. Maddin says:

    godlike !!!!!
    renaming the jet folder was the perfect tip
    u are the man

    after setting the registry key i thougt my domain was broken

  2. Danny says:

    Renaming the jet folder was also the solution for our (broken) SBS 2008 🙂

  3. Dave says:

    Thanks Man…Whew!!!!!

  4. Jamie says:

    OMG!! What a total life saver!! Did both the Jet Database rename and the moving “just move them out of the “NtFrs_PreExisting_See_EventLog” folder to one level up.” Did the trick!

    Also, after doing this, open the Group Policy Mgmt Console and click on on each GPO, particularly the Default Domain Policy and the Default Domain Controller Policy as permissions may not be consistent, clicking ok on the popup will correct this.

  5. Julian says:

    This worked for 2 x 2008 DCs that were not replicating the sysvol folder, great work 🙂

  6. Paul says:

    Tried these steps one at a time, doing the jet folder rename last. SYSVOL share came online immediately!!!!

    Thank you sir!!!

    SBS 2008

  7. jeff f says:

    fantastic, thanks for posting this

  8. Richard says:

    Thank you so much. You saved my life!
    My case:
    In order to fix Event ID 13568, I switched “Enable Journal Wrap Automatic Restore” to value =1 then DC is not available (Sysvol is not shared, Event ID 13566, Event ID 1126).
    After aply your suggestion, I can access to AD DS again.

  9. Worshipa says:

    Thanks alot the renaming is really superb. ThuMb Up Man

  10. russ says:

    you da man, thanks….

    I had begun the migration tool and it found journal wrap. I had fixed the journal wrap but the tool still thought it was there. I stopped ntfrs then renamed jet then restarted ntfrs as you recommended.

    I took one more step and cleared all the event viewer logs.

    then ran the migration tool scan scan again and BAM! it worked.

    Thanks
    Russ

  11. Bob says:

    It sure beats a system state restore, great tip!!

  12. Tom says:

    Once i’d changed the registry key to “1” my AD disappeared, all i did was restart the NTFRS twice and it came back.

  13. harman says:

    Gud work.. its work for me..yuu

  14. Scott says:

    What do I do if I have a second Domain Controller on this SBS2008 network that has not been replicating for a while. I want the SYSVOL that is on SERVER01 as it is most current. Is there any way I can make sure that SERVER02 does not replicate it’s bad SYSVOL directory to SERVER01?
    Thanks!

  15. Terry says:

    Thank you for this post! You saved us a LOT of time getting our DC back up and operational. We received the following error on our 2008 domain controller. Event ID 13566, Source Ntfrs. With the assistance provided in this post we had the issue resolved in under 2 hours. Steps taken: Renamed the Jet Folder and copied the folders out of “NtFrs_PreExisting_See_EventLog” and moved them one level up. Worked like a charm. Thanks again!

  16. Dan says:

    If there was a tip jar, I would contribute! Thanks.

  17. rimpi singh says:

    I can’t thank you enough for this article! Like the previous commenter wrote, if there was a tip jar, I would contribute! All the best.

  18. SmallAdmin says:

    You just save me day(s) working on the stupid raid error and sysvol missing! Renaming the JET folder and restore of SYSVOIL files and my domain is up again. Many, many thanks!

  19. Hugo Mentzingen says:

    Thank you very much for your contribution.

    We successfully upgraded our domain from 2000 to 2003 but on the day after the users could not logon. We found that the problem was the Event ID 13566 and your solution worked perfectly.

  20. fred says:

    Thank you very very very much, a perfect solution on a sbs 2008 wich had no replicate. I can go in vacation finaly….

  21. Vincent says:

    Thanks, this really solved my problems.
    First I got the JRNL_WRAP_ERROR, then I changed the value off the Enable Journal Wrap Automatic Restore key to 1. Then event 13566 showed up in the event logs and I saw the NtFrs_PreExisting_See_EventLog folder in the sysvol directory.
    I copied the contents of this folder to my domain.local directory, the I stopped the ntfrs service, renamed the jet folder and started the ntfrs service, after this everything is working again.

  22. […] changing the registry key I would recommend to make a backup from the C:WindowsSysvol […]

  23. Zeke says:

    Thanks for the fix, this bailed me hardcore! I have done many SBS migrations and have have to fix the journal wrap error every time and have not had this happen. Great fix.

  24. You are the MAN. The JET Database was corrupted for me and that’s what I was struggling on for hours.

  25. Dunedin IT says:

    Thanks Ronny.

    I had actually broken a clients AD using other method (Non-Authoritative restore etc), but the Automatic recovered worked after we completed recovery from backups and allowed the Windows 2008 SBS Sysvol to be replicated to the new 2012 R2 Servers.

    Jamie

  26. Luke says:

    I was just jumping up and down in joy at this, Friday afternoon, adding a new DC to a domain to remove their old SBS, and found this nasty bugger hiding since a few months back when they had a raid failure!

    Once I saw that sysvol share on the new DC, it was drinks in. Cheers!!!!

  27. Joe says:

    What if I started the migration already? I am going from 2003 SBS to 2008 standard and have completed the migration. Ran into an issue when trying to demote the 2003 Server and eventually found that the 2008 server didn’t have NETLOGON or SYSVOL shares. Ran a D4 fix on the 2008 and the SYSVOL shows up there now, but nothing is in it. On the 2003 SBS server i see these Journal Wrap Error dating back to 2014. All the roles are on the 2008 server, AD changes replicate fine, but FRS never replicated between the 2. I’d like to get the 2003 server demoted and shutdown. Any suggestions? Do i go through your process on the 2003 box and hope that fixes the FRS replication to the 2008 server?

Leave a Reply

Sharing Buttons by Linksku