Active Directory Journal Wrap Error

Hello Experts,

I’m hoping someone can help me with this as I’m losing sleep.

I currently have seven windows 2003 domain controllers, some of which are located at remote branches. I noticed a few days ago that group policies weren’t being applied at three of my remote locations. After doing some research, I discovered the following event I.D’s 13568 , 1058 , and 1030. The servers also provided a solution below that I would like to attempt, however I’m not sure what the risk are. Has anyone performed the below procedure before and what are the risk associated with this procedure? I’m about to start a migration in a few months but in the meantime I would to have my group policies working at these remote branches. I’m not even sure if I could safely migrate with these errors.

Error and solution

Event Type:      Error
Event Source:      NtFrs
Event Category:      None
Event ID:      13568
Date:            5/28/2015
Time:            7:56:26 AM
User:            N/A
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.
Click down the key path:
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.

For more information, see Help and Support Center at

(Additional Errors)

Event Type:      Error
Event Source:      Userenv
Event Category:      None
Event ID:      1030
Date:            5/29/2015
Time:            8:52:06 AM
User:            NT AUTHORITY\SYSTEM
Windows cannot query for the list of Group Policy objects. Check the event log for possible messages previously logged by the policy engine that describes the reason for this.

For more information, see Help and Support Center at

Event Type:      Error
Event Source:      Userenv
Event Category:      None
Event ID:      1058
Date:            5/29/2015
Time:            8:52:06 AM
User:            NT AUTHORITY\SYSTEM
Windows cannot access the file gpt.ini for GPO cn={DD2E3F6C-214D-42FB-89A7-A0354DB602F9},cn=policies,cn=system,DC=cnb,DC=domain,DC=com. The file must be present at the location <\\\SysVol\\Policies\{DD2E3F6C-214D-42FB-89A7-A0354DB602F9}\gpt.ini>. (The system cannot find the path specified. ). Group Policy processing aborted.

For more information, see Help and Support Center at
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Randy DownsOWNERCommented:
Read this.

By default, versions of the Ntfrs.exe file from Windows 2000 Service Pack 3 (SP3) and from Windows 2000 SP3 hotfix do not perform an automatic nonauthoritative restore (for example, SP3 leaves content in place as 2195 and SP1 left the context in place) when journal wrap errors are detected. SP3 versions of NTFRS may be configured to function like SP2 when the "Enable journal wrap automatic restore" registry entry is set to 1 in the following registry subkey:
Important We do not recommend that you use this registry setting, and this setting should not be used versions of Windows after the Service Pack 3 version of Windows 2000. The recommended method for performing a nonauthoritative restore on FRS members of DFS or SYSVOL replica sets is to use the FRS BurFlags registry value. For more information about how to use the BurFlags registry value, click the following article number to see the article in the Microsoft Knowledge Base:
290762 Using the BurFlags registry key to reinitialize File Replication service replica sets
The following are appropriate options to reduce journal wrap errors:

    Put the FRS-replicated content on less busy volumes.
    Keep the FRS service running.
    Avoid making changes to FRS-replicated content while the service is turned off.
    Increase the USN journal size.
DrDave242Senior Support EngineerCommented:
There's an alternative procedure for correcting journal-wrap errors. There is a chance of data loss (specifically involving Group Policy objects and logon/logoff scripts, the stuff that's typically stored in SYSVOL), but I've done this successfully numerous times:


Locate the domain controller with the most up-to-date copy of the SYSVOL folder. This is potentially the trickiest and most time-consuming step. How you do this is up to you; you can compare the modified dates on the folders within SYSVOL, or simply pick the server which has the most subfolders beneath the Policies folder, or some combination of these. You can also copy those subfolders from the Policies folder of one or more servers to the Policies folder of the one you choose, in order to ensure that the chosen server has copies of all of the GPOs that have been created on other DCs but not replicated successfully throughout the domain.


On the DC that you chose in step 1, perform an authoritative restore of FRS. The steps for doing so are given in MS KB article 290762, which, unfortunately, is rather poorly formatted. Reading the entire article is a good idea, but if you're under a time crunch, you can skip to the Authoritative FRS Restore section. Please note that the authoritative restore (setting Burflags to D4) should be performed on only one DC.


Wait for event 13516 to be logged in the File Replication Service event log of the DC in step 2. This may take a few minutes. This event indicates that FRS is functioning correctly on this DC.


Restart the File Replication Service on the other DCs, one at a time, and check their FRS event logs. When you see event 13516, that DC is good, and you may move on to the next one. If you don't see event 13516 after a few minutes, or if the log indicates that a particular DC is still in a journal-wrap state, go to step 5.


Perform a non-authoritative restore of FRS on any DCs which are still in journal wrap or aren't logging event 13516 for another reason. Use MS KB article 290762 again, but this time perform the steps in the Nonauthoritative Restore section (set Burflags to D2, not D4). This is very important - if you mistakenly set Burflags to D4 on one of these servers, you will likely lose some data and will have to recreate one or more GPOs and/or scripts from scratch or restore them from a backup.
If you run into any trouble with these steps, post the details here.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
CNBELGINAuthor Commented:
Microsoft was able to help by forcing the DCs to pull fresh copies of the Sysvol.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.