Journal wrap error on only AD server

  • Thread starter Thread starter Knox
  • Start date Start date
K

Knox

Background: I have a client that has a single AD server. This machine
is running Windows 2000 Server (Standard) They have only one server
and about 15 client machines. They have never performed a backup on
the server.

For additional redundancy, I am trying to add two w2k3 servers to the
mix and make them domain controllers. Ultimately I will try to make
one of the w2k3 servers the new master. I have added the machines,
but the sysvols never get published on the additional machines.

I believe that I have located the root cause of the failure to
replicate. The event log on the w2k server shows error 13568
JRNL_WRAP_Error. It first showed this error months before I entered
the picture.

First Question: Is this error enough to prevent me from being able to
replicate? In other words, have I really identified the root cause?

The suggested fix is to perform a D2 non-authoritative restore and let
the server get the information from other replicas. Obviously I can't
do that, since there are no other servers.

What is the best course of action? It would seem like the only fix is
an authoritative restore (D4) but that seems extreme. Is there a
better plan, since as far as I can tell, the data on the old server is
fine. I just want to say forget the USN journal for a moment and
start from this point forward.

Thanks in advance,

Knox
 
First, did you run adprep against the domain before joining hte 2k3 DCs? If
not, search Help and Support on a 2003 machine for adprep.

Next, here's an old KB that doesn't exist anymore that might help:

Event 13568 Is Logged in the File Replication Service Event Log[ntrelease]
ID: Q315070 CREATED: 18-DEC-2001 MODIFIED: 06-AUG-2002

The information in this article applies to:
- Microsoft Windows 2000 Advanced Server
- Microsoft Windows 2000 Server
----------------------------------------------------------------------------
---
[...]
SYMPTOMS
========

The following event may be logged in the File Replication service (FRS)
event
log after you install Windows 2000 Service Pack 3 (SP3):

Event Type: Warning
Event Source: NtFrs
Event Category: None
Event ID: 13568
Date: 12/12/2001
Time: 2:03:32 PM
User: N/A
computer: NA-DC-01
Description:
[... event description...]

CAUSE
=====

This error message is logged because the requested data is not available due
to
the following series of events:

- FRS uses the NTFS file system journal to track changes to files and to
folders that are in a replica tree to propagate those changes to other
members of the replica set.

- If FRS does not record the changes, the journal wraps and FRS does not
know
which change to process next. FRS may not record the changes because:
- FRS is off for an extended period of time.
-or-
- The changes are occurring faster than FRS can process them.

- To recover from this error state, FRS needs to:
- Re-initialize the content of the replicated directory.
- Resume tracking the NTFS journal from a known good starting point.

- To re-initialize the replica tree, FRS moves all content into the
NTFRS_Pre-Existing folder, and then FRS rejoins the replica set by
sourcing
from an upstream partner. Based on the contents of the file, one of the
following events occurs:
- If a file on the upstream partner is identical to the file that is in
the NTFRS_Pre-Existing folder, the local copy is moved into the replica
tree.
- If the file is different, or if new files have been added to the
replica set, FRS replicates the update from the upstream partner and moves
it into the replica tree.
- During this procedure, the data on that particular member becomes
unavailable.

In Service Pack 2 (SP2), this re-initialization takes place automatically,
which may take the data offline at an inopportune time. In SP3, the event is
logged by default and an administrator can re-initialize the replica tree at
a convenient time.

RESOLUTION
==========

[...]

To modify the default behavior, make the following changes in the registry
to
instruct FRS to handle the JRNL_WRAP_ERROR status automatically:
1. Stop FRS.
2. Start Registry Editor (Regedt32.exe).
3. Locate and click the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters
4. On the Edit menu, click Add Value, and then add the following registry
value:
Value name: Enable Journal Wrap Automatic Restore
Data type: REG_DWORD
Radix: Hexadecimal
Value data: 1 (Default 0)
5. Quit Registry Editor.
6. Restart FRS.

If these steps do not modify the default settings and the automatic
re-initialization is not turned on, you need to manually re-initialize the
replica tree. At a convenient time, make the following changes to the
registry:

1. Stop FRS.
2. Start Registry Editor (Regedt32.exe).
3. Locate and click the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup
/Restore/Process
at Startup
4. On the Edit menu, click Add Value, and then add the following registry
value:
Value name: BurFlags
Data type: REG_DWORD
Radix: Hexadecimal
Value data: D2
5. Quit Registry Editor.
6. Restart FRS.

MORE INFORMATION
================
For additional information about SP3 updates to the File Replication
service,
click the article number below to view the article in the Microsoft
Knowledge
Base:
Q307319 File Replication Service Improvements in Windows 2000 SP3

--
--Brian Desmond
Windows Server MVP
(e-mail address removed)12.il.us

Http://www.briandesmond.com
 
Yes, I ran adprep prior to joining the two 2k3 DC's. I did not notice
anything abnormal at that point. Although I have a documented
migration plan, it did not contain adprep, and I don't remember
exactly the parameters that I used for Adprep, but assume I first did
the forest and followed by the domain adprep.

I saw that KB somewhere, and the bottom line is that it recommends a
D2 non-authoritative restore which I believe would try to restore from
other replicas. However, there unfortunately are no other replicas.
So I think I might be looking at a D4 authoritative restore. Is a D4
restore a reasonable thing?

By the way, everything else seems normal in the system... DNS seems
to be working fine, WINS is ok, DHCP is ok.

Sonar reports that the win2k machine fails to report replication
status on sysvol because of FRSSets: Unexpected output (0).

Thank you, Brian

Knox


First, did you run adprep against the domain before joining hte 2k3 DCs? If
not, search Help and Support on a 2003 machine for adprep.

Next, here's an old KB that doesn't exist anymore that might help:

Event 13568 Is Logged in the File Replication Service Event Log[ntrelease]
ID: Q315070 CREATED: 18-DEC-2001 MODIFIED: 06-AUG-2002

The information in this article applies to:
- Microsoft Windows 2000 Advanced Server
- Microsoft Windows 2000 Server
----------------------------------------------------------------------------
---
[...]
SYMPTOMS
========

The following event may be logged in the File Replication service (FRS)
event
log after you install Windows 2000 Service Pack 3 (SP3):

Event Type: Warning
Event Source: NtFrs
Event Category: None
Event ID: 13568
Date: 12/12/2001
Time: 2:03:32 PM
User: N/A
computer: NA-DC-01
Description:
[... event description...]

CAUSE
=====

This error message is logged because the requested data is not available due
to
the following series of events:

- FRS uses the NTFS file system journal to track changes to files and to
folders that are in a replica tree to propagate those changes to other
members of the replica set.

- If FRS does not record the changes, the journal wraps and FRS does not
know
which change to process next. FRS may not record the changes because:
- FRS is off for an extended period of time.
-or-
- The changes are occurring faster than FRS can process them.

- To recover from this error state, FRS needs to:
- Re-initialize the content of the replicated directory.
- Resume tracking the NTFS journal from a known good starting point.

- To re-initialize the replica tree, FRS moves all content into the
NTFRS_Pre-Existing folder, and then FRS rejoins the replica set by
sourcing
from an upstream partner. Based on the contents of the file, one of the
following events occurs:
- If a file on the upstream partner is identical to the file that is in
the NTFRS_Pre-Existing folder, the local copy is moved into the replica
tree.
- If the file is different, or if new files have been added to the
replica set, FRS replicates the update from the upstream partner and moves
it into the replica tree.
- During this procedure, the data on that particular member becomes
unavailable.

In Service Pack 2 (SP2), this re-initialization takes place automatically,
which may take the data offline at an inopportune time. In SP3, the event is
logged by default and an administrator can re-initialize the replica tree at
a convenient time.

RESOLUTION
==========

[...]

To modify the default behavior, make the following changes in the registry
to
instruct FRS to handle the JRNL_WRAP_ERROR status automatically:
1. Stop FRS.
2. Start Registry Editor (Regedt32.exe).
3. Locate and click the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters
4. On the Edit menu, click Add Value, and then add the following registry
value:
Value name: Enable Journal Wrap Automatic Restore
Data type: REG_DWORD
Radix: Hexadecimal
Value data: 1 (Default 0)
5. Quit Registry Editor.
6. Restart FRS.

If these steps do not modify the default settings and the automatic
re-initialization is not turned on, you need to manually re-initialize the
replica tree. At a convenient time, make the following changes to the
registry:

1. Stop FRS.
2. Start Registry Editor (Regedt32.exe).
3. Locate and click the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup
/Restore/Process
at Startup
4. On the Edit menu, click Add Value, and then add the following registry
value:
Value name: BurFlags
Data type: REG_DWORD
Radix: Hexadecimal
Value data: D2
5. Quit Registry Editor.
6. Restart FRS.

MORE INFORMATION
================
For additional information about SP3 updates to the File Replication
service,
click the article number below to view the article in the Microsoft
Knowledge
Base:
Q307319 File Replication Service Improvements in Windows 2000 SP3
Click to expand...
 
I guess that D4 stuff is sort of obsolete. I guess that now those
functions are carried out by booting into directory restore mode and
then using ntdsutil to carry out various actions.

Does anyone know if the various fixes, etc that ntdsutil can execute
can correct a journal_wrap_error?

Knox





Yes, I ran adprep prior to joining the two 2k3 DC's. I did not notice
anything abnormal at that point. Although I have a documented
migration plan, it did not contain adprep, and I don't remember
exactly the parameters that I used for Adprep, but assume I first did
the forest and followed by the domain adprep.

I saw that KB somewhere, and the bottom line is that it recommends a
D2 non-authoritative restore which I believe would try to restore from
other replicas. However, there unfortunately are no other replicas.
So I think I might be looking at a D4 authoritative restore. Is a D4
restore a reasonable thing?

By the way, everything else seems normal in the system... DNS seems
to be working fine, WINS is ok, DHCP is ok.

Sonar reports that the win2k machine fails to report replication
status on sysvol because of FRSSets: Unexpected output (0).

Thank you, Brian

Knox


First, did you run adprep against the domain before joining hte 2k3 DCs? If
not, search Help and Support on a 2003 machine for adprep.

Next, here's an old KB that doesn't exist anymore that might help:

Event 13568 Is Logged in the File Replication Service Event Log[ntrelease]
ID: Q315070 CREATED: 18-DEC-2001 MODIFIED: 06-AUG-2002

The information in this article applies to:
- Microsoft Windows 2000 Advanced Server
- Microsoft Windows 2000 Server
----------------------------------------------------------------------------
---
[...]
SYMPTOMS
========

The following event may be logged in the File Replication service (FRS)
event
log after you install Windows 2000 Service Pack 3 (SP3):

Event Type: Warning
Event Source: NtFrs
Event Category: None
Event ID: 13568
Date: 12/12/2001
Time: 2:03:32 PM
User: N/A
computer: NA-DC-01
Description:
[... event description...]

CAUSE
=====

This error message is logged because the requested data is not available due
to
the following series of events:

- FRS uses the NTFS file system journal to track changes to files and to
folders that are in a replica tree to propagate those changes to other
members of the replica set.

- If FRS does not record the changes, the journal wraps and FRS does not
know
which change to process next. FRS may not record the changes because:
- FRS is off for an extended period of time.
-or-
- The changes are occurring faster than FRS can process them.

- To recover from this error state, FRS needs to:
- Re-initialize the content of the replicated directory.
- Resume tracking the NTFS journal from a known good starting point.

- To re-initialize the replica tree, FRS moves all content into the
NTFRS_Pre-Existing folder, and then FRS rejoins the replica set by
sourcing
from an upstream partner. Based on the contents of the file, one of the
following events occurs:
- If a file on the upstream partner is identical to the file that is in
the NTFRS_Pre-Existing folder, the local copy is moved into the replica
tree.
- If the file is different, or if new files have been added to the
replica set, FRS replicates the update from the upstream partner and moves
it into the replica tree.
- During this procedure, the data on that particular member becomes
unavailable.

In Service Pack 2 (SP2), this re-initialization takes place automatically,
which may take the data offline at an inopportune time. In SP3, the event is
logged by default and an administrator can re-initialize the replica tree at
a convenient time.

RESOLUTION
==========

[...]

To modify the default behavior, make the following changes in the registry
to
instruct FRS to handle the JRNL_WRAP_ERROR status automatically:
1. Stop FRS.
2. Start Registry Editor (Regedt32.exe).
3. Locate and click the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters
4. On the Edit menu, click Add Value, and then add the following registry
value:
Value name: Enable Journal Wrap Automatic Restore
Data type: REG_DWORD
Radix: Hexadecimal
Value data: 1 (Default 0)
5. Quit Registry Editor.
6. Restart FRS.

If these steps do not modify the default settings and the automatic
re-initialization is not turned on, you need to manually re-initialize the
replica tree. At a convenient time, make the following changes to the
registry:

1. Stop FRS.
2. Start Registry Editor (Regedt32.exe).
3. Locate and click the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup
/Restore/Process
at Startup
4. On the Edit menu, click Add Value, and then add the following registry
value:
Value name: BurFlags
Data type: REG_DWORD
Radix: Hexadecimal
Value data: D2
5. Quit Registry Editor.
6. Restart FRS.

MORE INFORMATION
================
For additional information about SP3 updates to the File Replication
service,
click the article number below to view the article in the Microsoft
Knowledge
Base:
Q307319 File Replication Service Improvements in Windows 2000 SP3
Click to expand...
Click to expand...
 
Well,
I tried a number of solutions dealing with the AD database using
NTDSUTIL. None of them were efective. Authoritative restore, repair,
etc. None corrected the problem.

Knox
 
The errors you are seeing are not AD errors - they are FRS errors.
You were on the rigth track earlier with the D4 idea since this is an only
DC.
The journal wrap may have occured in your case, if too many changes occur
too quickly or if there were outstanding replication partners who were not
cleaned up properly. The journal size in Sp4 is something like 500 megs...
so you really shouldnt see this too often... IMO

pat
 
That makes sense. I thought for a while that what I was seeing was a
mismatch between the AD database and its log files, but that's totally
wrong.

I will try the D4 authoritative restore this weekend, but it bothers
me that there is so little documentation on the microsoft KB about
this. The only real information is
http://www.jsiinc.com/SUBM/tip6100/rh6153.htm which refers to a
non-existant microsoft Q. I guess that D4 has enough gotcha's that
they don't want it used by ordinary folks. :)

Knox
 
Back
Top