Event id: 13568 - JRNL_WRAP_ERROR

Hi,
I have a Win 2003 R2 SP2 server which is my DC, file server, Exchange server, etc with about 75 XP clients attached to it.  Since January I have been seeing event ID 13568 (attached) logged in the File Replication Service event log after every reboot.  We had a few problems last year after installing a new AV package on the server where it hung on several occasions and I had to force a reset. I suspect this is what may have caused the problem.

I recently promoted another DC in the domain for testing purposes.  On this server I'm seeing event ID 13508 logged in the File Replication Service event log:-

The File Replication Service is having trouble enabling replication from \\server01.rowse.local to VIRTUALSERVER01 for c:\windows\sysvol\domain using the DNS name \\server01.rowse.local. FRS will keep retrying.

The domain is working OK.  I have attached the results of a dcdiag and netdiag.  The only error in the dcdiag relates to the FRS error.

So far the only solutions I can see are restoring the system state from a tape backup from before the error occured (scary).  Or carrying out an Authoritative FRS restore using the BurFlags registry key (also scary).

From reading KB 290762 (http://support.microsoft.com/kb/290762/) it appears that an Authoritative restore might fix the problem, however I have also read posts on EE from poor people who have lost their domain after carrying out a restore.

I want appreciate any advice on the safest way to move forward.

Thanks.
dcdiag.txt
netdiag.txt
event-ID-13568.txt
geoff_austinAsked:
Who is Participating?
 
dhruvarajpCommented:
well.. here is what i recomend
if 13508  is followed by another evend id 13509 .. you need not to do anything
snd if you are not geting the later event  then do this...
http://support.microsoft.com/kb/290762/ 

make  the old dc as authoritative and new dc as non authoritative

and you will not loost anything if you follow proper cautions while editing registery

nake BurFlags  D4 on the old dc and  D2 on the new dc

you will be all set

good luck
0
 
Coast-ITCommented:
restoring the system state is not a scary task.  

I would go for that option, I have done it lots of times.
0
 
geoff_austinAuthor Commented:
Coast-IT - Thanks for responding.

Which element of the system state would you restore?  In Backup Exec 11d I can select components to restore (see attached image).

Would restoring sysvol only fix this problem?  I wouldn't want to restore AD obviously because everyone who's joined since january will be removed and I'll lose any recent GPOs etc.
Restore-System-State.jpg
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
Coast-ITCommented:
I see your dilemma.  I can see you will have a problem restoring system state due tot he January thing...

Hopefully dhru's tip will resolve the problem.
0
 
geoff_austinAuthor Commented:
dhruvarajp - Thanks for your input.

Event id 13568 is not followed by 13569 (if that's what you meant).

I'm not sure I follow your instructions.  On the old DC you're saying follow the instructions on kb290762 to do an authoritative restore, wait until that server is happy, then do a non-authoritative restore on the second DC?
0
 
dhruvarajpCommented:
yes that is what i meant
here are the steps:
change the registery settings on both dcs
then
restart ntfrs on the   D4 dc (authoritative )
then restart ntfrs on  D2 dc   (non authoritative)

Thank you
Dhruv
0
 
geoff_austinAuthor Commented:
dhruvarajp - On the new DC I see event id 13508 in the file replication service event log:-

The File Replication Service is having trouble enabling replication from \\server01.rowse.local to VIRTUALSERVER01 for c:\windows\sysvol\domain using the DNS name \\server01.rowse.local. FRS will keep retrying.
 Following are some of the reasons you would see this warning.
 
 [1] FRS can not correctly resolve the DNS name \\server01.rowse.local from this computer.
 [2] FRS is not running on \\server01.rowse.local.
 [3] The topology information in the Active Directory for this replica has not yet replicated to all the Domain Controllers.
 
 This event log message will appear once per connection, After the problem is fixed you will see another event log message indicating that the connection has been established.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Because we've been seeing these posts on the old DC since January and the new DC was only added in August I expect that the new DC probably won't need to run a non-authoritative restore.  I expect that, once the problem is resolved on the old DC, replication will start working on the new DC without the need to run a restore.

I am still concerned about running the authoritative restore on the old DC.  I have seen a few posts from people after running a D4 where their domain goes down completely.

e.g. http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Q_24659982.html?sfQueryTermInfo=1+10+13568+30+event+id
0
 
dhruvarajpCommented:
||it turns out that after setting the Journal Wrap Automatic Restore to 1, and stopping and restarting the NTFRS service, something went drastically wrong ||

looks like they did something wrong and they changed something else as
"Journal Wrap Automatic Restore to 1 "


which we are not doing ...

i myself have done this process at least 10 times now and have had 100 % expected results
that is what i would be able to suggest you
0
 
dhruvarajpCommented:
opening a ticket with ms is not really worth it as they will charge you 250 $
and the support guy will do excatly what i recomended
0
 
geoff_austinAuthor Commented:
dhruvarajp - I appreciate your responses.

I understand that you have done this on many occassions and it has produced the expected results each time.  I'm sure you're right, and it will work as expected.  However if it doesn't I would like to have a backup plan.  I guess calling Microsoft if it all goes wrong is always an option...
0
 
dhruvarajpCommented:
ok.. what you can do is copy the complete sysvol folder to a alternate location
.. if you calling msft they will ask you to do so.. aslo take a systemstate back up  (i know you have that running on daily basis and before /after major chanes you do ,, becouse you are a smart system admin )
0
 
geoff_austinAuthor Commented:
Thanks again.

I have backed up the sysvol folder to another drive.

The system state is backed up as part of my daily backup using Backup Exec 11d.

I will leave this question open until after the weekend if that's OK.
0
 
ChiefITCommented:
You must fix DNS------FIRST:

Let's diagnose and fix DNS.

Please go to the command prompt of your DCs and type:

DCdiag /test:DNS
0
 
geoff_austinAuthor Commented:
ChiefIT - I ran the diagnostics check on DNS and the only errors were relating to external root hint DNS servers, so I went ahead with the restore.

dhruvarajp - Thanks for your input.  I ran the restore and I think the problem has gone away.  Thanks again for your help.
0
 
geoff_austinAuthor Commented:
Much appreciated
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.