NTFRS Win2K3 Event ID 13506 Philip Blow 04.07.2007 06:34:01 Hi, 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. -------------------------------------------------------------------------

Re: NTFRS Win2K3 Event ID 13506 "Ned Pyle [MSFT]" <nedpyle[ at ]online.microsoft.com> 05.07.2007 23:16:43 That error definitely implies that the FRS engine thinks that the database thinks that the file system thinks (whew) that there are more than 100,000 nested subfolders within your SYSVOL. You can check, but I very much doubt that's the case - it's purely an issue within the DB in all microsoft experience, caused by some unknown corrupting behavior. 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" <PhilipBlow[ at ]discussions.microsoft.com> wrote in message news:F5E70D27-1A8E-4628-833E-18E13D6AF908[ at ]microsoft.com... [Quoted Text] > Hi, > > 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. > > -------------------------------------------------------------------------

Re: NTFRS Win2K3 Event ID 13506 Philip Blow 06.07.2007 01:26:02 Ned, 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 [MSFT]" wrote: [Quoted Text] > That error definitely implies that the FRS engine thinks that the database > thinks that the file system thinks (whew) that there are more than 100,000 > nested subfolders within your SYSVOL. You can check, but I very much doubt > that's the case - it's purely an issue within the DB in all microsoft > experience, caused by some unknown corrupting behavior. > > 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" <PhilipBlow[ at ]discussions.microsoft.com> wrote in message > news:F5E70D27-1A8E-4628-833E-18E13D6AF908[ at ]microsoft.com... > > Hi, > > > > 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. > > > > ------------------------------------------------------------------------- > >

Re: NTFRS Win2K3 Event ID 13506 "Ned Pyle [MSFT]" <nedpyle[ at ]online.microsoft.com> 06.07.2007 15:25:59 Ah. Poop. Well if you followed my earlier instructions you could potentially lose authoritative data... how much total data we talking about, how many spoke servers, and what are their connection speeds to the hub? -- 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" <PhilipBlow[ at ]discussions.microsoft.com> wrote in message news:AAA43AAC-B66E-42D1-B637-D47BF8AD576D[ at ]microsoft.com... [Quoted Text] > Ned, > > 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 [MSFT]" wrote: > >> That error definitely implies that the FRS engine thinks that the >> database >> thinks that the file system thinks (whew) that there are more than >> 100,000 >> nested subfolders within your SYSVOL. You can check, but I very much >> doubt >> that's the case - it's purely an issue within the DB in all microsoft >> experience, caused by some unknown corrupting behavior. >> >> 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" <PhilipBlow[ at ]discussions.microsoft.com> wrote in message >> news:F5E70D27-1A8E-4628-833E-18E13D6AF908[ at ]microsoft.com... >> > Hi, >> > >> > 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. >> > >> > ------------------------------------------------------------------------- >> >>

Re: NTFRS Win2K3 Event ID 13506 Philip Blow 07.07.2007 00:44:01 Ned, 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. Cheers, Philip "Ned Pyle [MSFT]" wrote: [Quoted Text] > Ah. Poop. Well if you followed my earlier instructions you could potentially > lose authoritative data... how much total data we talking about, how many > spoke servers, and what are their connection speeds to the hub? > > -- > > 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" <PhilipBlow[ at ]discussions.microsoft.com> wrote in message > news:AAA43AAC-B66E-42D1-B637-D47BF8AD576D[ at ]microsoft.com... > > Ned, > > > > 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 [MSFT]" wrote: > > > >> That error definitely implies that the FRS engine thinks that the > >> database > >> thinks that the file system thinks (whew) that there are more than > >> 100,000 > >> nested subfolders within your SYSVOL. You can check, but I very much > >> doubt > >> that's the case - it's purely an issue within the DB in all microsoft > >> experience, caused by some unknown corrupting behavior. > >> > >> 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" <PhilipBlow[ at ]discussions.microsoft.com> wrote in message > >> news:F5E70D27-1A8E-4628-833E-18E13D6AF908[ at ]microsoft.com... > >> > Hi, > >> > > >> > 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. > >> > > >> > ------------------------------------------------------------------------- > >> > >> > >