>http://support.microsoft.com/kb/290762 

That is one of the first 2 articles I would have cited. Also if you are
only talking about SYSVOL and not another replica set, the exact
instructions are here in condensed form-
http://technet.microsoft.com/en-us/library/cc778345.aspx

 

Additionally http://support.microsoft.com/kb/292438  says in part:

To recover, the affected replica member will need to be reinitialized
with a non-authoritative restore (BURFLAGS=D2) where it will synchronize
files from an existing inbound partner. This re-initialization can be
time consuming for large replica sets. [1]
On computers that run either the Windows 2000 (2195 binary), Windows
2000 Service Pack 1 (SP1), or SP1 Hotfix (WINSE build 5298) versions of
the Ntfrs.exe file, the non-authoritative restore process must be
invoked manually by setting BURFLAGS=D2 in the Windows NT registry.
For Windows 2000 computers using Windows 2000 Service Pack 2 (SP2), or
the Windows 2000 SP2 hotfix (WINSE 11773), versions of the Ntfrs.exe
file, the service performs a programmatic non-authoritative restore when
the journal_wrap_error is detected.
By default, Windows 2000 Service Pack 3 (SP3) and Windows 2000 SP3
hotfix versions of the Ntfrs.exe file do not perform an automatic
non-authoritative restore (for example, SP3 leaves content in place as
2195 and SP1 did) 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 key is set to 1 in the following
registry key: 

HKLM\System\Ccs\Services\Ntfrs\Parameters 

 

Important Microsoft does not recommend that you use this registry
setting, and it should not be used post-Windows 2000 SP3.

 

 

[1] MS calls this a vVjoin and you have to be aware that it can take a
really long time depending on the size of the replica set involved and
could also fail. If it's a small set on a fast network it can take place
really quickly IME.

 

The 292438 KB article above also gives some advice on how to ascertain
possible causes and prescriptive guidance on how to rectify it. In the
cases I have encountered it has been fairly easy to determine the cause
but it did get me off my arse and watching that lab forest a little
closer with Ultrasound.

 

Some other good references-

 

A little old but has a great overview of how it works and the
terminology involved:

How FRS Works http://technet.microsoft.com/en-us/library/cc758169.aspx
A little old but has a great overview of how it works and the
terminology involved

 

MCP Mag article that gives a nice overview in a couple of pages, kind of
a Cliff's notes version-
http://mcpmag.com/features/article.asp?EditorialsID=403

 

Great blog from the DS team on FRSDiag-
http://blogs.technet.com/askds/archive/2008/05/30/how-to-get-the-most-fr
om-your-frsdiag.aspx

 

From: James Rankin [mailto:[email protected]] 
Sent: Friday, March 13, 2009 2:01 AM
To: NT System Admin Issues
Subject: Re: Userenv errors

 

I have had to do both the D2 and D4 restores on occasion, and both got
me out of sticky situations :-) You are right about the event log
advice, it seems to do nada

http://support.microsoft.com/kb/290762 

2009/3/12 Free, Bob <[email protected]>

That was one of my first guesses :-)

Did the event log tell you to "Enable Journal Wrap Automatic Restore"
registry parameter to 1 ?

If so that's not what the DS guys at MS will tell you to do today but I
don't know if the event log guidance ever got updated. Last time it
happened to me on 2K3SP1 the bogus advice was still in the event log
entry.

What they will tell you to do today is a non-authoritative SYSVOL
restore, AKA a D2 restore.

That is actually a "feature" that used to be the default behavior that
was disabled in W2KSP3 and W2KSP3 hotfix versions of Ntfrs.exe

I can dig up the details if it's of interest...





-----Original Message-----
From: Craig Gauss [mailto:[email protected]]

Sent: Thursday, March 12, 2009 1:53 PM
To: NT System Admin Issues
Subject: RE: Userenv errors

Yes



-----Original Message-----
From: Free, Bob [mailto:[email protected]]
Sent: Thursday, March 12, 2009 3:35 PM
To: NT System Admin Issues
Subject: RE: Userenv errors

Journal wrap hosing FRS replication?

-----Original Message-----
From: Craig Gauss [mailto:[email protected]]
Sent: Thursday, March 12, 2009 1:22 PM
To: NT System Admin Issues
Subject: RE: Userenv errors

Ran GPOTool and ended up finding replication was completely hosed on one
of our domain controllers.  Probably could have found the issue if I
would have looked at the event log on that server.  Followed the event
log suggestion and made the necessary registry changes. (Finally an
event log entry that helped for once)  Rebooted and the errors have
begun to go away.




-----Original Message-----
From: David Lum [mailto:[email protected]]
Sent: Thursday, March 12, 2009 2:57 PM
To: NT System Admin Issues
Subject: RE: Userenv errors

Do share!

Dave

-----Original Message-----
From: Craig Gauss [mailto:[email protected]]
Sent: Thursday, March 12, 2009 12:01 PM
To: NT System Admin Issues
Subject: RE: Userenv errors

Thanks for the GPOtool pointer.  Found an issue with one of our DCs.


Craig Gauss,  Technical Supervisor/Security Officer Riverview Hospital
Association
Phone: 715-423-6060 ext. 8572



-----Original Message-----
From: Free, Bob [mailto:[email protected]]
Sent: Thursday, March 12, 2009 12:23 PM
To: NT System Admin Issues
Subject: RE: Userenv errors

Fair chance you have inconsistent permissions on your sysvol or worse.
That error will show up if the computer accounts don't have proper
permissions.

Run GPOtool to check the GPOs in that domain, it will identify a lot of
problems right there without a lot of manual checking. There are a lot
of other things to check but start there.

Gpresult from an affected client can also be illuminating

-----Original Message-----
From: Craig Gauss [mailto:[email protected]]
Sent: Thursday, March 12, 2009 5:45 AM
To: NT System Admin Issues
Subject: Userenv errors

I have been searching Google for the past few days and havent really
found a good solution.  Wondering if anyone on the list has ever had
issues like this.  We have a large amount of workstations with the
following error:

Windows cannot access the file gpt.ini for GPO The file must be present
at the location <>. (). Group Policy processing aborted.

Any ideas?


~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~




~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

 

 

 

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Reply via email to