At about 1:45 PM (local Sydney, AUS time) on Monday for no appart reason the
NTFRS service started to fail consistency checks in the NTFRS database. (I,
of course, had taken a few days off !) Below is the event log entry. I have
posted here because I could not find the specific error anywhere on the net
and I hoping someone might be able to assist with a solution.
The server on which the error is occuring on is the Domain Controller for
our head office (I have a second DC so auth services are still working). It
is running Windows Server 2003 Standard SP 1 plus all but last months
hotfixes. The server is also our primary file server and hosts our only DFS
root (there are partial replicas at our branch offices). Getting the server
back online with as little fuss as possible would be great.
The followup event log entry (ID 13555) suggests performing a full system
state restore on the DC, but I'm not sure if that is really necessary as it
only appears to be the ntfrs database or log files that are corrupted.
Is there any easy way to correct the corruption in the ntfrs database and
restart replication?
I have disabled replication for all DFS targets on the server and attempted
a D2 restore on SYSVOL, but the error still occurs and the FRS service halts.
Thanks in advance,
Philip.
---------------------------------------------------------------
Source: Ntfrs
Type: Error
ID: 13506
The File Replication Service failed a consistency check
(!"Hung in Journal entry filter lookup")
in "JrnlGetPathAndLevel:" at line 5292.
The File Replication Service will restart automatically at a later time. If
this problem persists a subsequent entry in this event log describes the
recovery procedure.
For more information about the automatic restart right click on My Computer
and then click on Manage, System Tools, Services, File Replication Service,
and Recovery.
-------------------------------------------------------------------------
If you are only using FRS for SYSVOL replication, I suggest:
1. Stop the FRS service on both nodes.
2. On the working server, set a burflag of D4 and start FRS.
3. On the non-working server, delete the contents of the %windir%\ntfrs\jet
folder (all files and folders zapped).
4. On the non-working server, set burflag of D2 (I realise you did this
before, but now we're doing it with the other server having the announce
falg of authoritative and the bad server not having any jet data to re-use).
5. Start FRS on the bad server.
6. Verify that the issue is corrected.
(I am using the old reliable article here that you propbably already know:
290762 Using the BurFlags registry key to reinitialize File Replication
Service replica sets
http://support.microsoft.com/default.aspx?scid=kb;EN-US;290762
)
If it is corrected and doesn't come back, chalk it up to elves. If it's
corrected and it *does* come back, start exploring your hardware to make
sure disk system isn't having any issues. If it's not corrected, ping me
back here - but I've seen this maybe 3-4 times in 7 years and the above
steps always corrected it forever, in my experience.
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Please read http://www.microsoft.com/info/cpyright.htm for more information.
"Philip Blow" <Phili...@discussions.microsoft.com> wrote in message
news:F5E70D27-1A8E-4628...@microsoft.com...
Thanks for the reply.
However, I am also using FRS on the corrupted server for DFS and the
corrupted server is the hub for all DFS replication. What will happen to the
DFS replicas if I delete the ntfrs database?
Cheers,
Philip
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Please read http://www.microsoft.com/info/cpyright.htm for more information.
"Philip Blow" <Phili...@discussions.microsoft.com> wrote in message
news:AAA43AAC-B66E-42D1...@microsoft.com...
I have two spokes. One is on a 1 Mbps link and the other is on a 512 Kpbs
link. I have about 60 GB of data that needs replicated to the faster spoke
and the about 30 GB to be replicated to the other. Thankfully I don't have to
pay for data transfer over these links.
After doing some quick calcs in my head I decided to bite the bullet and do
a full D2 restoration on the hub. I started on Friday evening. I need to
have as much of the hub as possible working for Monday morning. To hopefully
ensure that the mission critical replicas are rebuilt in time, I have
prioritised the initial synchronisation from the server on the 1 Mbps
connection over the other server. I have also disabled referrals to all
replicas on the hub and will reenable the referrals as soon as the replica is
rebuilt.
I'm hoping this is the most efficent way to rebuild the hub. I'm also using
some directory comparision software to ensure that all the files are
replicated correctly. This is a nice little trick I discovered when trying to
correct previous FRS replication problems.
Thanks again for your assistance. I'll post again on to let you know how I
went.