From: Susan Bradley on
Copy the event log error and paste it here.

I'll the explain what it's saying and what it's going to do.

This is one of those times you have to stop reading all of those posts.
We're not them. We don't have a second DC. We're SBS and it picks it
up from the copy of the sysvol.

You perform the procedure by sticking the reg key in exactly as it says
and you let AD fix itself up.


JNelsonCPath wrote:
> Thanks, please forgive my ignorance, but I am very nervous to do this as it
> doesn't appear to fit my situation. Do you have any more detail you can
> offer me about why this will do the trick in my situation?? The "solution"
> in the event log removes the server from the replication set and then re-adds
> it. Is this OK because I only have a single DC?
> I am also reading way too many posts online about how this procedure harms
> the SYSVOL folder and removes data from it. If I can get a clear explanation
> of how to perform this procedure making sure it wont harm my SYSVOL as well
> as stop the replication set from trying over nad over to reach my old server,
> I will be happy.
>
> "Susan Bradley" wrote:
>
>
>> JNelsonCPath wrote:
>>
>>> I apologize ahead of time if this question was already discussed, I realize
>>> it is an older topic, but I couldn't find my particular "offshoot" of the
>>> issue so decided to post a question.
>>>
>>> Here is the history of the problem. I have an SBS 2003 Standard domain.
>>> Two years ago, I moved SBS 2003 to more powerful hardware by way of
>>> Microsoft's migration procedure. All went well except for the following:
>>> When I removed the old SBS from the network, I began getting errors in my
>>> file replication log on the new server complaining that it had a journal wrap
>>> error (event ID 13568) and could not read from the NTFS USN journal on the
>>> other server. Well the error is correct because the old server was removed
>>> and no longer exists. I made an assumption that Microsoft's recommended
>>> method for migrating SBS 2003 to new hardware would deal with any replication
>>> issues when the domain data was transferred, but it did not and the new
>>> server has been looking for the old one ever since.
>>>
>>> For the past two years, the SBS 2003 server has been running tip top and has
>>> experienced few issues. We now plan to migrate to SBS 2008 to take advantage
>>> of the newer technologies, and this journal wrap error has become important
>>> again. I have researched the web for days looking for a solution to my
>>> particular situation and cannot find anything that makes sense for this
>>> particular problem. All of the solutions, ideas, posts, KB articles, etc...
>>> that I have been looking at are solutions and ideas for restoring replication
>>> between two or more partners. While these solutions and ideas are talking
>>> about the same error message that I am seeing on my server, I have to assume
>>> that they don't apply to me becasue there is no location on my network to
>>> replicate with.
>>> How can I resolve the NTFRS errors I am seeing with no replication partner
>>> available? It is important that I resolve this before we migrate. All
>>> solutions I have seen say that the server will be removed from the
>>> replication set and then re-added to it which is impossible due to the old
>>> server being gone.
>>>
>>> Thank you in advance!
>>>
>>>
>>>
>> See the error message in the event logs?
>> Read it.
>> See what it says to do? See how it says to add an reg key?
>> Do it.
>> It's that easy.
>> .
>>
>>
From: JNelsonCPath on
OK thank you. I will post the error when I get to the office.
I became nervous about following this procedure after finding this... Not
100% sure, but it appears to have been written by you.
http://msmvps.com/blogs/bradley/archive/2007/12/26/fixing-a-little-bit-of-journal-wrap.aspx
And This...
http://msmvps.com/blogs/bradley/archive/2007/12/27/help-i-ve-lost-my-sysvol-and-can-t-get-up.aspx
Sorry for my confusion.

"Susan Bradley" wrote:

> Copy the event log error and paste it here.
>
> I'll the explain what it's saying and what it's going to do.
>
> This is one of those times you have to stop reading all of those posts.
> We're not them. We don't have a second DC. We're SBS and it picks it
> up from the copy of the sysvol.
>
> You perform the procedure by sticking the reg key in exactly as it says
> and you let AD fix itself up.
>
>
> JNelsonCPath wrote:
> > Thanks, please forgive my ignorance, but I am very nervous to do this as it
> > doesn't appear to fit my situation. Do you have any more detail you can
> > offer me about why this will do the trick in my situation?? The "solution"
> > in the event log removes the server from the replication set and then re-adds
> > it. Is this OK because I only have a single DC?
> > I am also reading way too many posts online about how this procedure harms
> > the SYSVOL folder and removes data from it. If I can get a clear explanation
> > of how to perform this procedure making sure it wont harm my SYSVOL as well
> > as stop the replication set from trying over nad over to reach my old server,
> > I will be happy.
> >
> > "Susan Bradley" wrote:
> >
> >
> >> JNelsonCPath wrote:
> >>
> >>> I apologize ahead of time if this question was already discussed, I realize
> >>> it is an older topic, but I couldn't find my particular "offshoot" of the
> >>> issue so decided to post a question.
> >>>
> >>> Here is the history of the problem. I have an SBS 2003 Standard domain.
> >>> Two years ago, I moved SBS 2003 to more powerful hardware by way of
> >>> Microsoft's migration procedure. All went well except for the following:
> >>> When I removed the old SBS from the network, I began getting errors in my
> >>> file replication log on the new server complaining that it had a journal wrap
> >>> error (event ID 13568) and could not read from the NTFS USN journal on the
> >>> other server. Well the error is correct because the old server was removed
> >>> and no longer exists. I made an assumption that Microsoft's recommended
> >>> method for migrating SBS 2003 to new hardware would deal with any replication
> >>> issues when the domain data was transferred, but it did not and the new
> >>> server has been looking for the old one ever since.
> >>>
> >>> For the past two years, the SBS 2003 server has been running tip top and has
> >>> experienced few issues. We now plan to migrate to SBS 2008 to take advantage
> >>> of the newer technologies, and this journal wrap error has become important
> >>> again. I have researched the web for days looking for a solution to my
> >>> particular situation and cannot find anything that makes sense for this
> >>> particular problem. All of the solutions, ideas, posts, KB articles, etc...
> >>> that I have been looking at are solutions and ideas for restoring replication
> >>> between two or more partners. While these solutions and ideas are talking
> >>> about the same error message that I am seeing on my server, I have to assume
> >>> that they don't apply to me becasue there is no location on my network to
> >>> replicate with.
> >>> How can I resolve the NTFRS errors I am seeing with no replication partner
> >>> available? It is important that I resolve this before we migrate. All
> >>> solutions I have seen say that the server will be removed from the
> >>> replication set and then re-added to it which is impossible due to the old
> >>> server being gone.
> >>>
> >>> Thank you in advance!
> >>>
> >>>
> >>>
> >> See the error message in the event logs?
> >> Read it.
> >> See what it says to do? See how it says to add an reg key?
> >> Do it.
> >> It's that easy.
> >> .
> >>
> >>
> .
>
From: Susan Bradley on
Yup that's me. If the one burflags value doesn't work you do the other one.
JNelsonCPath wrote:
> OK thank you. I will post the error when I get to the office.
> I became nervous about following this procedure after finding this... Not
> 100% sure, but it appears to have been written by you.
> http://msmvps.com/blogs/bradley/archive/2007/12/26/fixing-a-little-bit-of-journal-wrap.aspx
> And This...
> http://msmvps.com/blogs/bradley/archive/2007/12/27/help-i-ve-lost-my-sysvol-and-can-t-get-up.aspx
> Sorry for my confusion.
>
> "Susan Bradley" wrote:
>
>
>> Copy the event log error and paste it here.
>>
>> I'll the explain what it's saying and what it's going to do.
>>
>> This is one of those times you have to stop reading all of those posts.
>> We're not them. We don't have a second DC. We're SBS and it picks it
>> up from the copy of the sysvol.
>>
>> You perform the procedure by sticking the reg key in exactly as it says
>> and you let AD fix itself up.
>>
>>
>> JNelsonCPath wrote:
>>
>>> Thanks, please forgive my ignorance, but I am very nervous to do this as it
>>> doesn't appear to fit my situation. Do you have any more detail you can
>>> offer me about why this will do the trick in my situation?? The "solution"
>>> in the event log removes the server from the replication set and then re-adds
>>> it. Is this OK because I only have a single DC?
>>> I am also reading way too many posts online about how this procedure harms
>>> the SYSVOL folder and removes data from it. If I can get a clear explanation
>>> of how to perform this procedure making sure it wont harm my SYSVOL as well
>>> as stop the replication set from trying over nad over to reach my old server,
>>> I will be happy.
>>>
>>> "Susan Bradley" wrote:
>>>
>>>
>>>
>>>> JNelsonCPath wrote:
>>>>
>>>>
>>>>> I apologize ahead of time if this question was already discussed, I realize
>>>>> it is an older topic, but I couldn't find my particular "offshoot" of the
>>>>> issue so decided to post a question.
>>>>>
>>>>> Here is the history of the problem. I have an SBS 2003 Standard domain.
>>>>> Two years ago, I moved SBS 2003 to more powerful hardware by way of
>>>>> Microsoft's migration procedure. All went well except for the following:
>>>>> When I removed the old SBS from the network, I began getting errors in my
>>>>> file replication log on the new server complaining that it had a journal wrap
>>>>> error (event ID 13568) and could not read from the NTFS USN journal on the
>>>>> other server. Well the error is correct because the old server was removed
>>>>> and no longer exists. I made an assumption that Microsoft's recommended
>>>>> method for migrating SBS 2003 to new hardware would deal with any replication
>>>>> issues when the domain data was transferred, but it did not and the new
>>>>> server has been looking for the old one ever since.
>>>>>
>>>>> For the past two years, the SBS 2003 server has been running tip top and has
>>>>> experienced few issues. We now plan to migrate to SBS 2008 to take advantage
>>>>> of the newer technologies, and this journal wrap error has become important
>>>>> again. I have researched the web for days looking for a solution to my
>>>>> particular situation and cannot find anything that makes sense for this
>>>>> particular problem. All of the solutions, ideas, posts, KB articles, etc...
>>>>> that I have been looking at are solutions and ideas for restoring replication
>>>>> between two or more partners. While these solutions and ideas are talking
>>>>> about the same error message that I am seeing on my server, I have to assume
>>>>> that they don't apply to me becasue there is no location on my network to
>>>>> replicate with.
>>>>> How can I resolve the NTFRS errors I am seeing with no replication partner
>>>>> available? It is important that I resolve this before we migrate. All
>>>>> solutions I have seen say that the server will be removed from the
>>>>> replication set and then re-added to it which is impossible due to the old
>>>>> server being gone.
>>>>>
>>>>> Thank you in advance!
>>>>>
>>>>>
>>>>>
>>>>>
>>>> See the error message in the event logs?
>>>> Read it.
>>>> See what it says to do? See how it says to add an reg key?
>>>> Do it.
>>>> It's that easy.
>>>> .
>>>>
>>>>
>>>>
>> .
>>
>>
From: JNelsonCPath on
So are you now telling me to skip the event ID procedure and do the burflags
procedure??

"Susan Bradley" wrote:

> Yup that's me. If the one burflags value doesn't work you do the other one.
> JNelsonCPath wrote:
> > OK thank you. I will post the error when I get to the office.
> > I became nervous about following this procedure after finding this... Not
> > 100% sure, but it appears to have been written by you.
> > http://msmvps.com/blogs/bradley/archive/2007/12/26/fixing-a-little-bit-of-journal-wrap.aspx
> > And This...
> > http://msmvps.com/blogs/bradley/archive/2007/12/27/help-i-ve-lost-my-sysvol-and-can-t-get-up.aspx
> > Sorry for my confusion.
> >
> > "Susan Bradley" wrote:
> >
> >
> >> Copy the event log error and paste it here.
> >>
> >> I'll the explain what it's saying and what it's going to do.
> >>
> >> This is one of those times you have to stop reading all of those posts.
> >> We're not them. We don't have a second DC. We're SBS and it picks it
> >> up from the copy of the sysvol.
> >>
> >> You perform the procedure by sticking the reg key in exactly as it says
> >> and you let AD fix itself up.
> >>
> >>
> >> JNelsonCPath wrote:
> >>
> >>> Thanks, please forgive my ignorance, but I am very nervous to do this as it
> >>> doesn't appear to fit my situation. Do you have any more detail you can
> >>> offer me about why this will do the trick in my situation?? The "solution"
> >>> in the event log removes the server from the replication set and then re-adds
> >>> it. Is this OK because I only have a single DC?
> >>> I am also reading way too many posts online about how this procedure harms
> >>> the SYSVOL folder and removes data from it. If I can get a clear explanation
> >>> of how to perform this procedure making sure it wont harm my SYSVOL as well
> >>> as stop the replication set from trying over nad over to reach my old server,
> >>> I will be happy.
> >>>
> >>> "Susan Bradley" wrote:
> >>>
> >>>
> >>>
> >>>> JNelsonCPath wrote:
> >>>>
> >>>>
> >>>>> I apologize ahead of time if this question was already discussed, I realize
> >>>>> it is an older topic, but I couldn't find my particular "offshoot" of the
> >>>>> issue so decided to post a question.
> >>>>>
> >>>>> Here is the history of the problem. I have an SBS 2003 Standard domain.
> >>>>> Two years ago, I moved SBS 2003 to more powerful hardware by way of
> >>>>> Microsoft's migration procedure. All went well except for the following:
> >>>>> When I removed the old SBS from the network, I began getting errors in my
> >>>>> file replication log on the new server complaining that it had a journal wrap
> >>>>> error (event ID 13568) and could not read from the NTFS USN journal on the
> >>>>> other server. Well the error is correct because the old server was removed
> >>>>> and no longer exists. I made an assumption that Microsoft's recommended
> >>>>> method for migrating SBS 2003 to new hardware would deal with any replication
> >>>>> issues when the domain data was transferred, but it did not and the new
> >>>>> server has been looking for the old one ever since.
> >>>>>
> >>>>> For the past two years, the SBS 2003 server has been running tip top and has
> >>>>> experienced few issues. We now plan to migrate to SBS 2008 to take advantage
> >>>>> of the newer technologies, and this journal wrap error has become important
> >>>>> again. I have researched the web for days looking for a solution to my
> >>>>> particular situation and cannot find anything that makes sense for this
> >>>>> particular problem. All of the solutions, ideas, posts, KB articles, etc...
> >>>>> that I have been looking at are solutions and ideas for restoring replication
> >>>>> between two or more partners. While these solutions and ideas are talking
> >>>>> about the same error message that I am seeing on my server, I have to assume
> >>>>> that they don't apply to me becasue there is no location on my network to
> >>>>> replicate with.
> >>>>> How can I resolve the NTFRS errors I am seeing with no replication partner
> >>>>> available? It is important that I resolve this before we migrate. All
> >>>>> solutions I have seen say that the server will be removed from the
> >>>>> replication set and then re-added to it which is impossible due to the old
> >>>>> server being gone.
> >>>>>
> >>>>> Thank you in advance!
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> See the error message in the event logs?
> >>>> Read it.
> >>>> See what it says to do? See how it says to add an reg key?
> >>>> Do it.
> >>>> It's that easy.
> >>>> .
> >>>>
> >>>>
> >>>>
> >> .
> >>
> >>
> .
>
From: Duncan McC on
I would recommend you attempt to fix the journal wrap error on the
server by setting the Burflags registry entry to D4, and restart NTFRS
service (and not set the "Enable Journal Wrap Automatic Restore"
registry parameter").

Backup your server first.

Do the procedure. The check the SYSVOL share and Event Logs.

--
Duncan.


In article <228237DB-01D0-4264-9E88-90E77FE51E13(a)microsoft.com>,
JNelsonCPath(a)discussions.microsoft.com says...
>
> So are you now telling me to skip the event ID procedure and do the burflags
> procedure??
>
> "Susan Bradley" wrote:
>
> > Yup that's me. If the one burflags value doesn't work you do the other one.
> > JNelsonCPath wrote:
> > > OK thank you. I will post the error when I get to the office.
> > > I became nervous about following this procedure after finding this... Not
> > > 100% sure, but it appears to have been written by you.
> > > http://msmvps.com/blogs/bradley/archive/2007/12/26/fixing-a-little-bit-of-journal-wrap.aspx
> > > And This...
> > > http://msmvps.com/blogs/bradley/archive/2007/12/27/help-i-ve-lost-my-sysvol-and-can-t-get-up.aspx
> > > Sorry for my confusion.
> > >
> > > "Susan Bradley" wrote:
> > >
> > >
> > >> Copy the event log error and paste it here.
> > >>
> > >> I'll the explain what it's saying and what it's going to do.
> > >>
> > >> This is one of those times you have to stop reading all of those posts.
> > >> We're not them. We don't have a second DC. We're SBS and it picks it
> > >> up from the copy of the sysvol.
> > >>
> > >> You perform the procedure by sticking the reg key in exactly as it says
> > >> and you let AD fix itself up.
> > >>
> > >>
> > >> JNelsonCPath wrote:
> > >>
> > >>> Thanks, please forgive my ignorance, but I am very nervous to do this as it
> > >>> doesn't appear to fit my situation. Do you have any more detail you can
> > >>> offer me about why this will do the trick in my situation?? The "solution"
> > >>> in the event log removes the server from the replication set and then re-adds
> > >>> it. Is this OK because I only have a single DC?
> > >>> I am also reading way too many posts online about how this procedure harms
> > >>> the SYSVOL folder and removes data from it. If I can get a clear explanation
> > >>> of how to perform this procedure making sure it wont harm my SYSVOL as well
> > >>> as stop the replication set from trying over nad over to reach my old server,
> > >>> I will be happy.
> > >>>
> > >>> "Susan Bradley" wrote:
> > >>>
> > >>>
> > >>>
> > >>>> JNelsonCPath wrote:
> > >>>>
> > >>>>
> > >>>>> I apologize ahead of time if this question was already discussed, I realize
> > >>>>> it is an older topic, but I couldn't find my particular "offshoot" of the
> > >>>>> issue so decided to post a question.
> > >>>>>
> > >>>>> Here is the history of the problem. I have an SBS 2003 Standard domain.
> > >>>>> Two years ago, I moved SBS 2003 to more powerful hardware by way of
> > >>>>> Microsoft's migration procedure. All went well except for the following:
> > >>>>> When I removed the old SBS from the network, I began getting errors in my
> > >>>>> file replication log on the new server complaining that it had a journal wrap
> > >>>>> error (event ID 13568) and could not read from the NTFS USN journal on the
> > >>>>> other server. Well the error is correct because the old server was removed
> > >>>>> and no longer exists. I made an assumption that Microsoft's recommended
> > >>>>> method for migrating SBS 2003 to new hardware would deal with any replication
> > >>>>> issues when the domain data was transferred, but it did not and the new
> > >>>>> server has been looking for the old one ever since.
> > >>>>>
> > >>>>> For the past two years, the SBS 2003 server has been running tip top and has
> > >>>>> experienced few issues. We now plan to migrate to SBS 2008 to take advantage
> > >>>>> of the newer technologies, and this journal wrap error has become important
> > >>>>> again. I have researched the web for days looking for a solution to my
> > >>>>> particular situation and cannot find anything that makes sense for this
> > >>>>> particular problem. All of the solutions, ideas, posts, KB articles, etc...
> > >>>>> that I have been looking at are solutions and ideas for restoring replication
> > >>>>> between two or more partners. While these solutions and ideas are talking
> > >>>>> about the same error message that I am seeing on my server, I have to assume
> > >>>>> that they don't apply to me becasue there is no location on my network to
> > >>>>> replicate with.
> > >>>>> How can I resolve the NTFRS errors I am seeing with no replication partner
> > >>>>> available? It is important that I resolve this before we migrate. All
> > >>>>> solutions I have seen say that the server will be removed from the
> > >>>>> replication set and then re-added to it which is impossible due to the old
> > >>>>> server being gone.
> > >>>>>
> > >>>>> Thank you in advance!
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>> See the error message in the event logs?
> > >>>> Read it.
> > >>>> See what it says to do? See how it says to add an reg key?
> > >>>> Do it.
> > >>>> It's that easy.
> > >>>> .
> > >>>>
> > >>>>
> > >>>>
> > >> .
> > >>
> > >>
> > .
> >

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: OWA and Documents
Next: Service Packs & Updates