Journal Wrap Error SBS + NTFRS Errors on addtional DC - Which do I fix?

I'm preparing an SBS 2003 environment for migration to SBS 2008.   I've got a Journal Wrap condition on the SBS server and journal errors on the member DC.

The text indicates I need to do a non-authoritative replication, but I'm concerned as to which server I should do first.  Being that they're both having errors, I'm not sure which way to replicate.

BTW, the system state of the SBS server was recently repaired the hard way.

Thanks in Advance,
Fred



Event on the additional DC:
 
Event Type:	Error
Event Source:	NtFrs
Event Category:	None
Event ID:	13568
Date:		3/29/2009
Time:		12:02:35 PM
User:		N/A
Computer:	SBS
Description:
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.
 
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
 
Event Type:	Error
Event Source:	NtFrs
Event Category:	None
Event ID:	13555
Date:		4/23/2009
Time:		4:48:22 PM
User:		N/A
Computer:	BARNEY
Description:
The File Replication Service is in an error state. Files will not replicate to or from one or all of the replica sets on this computer until the following recovery steps are performed: 
 
 Recovery Steps: 
 
 [1] The error state may clear itself if you stop and restart the FRS service. This can be done by performing the following in a command window: 
 
    net stop ntfrs 
    net start ntfrs 
 
If this fails to clear up the problem then proceed as follows. 
 
 [2] For Active Directory Domain Controllers that DO NOT host any DFS alternates or other replica sets with replication enabled: 
 
If there is at least one other Domain Controller in this domain then restore the "system state" of this DC from backup (using ntbackup or other backup-restore utility) and make it non-authoritative. 
 
If there are NO other Domain Controllers in this domain then restore the "system state" of this DC from backup (using ntbackup or other backup-restore utility) and choose the Advanced option which marks the sysvols as primary. 
 
If there are other Domain Controllers in this domain but ALL of them have this event log message then restore one of them as primary (data files from primary will replicate everywhere) and the others as non-authoritative. 
 
 
 [3] For Active Directory Domain Controllers that host DFS alternates or other replica sets with replication enabled: 
 
 (3-a) If the Dfs alternates on this DC do not have any other replication partners then copy the data under that Dfs share to a safe location. 
 (3-b) If this server is the only Active Directory Domain Controller for this domain then, before going to (3-c),  make sure this server does not have any inbound or outbound connections to other servers that were formerly Domain Controllers for this domain but are now off the net (and will never be coming back online) or have been fresh installed without being demoted. To delete connections use the Sites and Services snapin and look for 
Sites->NAME_OF_SITE->Servers->NAME_OF_SERVER->NTDS Settings->CONNECTIONS. 
 (3-c) Restore the "system state" of this DC from backup (using ntbackup or other backup-restore utility) and make it non-authoritative. 
 (3-d) Copy the data from step (3-a) above to the original location after the sysvol share is published. 
 
 
 [4] For other Windows servers: 
 
 (4-a)  If any of the DFS alternates or other replica sets hosted by this server do not have any other replication partners then copy the data under its share or replica tree root to a safe location. 
 (4-b)  net stop ntfrs 
 (4-c)  rd /s /q  c:\windows\ntfrs\jet 
 (4-d)  net start ntfrs 
 (4-e)  Copy the data from step (4-a) above to the original location after the service has initialized (5 minutes is a safe waiting time). 
 
Note: If this error message is in the eventlog of all the members of a particular replica set then perform steps (4-a) and (4-e) above on only one of the members.
 
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
 
 
Events on the SBS 2003 Box
 
 
Event Type:	Error
Event Source:	NtFrs
Event Category:	None
Event ID:	13568
Date:		4/23/2009
Time:		5:24:56 PM
User:		N/A
Computer:	SBS
Description:
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.
 
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
 
Event Type:	Error
Event Source:	NtFrs
Event Category:	None
Event ID:	13571
Date:		3/29/2009
Time:		12:02:16 PM
User:		N/A
Computer:	SBS
Description:
The File Replication Service has detected that one or more volumes on this computer have the same Volume Serial Number. File Replication  Service does not support this configuration. Files may not replicate  until this conflict is resolved. 
 
 Volume Serial Number : 84ec-9ae4 
 List of volumes that have this Volume Serial Number: c:, c: 
 
 The output of "dir" command displays the Volume Serial Number before listing the contents of the folder. 
 
 
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Open in new window

LVL 2
fredimacAsked:
Who is Participating?
 
snusgubbenCommented:
The important thing is what DC that holdes the files in SYSVOL. That one should be set the D4.

Copy all files in SYSVOL on the SBS DC to a safe place. Also take a system state backup of this DC. If you uses GPMC take a backup of the GPO's from the consol.

----
Event ID 13565 File Replication Service is initializing the system volume with data from another domain controller.
Seems like the second DC has been set to D2(?)

Event id 13508 - The File Replication Service is having trouble enabling replication. Can your second DC resolve and contact the SBS DC?

From cmd on the second DC:

ntfrsutl verison <FQDN to the SBS DC>
ping -a <SBS_DC_IP>
ping <FQDN to SBS_DC>

All three ok?

Do the same tests the other way.
----

Seems to me (if your DNS is ok), you should set D4 on the SBS and D2 on the second DC and restart ntfrs like you say.


SG
 

0
 
snusgubbenCommented:


If you got multiple DCs you just browse the SYSVOL's to see what DC that holds your policies and scripts.

Read these:

http://support.microsoft.com/default.aspx?scid=kb;en-us;315457
http://support.microsoft.com/kb/290762/en-us

The DC with the SYSVOL that is ok you set as authoritative (D4), the rest you can set to be non-authoritative (D2).


SG
0
 
fredimacAuthor Commented:
I did the procedure for the BurFlags on the member DC and it seems to be free of errors now.

I still have the Journal Wrap error 13568  on the SBS box.  should I give it some time before I try the same process on the SBS box?  

Thanks
Fred
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

 
snusgubbenCommented:
First I would restart the DC's, then check what the Event log says. You could also run a FRSDiag on both DC's to spot for errors.

You need to have a look at the SYSVOL on the "member DC" (assuming the "member DC" is a second DC). If you got all policies and script in it you can set the SBS box to "D2" so it will replicate the replica set with the "member DC".

Also compare the SYSVOL of both DC's. I guess one of them has more files then the other.


SG
0
 
fredimacAuthor Commented:
So currently, the SBS Box still shows the Journal Wrap condition (Event id 13568)

The 2nd DC shows Events 13565 and 13508

When I compare the folders, the SBS box contains the scripts and the member DC has only a folder called NtFrs_PreExisting___See_EventLog, which contains the Policies and Scripts folders and has fewer files in those folders.

My guess is that I need tell SBS it's the leader and replicate to the member DC?

What's your suggestion?

Thanks,
Fred
0
 
snusgubbenCommented:
Please have a look at this: http://support.microsoft.com/kb/958804

Just remember if you run the "DCGPOFIX" this will revert the Default Domain Policy and the Default Domain Controller Policy back to the state when your domain was created. Meaning all changes made to these GPOs will be lost.


SG

0
 
snusgubbenCommented:
In addition...
D4 means a authoritative "restore" that will be replicated to DC's with the Burflag set to D2.

SG
0
 
fredimacAuthor Commented:
I've read the docs and still feel a bit confused as to the order , direction of fixing.

The SBS box has files in the right place and dcdiag reports success, yet it indicates a journal wrap condition.

The member DC has the "pre-existing" subfolder.

Should I set the SBS box to D4 and the other server to D2, then restart ntfrs?  

What GPO information could be lost and can I back up that info before the process?

I'd like to make the SBS server use it's files as the good ones and replace those on the member server.

Thanks,
Fred
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.