Discussion:
FRS Journal wrap condition...
(too old to reply)
Duncan McC
2009-09-09 23:51:06 UTC
Permalink
Hi,

I have a new client (yay!) and upon checking their server I've found
that is in a journal wrap condition, and I'm wondering what I should do
to fix this.

SBS 2003, Premium, R2, fully patched. (ISA and SQL Server are both
installed).

In the SBS Best Practices Analyzer, it points to:
http://support.microsoft.com/kb/292438

... which states on the page...
1.
=================================
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.
=================================


However; in the Event Logs, under File Replication Service, the error
message is:
2.
=================================
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.
=================================

So I'm not sure what path to follow (1. or 2.), and would appreciate any
feedback.

According to the Event Logs the journal wrap error has existed since Feb
2008.
--
Duncan
Les Connor [SBS MVP]
2009-09-09 23:57:35 UTC
Permalink
Hi Duncan,

I use the steps in the event itself, seems to work fine.
--
-----------------------------------------------
Les Connor [SBS MVP]
Post by Duncan McC
Hi,
I have a new client (yay!) and upon checking their server I've found
that is in a journal wrap condition, and I'm wondering what I should do
to fix this.
SBS 2003, Premium, R2, fully patched. (ISA and SQL Server are both
installed).
http://support.microsoft.com/kb/292438
... which states on the page...
1.
=================================
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.
=================================
However; in the Event Logs, under File Replication Service, the error
2.
=================================
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.
"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.
=================================
So I'm not sure what path to follow (1. or 2.), and would appreciate any
feedback.
According to the Event Logs the journal wrap error has existed since Feb
2008.
--
Duncan
Larry Struckmeyer[SBS-MVP]
2009-09-10 00:01:19 UTC
Permalink
Not that I doubt for an instant that what you see is "real", but please check
the event logs, as the Performance Report can show this for weeks after it
has been fixed.

As for fixing it, I tend toward the reg entry in your paragraph 2.


-
Larry
Please post the resolution to your
issue so others may benefit
-
Get Your SBS Health Check at
www.sbsbpa.com
Post by Duncan McC
Hi,
I have a new client (yay!) and upon checking their server I've found
that is in a journal wrap condition, and I'm wondering what I should
do to fix this.
SBS 2003, Premium, R2, fully patched. (ISA and SQL Server are both
installed).
http://support.microsoft.com/kb/292438
... which states on the page...
1.
=================================
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.
=================================
However; in the Event Logs, under File Replication Service, the error
2.
=================================
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.
"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.
=================================
So I'm not sure what path to follow (1. or 2.), and would appreciate
any feedback.
According to the Event Logs the journal wrap error has existed since
Feb 2008.
Duncan McC
2009-09-10 12:24:14 UTC
Permalink
Hi Larry,

I have examined several Performance Reports - can't find any reference
at all to the journal wrap error.

See my other reply (to Merv) for more details.
--
Duncan
Post by Larry Struckmeyer[SBS-MVP]
Not that I doubt for an instant that what you see is "real", but please check
the event logs, as the Performance Report can show this for weeks after it
has been fixed.
As for fixing it, I tend toward the reg entry in your paragraph 2.
-
Larry
Please post the resolution to your
issue so others may benefit
-
Get Your SBS Health Check at
www.sbsbpa.com
Post by Duncan McC
Hi,
I have a new client (yay!) and upon checking their server I've found
that is in a journal wrap condition, and I'm wondering what I should
do to fix this.
SBS 2003, Premium, R2, fully patched. (ISA and SQL Server are both
installed).
http://support.microsoft.com/kb/292438
... which states on the page...
1.
=================================
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.
=================================
However; in the Event Logs, under File Replication Service, the error
2.
=================================
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.
"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.
=================================
So I'm not sure what path to follow (1. or 2.), and would appreciate
any feedback.
According to the Event Logs the journal wrap error has existed since
Feb 2008.
Merv Porter [SBS-MVP]
2009-09-10 00:19:25 UTC
Permalink
I'd say go with setting the Burflags value (Solution 1) . Setting the
"Enable Journal Wrap Automatic Restore" registry parameter (Solution 2)
apparently can cause problems.

Help, I've lost my SYSVOL and can't get up
http://msmvps.com/blogs/bradley/archive/2007/12/27/help-i-ve-lost-my-sysvol-and-can-t-get-up.aspx

From the Comments section...
----------------------------------
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.
----------------------------------
--
Merv Porter [SBS-MVP]
============================
Post by Duncan McC
Hi,
I have a new client (yay!) and upon checking their server I've found
that is in a journal wrap condition, and I'm wondering what I should do
to fix this.
SBS 2003, Premium, R2, fully patched. (ISA and SQL Server are both
installed).
http://support.microsoft.com/kb/292438
... which states on the page...
1.
=================================
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.
=================================
However; in the Event Logs, under File Replication Service, the error
2.
=================================
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.
"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.
=================================
So I'm not sure what path to follow (1. or 2.), and would appreciate any
feedback.
According to the Event Logs the journal wrap error has existed since Feb
2008.
--
Duncan
Les Connor [SBS MVP]
2009-09-10 00:24:50 UTC
Permalink
Good find, as I once had fits trying to get sysvol back. But 3 or 4 other
occasions, using the steps in the event log did the trick without any drama.
--
-----------------------------------------------
Les Connor [SBS MVP]
Post by Merv Porter [SBS-MVP]
I'd say go with setting the Burflags value (Solution 1) . Setting the
"Enable Journal Wrap Automatic Restore" registry parameter (Solution 2)
apparently can cause problems.
Help, I've lost my SYSVOL and can't get up
http://msmvps.com/blogs/bradley/archive/2007/12/27/help-i-ve-lost-my-sysvol-and-can-t-get-up.aspx
From the Comments section...
----------------------------------
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.
----------------------------------
--
Merv Porter [SBS-MVP]
============================
Post by Duncan McC
Hi,
I have a new client (yay!) and upon checking their server I've found
that is in a journal wrap condition, and I'm wondering what I should do
to fix this.
SBS 2003, Premium, R2, fully patched. (ISA and SQL Server are both
installed).
http://support.microsoft.com/kb/292438
... which states on the page...
1.
=================================
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.
=================================
However; in the Event Logs, under File Replication Service, the error
2.
=================================
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.
"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.
=================================
So I'm not sure what path to follow (1. or 2.), and would appreciate any
feedback.
According to the Event Logs the journal wrap error has existed since Feb
2008.
--
Duncan
Duncan McC
2009-09-10 12:29:15 UTC
Permalink
Thanks Merv and Les for your replies...

I have decided to try the Burflags setting based on your info.

All seems good according to the Registry, the NTFRS has reportedly
restarted in a good state.

(I don't know whether setting the "Enable Journal Wrap Automatic
Restore" reg value would have caused any problems).
--
Duncan
Post by Merv Porter [SBS-MVP]
I'd say go with setting the Burflags value (Solution 1) . Setting the
"Enable Journal Wrap Automatic Restore" registry parameter (Solution 2)
apparently can cause problems.
Help, I've lost my SYSVOL and can't get up
http://msmvps.com/blogs/bradley/archive/2007/12/27/help-i-ve-lost-my-sysvol-and-can-t-get-up.aspx
From the Comments section...
----------------------------------
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.
----------------------------------
Duncan McC
2009-09-10 12:49:19 UTC
Permalink
That should say, according to the Event Logs - not Registry - I'm
lexdislic, but you already knew that.
--
Duncan

In article <***@news.microsoft.com>, ***@work.ok
says...
Post by Duncan McC
Thanks Merv and Les for your replies...
I have decided to try the Burflags setting based on your info.
All seems good according to the Registry, the NTFRS has reportedly
restarted in a good state.
(I don't know whether setting the "Enable Journal Wrap Automatic
Restore" reg value would have caused any problems).
Continue reading on narkive:
Loading...