Remember when I did that?  Okay so maybe don’t do that.

As a result of doing that I started to get some really nasty looking errors in my application log file and WSUS couldn’t find the server and my Group policy console was horked up.



Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1058
Date:  12/26/2007
Time:  4:28:54 AM
User:  KIKIBITZRTM\Administrator
Windows cannot access the file gpt.ini for GPO cn={F58917D4-784A-43B7-BA4F-A8DDED4CED2A},cn=policies,cn=system,DC=Kikibitzrtm,DC=local. The file must be present at the location <\\Kikibitzrtm.local\SysVol\Kikibitzrtm.local\Policies\{F58917D4-784A-43B7-BA4F-A8DDED4CED2A}\gpt.ini>. (Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied. ). Group Policy processing aborted.

For more information, see Help and Support Center at

Yeah.  Not good.  And boy was WSUS and the group policy console not a happy camper, lemme tell you. 

What I found was that I had lost the SYSVOL share and that the policies had been moved from where they were supposed to be.

That was not shared out … and if SYSVOL is not shared.. Group policy is not a happy camper.

And the two folders, policies and scripts were stuck under NtFRS_PreExisting__See_EventLog

Okay…so maybe that journal wrap thing wasn’t so good of an idea after all.

 Now that I shared the sysvol back out, I’m down to only getting 1030 and 1006 errors.

We’ll obviously be checking out

Good thing this is the beat up home server ‘eh?


2 Responses to Help, I’ve lost my SYSVOL and can’t get up….

  1. Chris Knight says:

    Yeah, the journal wrap “fix” took the FRS database back to a clean state without anything useful in sysvol.

    The two choices are: restore System State to its original location from a reasonably close backup, or restore System State to an alternate location, then copy the folders back into the sysvol folder, using MSKB 315457 as a guide.

    Oh, and do a “chkdsk /f c:” first.

    The journal wrap problem is the best reason to perform a backup from within GPMC, or use a GPO repository tool like GPOVault (now in MDOP). It makes recovering your GPOs simpler.

  2. Pedro R. says:

    Hi again Susan.

    I’m back to mentioning the use of the Burflags key to fix Journal Wrap Errors instead of “Enable Journal Wrap Automatic Restore”. This technique also prevents you from seing the kind of errors you mention here (SYSVOL becoming empty).

    Using “Enable Journal Wrap Automatic Restore” will make NTFRS reinitialize all NTFRS shares and delete all contents in those shares (a very aggressive approach).
    Instead, just use the “Burflags” key and set it to “D4” and restart NTFRS. You will see it heal itself and yet, SYSVOL and NETLOGON will still be intact after the restore 😉

    If it’s the only DC in the network then I would go ahead with Burflags set to D4. If there is more than one DC you may wnat to set Burflags do D2.
    In any case check out the official docs: “Using the BurFlags registry key to reinitialize File Replication Service replica sets” at

    happy new year!!