We are running several Windows Server 2008 R2 domain controllers. The replication of sysvol is done by NTFRS.

Yesterday, our master DC reported a "JRNL_WRAP_ERROR" for the SYSVOL Share. I ran a chkdsk on C:\ but it did not show any problems. After this, I have initiated an non-authoritative restore by stopping ntfrs.exe, setting BurFlags to "D2" in HKLM/SYSTEM/CurrentControlSet/services/Ntfrs/Parameters/Backup\Restore/Process at Startup and restarting ntrfs.exe again.

While this seems to work for C:\WINDOWS\SYSVOL\domain\Policies, it for some reason does not pull C:\Windows\Sysvol\domain\scripts from the other DCs. The scripts folder has a few directories in it after the non-authoritative restore and those are indeed supposed to be there. However, it does not contain all of them and the ones it contains are incomplete.

I also renamed C:\Windows\ntrfs\jet and started the non-authoritative restore again in order to rule out problems related to the cache, but it also didn't lead to any success.

After restarting the non-authoritative restore, I also noticed that the scripts directory strangely did not appear in C:\Windows\SYSVOL\domain\NtFrs_PreExisting___See_EventLog, while the Policies directory did. I assumed it simply moves C:\Windows\SYSVOL\domain\ to that folder, but seems it isn't that simple. The fact that it leaves out scripts makes me wonder whether there is some database keeping track of the content in C:\Windows\SYSVOL\domain\, so that it only moves what it actually knows.

The event log does not help me much, it says SYSVOL has been initiiated successfully after the non-authoriative restore.

EDIT: For now, we got rid of this issue by reinstalling AD on the affected server. While the directory got cleared after removal, C:\Windows\Sysvol\domain\scripts remained for some reason - perhapst a problem with permissions. We then explicitly deleted C:\WINDOWS\SYSVOL and reinstalled AD again.

  • 1
    Remember that you don't have a 'master DC' in a post-NT4 world.
    – phoebus
    Nov 14, 2013 at 15:49
  • So since SYSVOL is replicating via FRS, that means that these servers were either upgraded, or you are running at down-level domain/forest functional levels for some reason, right?
    – Ryan Ries
    Nov 14, 2013 at 17:35

1 Answer 1


The Problem happened again on another DC. It turns out that a few files were in the C:\Windows\Sysvol\domain\scripts folder - some exe files running. NTFRs.exe couldn't complete its task.

ntrfsutl was useful to debug this problem. http://support.microsoft.com/kb/822300/en-us is a certainly helpful. I used ntrfsutl inlog to see the state of files being transfered. For my case, the scripts folder was in state IBCO_INSTALL_REN_RETRY all the time. I then located all the files which held locks in the script directory (and its sub directories). Those were a few programs which were also running on client computers (but opened over the NETLOGON share).

You can use handles.exe from SysInternal Tools to identify open file handles. In my case some files were opened by the "System" process. Those were actually opened over the network share by client computers. I closed their handle via compmgmt.msc.

After all opened handles were closed, the replication finally succeeded.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .