Sign in with
Sign up | Sign in
Your question

Only DC in child domain disconnected for longer then tombs..

Last response: in Windows 2000/NT
Share
Anonymous
March 22, 2005 4:47:02 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

Customer issue
They have a single DC (!) in a child domain.
Unfortunately a change was made to firewall so replication has not happened
since early January.

Firewall fixed but the DC will not replicate _ error 2042 It has been too
long since ... (I don't have the exact message but it appears that the DC
will not replicate with the root domain as the tombstone period has passed)

In the child domain are 60 users + PCs.
There is an exchange server but this is in the root domain.

Technet is quite clear about not trying to get replication to work _ however
this is the only DC in a child domain. However I am open to any options.
Can this domain be ever to made to work again _ if so how?
or should the accounts be moved to another domain
Any suggestions on how to salvage as much as possible greatfully received.

--
Thanks for any help,
Alistair
Anonymous
March 22, 2005 7:50:47 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

"Alistair Keay" <AlistairKeay@discussions.microsoft.com> wrote in message
news:42FD3794-A8BA-4188-9B91-681CFBE94BEF@microsoft.com...
> Customer issue
> They have a single DC (!) in a child domain.
> Unfortunately a change was made to firewall so replication has not
happened
> since early January.
>
> Firewall fixed but the DC will not replicate _ error 2042 It has been too
> long since ... (I don't have the exact message but it appears that the DC
> will not replicate with the root domain as the tombstone period has
passed)
>
> In the child domain are 60 users + PCs.
> There is an exchange server but this is in the root domain.
>
> Technet is quite clear about not trying to get replication to work _
however
> this is the only DC in a child domain. However I am open to any options.

For good reason.

You are likely hosed -- maybe someone else will offer
a trick I don't know however.

> Can this domain be ever to made to work again _ if so how?
> or should the accounts be moved to another domain

Probably your best bet is to try to migrate the users out of it,
to an existing (or a temporary) domain. Even using an existing
domain of the same forest will be a bit tricky since the default
"domain trusts" will probably not work anyway.

You might need to setup explicit "external trusts" to get the
needed trusts operation, or even have to move twice (once
to a trusted external domain and then back into the forest to
a new or existing domain.)

> Any suggestions on how to salvage as much as possible greatfully received.

I seldom recommend "Migration" but this may be such a case.
Anonymous
March 22, 2005 9:11:33 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

In news:42FD3794-A8BA-4188-9B91-681CFBE94BEF@microsoft.com,
Alistair Keay <AlistairKeay@discussions.microsoft.com> commented
Then Kevin replied below:
> Customer issue
> They have a single DC (!) in a child domain.
> Unfortunately a change was made to firewall so
> replication has not happened since early January.
>
> Firewall fixed but the DC will not replicate _ error 2042
> It has been too long since ... (I don't have the exact
> message but it appears that the DC will not replicate
> with the root domain as the tombstone period has passed)
>
> In the child domain are 60 users + PCs.
> There is an exchange server but this is in the root
> domain.
>
> Technet is quite clear about not trying to get
> replication to work _ however this is the only DC in a
> child domain. However I am open to any options. Can this
> domain be ever to made to work again _ if so how?
> or should the accounts be moved to another domain
> Any suggestions on how to salvage as much as possible
> greatfully received.

If replication has be down past the sixty day tombstone I'm afraid there is
nothing you can do. The only possible thing you can try is setting the date
back on the DC to less than the sixty day tombstone, and try to force
replication.
The last time I saw this happen was when two DCs in the forest root did
this, I spent six hours on the phone with MSPSS doing a force removal of AD
and repromoting the bad DC.

It might be possible to set the date back on both the parent and child DCs,
but don't go back any farther than you have to. If that doesn't work, your
no worse off I don't guess.


--
Best regards,
Kevin D4 Dad Goodknecht Sr. [MVP]
Hope This Helps
===================================
When responding to posts, please "Reply to Group"
via your newsreader so that others may learn and
benefit from your issue, to respond directly to
me remove the nospam. from my email address.
===================================
http://www.lonestaramerica.com/
===================================
Use Outlook Express?... Get OE_Quotefix:
It will strip signature out and more
http://home.in.tum.de/~jain/software/oe-quotefix/
===================================
Keep a back up of your OE settings and folders
with OEBackup:
http://www.oehelp.com/OEBackup/Default.aspx
===================================
Related resources
Can't find your answer ? Ask !
Anonymous
March 23, 2005 5:09:59 AM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

Herb,

Is there any chance he could do an authoritative restore of the domain
partition but not the Configuration or Schema partitions letting those
inherit from the forest root domain?

I am not sure how the tombstone dates interact with a restored AD partition.
Thoughts? I am grasping here because Herb is right -- without something
creative, you're likely hosed.

Otherwise, I would suggest:
1. Segregate that DC from the rest of the network
2. Back it up in case things get worse.
3. Make sure DNS is configured on this machine as AD-I
4. Seize all FSMO roles and do a metadata cleanup and kill all trusts
(netdom if you must)
5. Now the DC is acting as its own forest root. (Use DCdiag and Netdiag to
verify)
6. Bring in a new DC as a child of the original domain and different NetBios
name
7. Set up trusts and use ADMT to migrate users, Passwords, and SIDHistory to
the new DC
8. Migrate resources to the new DC
9. Wipe the old DC
10. Rejoin the old DC and promote it as a second DC in the new child domain.
--
Ryan Hanisco
MCSE, MCDBA
FlagShip Integration Services
Chicago, IL

"Herb Martin" <news@LearnQuick.com> wrote in message
news:o eiEAIzLFHA.1308@TK2MSFTNGP15.phx.gbl...
> "Alistair Keay" <AlistairKeay@discussions.microsoft.com> wrote in message
> news:42FD3794-A8BA-4188-9B91-681CFBE94BEF@microsoft.com...
>> Customer issue
>> They have a single DC (!) in a child domain.
>> Unfortunately a change was made to firewall so replication has not
> happened
>> since early January.
>>
>> Firewall fixed but the DC will not replicate _ error 2042 It has been too
>> long since ... (I don't have the exact message but it appears that the DC
>> will not replicate with the root domain as the tombstone period has
> passed)
>>
>> In the child domain are 60 users + PCs.
>> There is an exchange server but this is in the root domain.
>>
>> Technet is quite clear about not trying to get replication to work _
> however
>> this is the only DC in a child domain. However I am open to any options.
>
> For good reason.
>
> You are likely hosed -- maybe someone else will offer
> a trick I don't know however.
>
>> Can this domain be ever to made to work again _ if so how?
>> or should the accounts be moved to another domain
>
> Probably your best bet is to try to migrate the users out of it,
> to an existing (or a temporary) domain. Even using an existing
> domain of the same forest will be a bit tricky since the default
> "domain trusts" will probably not work anyway.
>
> You might need to setup explicit "external trusts" to get the
> needed trusts operation, or even have to move twice (once
> to a trusted external domain and then back into the forest to
> a new or existing domain.)
>
>> Any suggestions on how to salvage as much as possible greatfully
>> received.
>
> I seldom recommend "Migration" but this may be such a case.
>
>
Anonymous
March 23, 2005 3:13:27 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

"Ryan Hanisco" <rhanisco@flagshipis.com> wrote in message
news:u#FWR#3LFHA.732@TK2MSFTNGP12.phx.gbl...
> Herb,

I am going to answer (as best I can and incompletely)
your actual question, but first let me say that I am pretty
sure it will not solve the larger problem: Getting this
domain to replicate with the other domains in the forest,
while maintaining the domain partition information.


> Is there any chance he could do an authoritative restore of the domain
> partition but not the Configuration or Schema partitions letting those
> inherit from the forest root domain?

In theory this is possible, but I don't personally
know how nor do I immediately know if this
information is available so I will only be able
to suggest how I would go about thinking through
the problem....

Authoritative Restore includes both the possibility
of "restore subtree" and "restore database".

Of course the former restores only certain OU or
even smaller trees (down to individual objects),
and the latter restores the ENTIRE database which
has always been take to mean not just the domain
partition but all partitions.

Were there a way (this is what I don't know) to
specify a "subtree" that amounted to the Domain
partition (the entire domain BUT NOT the other
partitions) then it would be what you seek.

That is what I would research. (I might look at
ADSIEdit or other ADSI sources, not for the answer
but for a Distinguished Name that might equal that
'subtree'.)

Of course, even if you find that subtree name, it might
not be acceptable to NTDSUtil and so might fail for
silly reasons specific to this tool, despite the overall
soundness of the idea.

This brings us to two more ideas:

1) Restoring only the "Proper Subtrees"

2) Writing a script to bump the update serial numbers
in the same manner as NTDSUtil

#2 is made difficult because AD cannot be online while you
do this -- you might come up with some scheme for having
it online but network disconnected to it is able to accept
script updates but cannot replicate until you bring it
physically online.

#1 is a GOOD possibility if you had all or most of your
users in OUs rather than at the "root" of the Domain.
And/or you can extract a list of "other objects" from the
root.

Now note: Even if all users and computers are in OU trees,
then what about other objects we seldom notice explicitly:
GPO (links to the GPO files) and other housekeeping objects.

That is what (I think) I know.

I am leaving the rest of the message below for FYI purposes even
though my comments stop here.

--------------
> I am not sure how the tombstone dates interact with a restored AD
partition.
> Thoughts? I am grasping here because Herb is right -- without something
> creative, you're likely hosed.
>
> Otherwise, I would suggest:
> 1. Segregate that DC from the rest of the network
> 2. Back it up in case things get worse.
> 3. Make sure DNS is configured on this machine as AD-I
> 4. Seize all FSMO roles and do a metadata cleanup and kill all trusts
> (netdom if you must)
> 5. Now the DC is acting as its own forest root. (Use DCdiag and Netdiag to
> verify)
> 6. Bring in a new DC as a child of the original domain and different
NetBios
> name
> 7. Set up trusts and use ADMT to migrate users, Passwords, and SIDHistory
to
> the new DC
> 8. Migrate resources to the new DC
> 9. Wipe the old DC
> 10. Rejoin the old DC and promote it as a second DC in the new child
domain.
> --
> Ryan Hanisco
> MCSE, MCDBA
> FlagShip Integration Services
> Chicago, IL
>
> "Herb Martin" <news@LearnQuick.com> wrote in message
> news:o eiEAIzLFHA.1308@TK2MSFTNGP15.phx.gbl...
> > "Alistair Keay" <AlistairKeay@discussions.microsoft.com> wrote in
message
> > news:42FD3794-A8BA-4188-9B91-681CFBE94BEF@microsoft.com...
> >> Customer issue
> >> They have a single DC (!) in a child domain.
> >> Unfortunately a change was made to firewall so replication has not
> > happened
> >> since early January.
> >>
> >> Firewall fixed but the DC will not replicate _ error 2042 It has been
too
> >> long since ... (I don't have the exact message but it appears that the
DC
> >> will not replicate with the root domain as the tombstone period has
> > passed)
> >>
> >> In the child domain are 60 users + PCs.
> >> There is an exchange server but this is in the root domain.
> >>
> >> Technet is quite clear about not trying to get replication to work _
> > however
> >> this is the only DC in a child domain. However I am open to any
options.
> >
> > For good reason.
> >
> > You are likely hosed -- maybe someone else will offer
> > a trick I don't know however.
> >
> >> Can this domain be ever to made to work again _ if so how?
> >> or should the accounts be moved to another domain
> >
> > Probably your best bet is to try to migrate the users out of it,
> > to an existing (or a temporary) domain. Even using an existing
> > domain of the same forest will be a bit tricky since the default
> > "domain trusts" will probably not work anyway.
> >
> > You might need to setup explicit "external trusts" to get the
> > needed trusts operation, or even have to move twice (once
> > to a trusted external domain and then back into the forest to
> > a new or existing domain.)
> >
> >> Any suggestions on how to salvage as much as possible greatfully
> >> received.
> >
> > I seldom recommend "Migration" but this may be such a case.
> >
> >
>
>
Anonymous
March 23, 2005 3:37:48 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

Thanks Herb. I know that's pushing the boundary of things that should be
tried... It is an interesting thought though -- and one I might have to lab
out.

Thanks for your input. If I can get a partial restore to go, I'll let you
and the NG know.

--
Ryan Hanisco
MCSE, MCDBA
FlagShip Integration Services
Chicago, IL

"Herb Martin" <news@LearnQuick.com> wrote in message
news:%235fD0T9LFHA.3708@TK2MSFTNGP14.phx.gbl...
> "Ryan Hanisco" <rhanisco@flagshipis.com> wrote in message
> news:u#FWR#3LFHA.732@TK2MSFTNGP12.phx.gbl...
>> Herb,
>
> I am going to answer (as best I can and incompletely)
> your actual question, but first let me say that I am pretty
> sure it will not solve the larger problem: Getting this
> domain to replicate with the other domains in the forest,
> while maintaining the domain partition information.
>
>
>> Is there any chance he could do an authoritative restore of the domain
>> partition but not the Configuration or Schema partitions letting those
>> inherit from the forest root domain?
>
> In theory this is possible, but I don't personally
> know how nor do I immediately know if this
> information is available so I will only be able
> to suggest how I would go about thinking through
> the problem....
>
> Authoritative Restore includes both the possibility
> of "restore subtree" and "restore database".
>
> Of course the former restores only certain OU or
> even smaller trees (down to individual objects),
> and the latter restores the ENTIRE database which
> has always been take to mean not just the domain
> partition but all partitions.
>
> Were there a way (this is what I don't know) to
> specify a "subtree" that amounted to the Domain
> partition (the entire domain BUT NOT the other
> partitions) then it would be what you seek.
>
> That is what I would research. (I might look at
> ADSIEdit or other ADSI sources, not for the answer
> but for a Distinguished Name that might equal that
> 'subtree'.)
>
> Of course, even if you find that subtree name, it might
> not be acceptable to NTDSUtil and so might fail for
> silly reasons specific to this tool, despite the overall
> soundness of the idea.
>
> This brings us to two more ideas:
>
> 1) Restoring only the "Proper Subtrees"
>
> 2) Writing a script to bump the update serial numbers
> in the same manner as NTDSUtil
>
> #2 is made difficult because AD cannot be online while you
> do this -- you might come up with some scheme for having
> it online but network disconnected to it is able to accept
> script updates but cannot replicate until you bring it
> physically online.
>
> #1 is a GOOD possibility if you had all or most of your
> users in OUs rather than at the "root" of the Domain.
> And/or you can extract a list of "other objects" from the
> root.
>
> Now note: Even if all users and computers are in OU trees,
> then what about other objects we seldom notice explicitly:
> GPO (links to the GPO files) and other housekeeping objects.
>
> That is what (I think) I know.
>
> I am leaving the rest of the message below for FYI purposes even
> though my comments stop here.
>
> --------------
>> I am not sure how the tombstone dates interact with a restored AD
> partition.
>> Thoughts? I am grasping here because Herb is right -- without something
>> creative, you're likely hosed.
>>
>> Otherwise, I would suggest:
>> 1. Segregate that DC from the rest of the network
>> 2. Back it up in case things get worse.
>> 3. Make sure DNS is configured on this machine as AD-I
>> 4. Seize all FSMO roles and do a metadata cleanup and kill all trusts
>> (netdom if you must)
>> 5. Now the DC is acting as its own forest root. (Use DCdiag and Netdiag
>> to
>> verify)
>> 6. Bring in a new DC as a child of the original domain and different
> NetBios
>> name
>> 7. Set up trusts and use ADMT to migrate users, Passwords, and SIDHistory
> to
>> the new DC
>> 8. Migrate resources to the new DC
>> 9. Wipe the old DC
>> 10. Rejoin the old DC and promote it as a second DC in the new child
> domain.
>> --
>> Ryan Hanisco
>> MCSE, MCDBA
>> FlagShip Integration Services
>> Chicago, IL
>>
>> "Herb Martin" <news@LearnQuick.com> wrote in message
>> news:o eiEAIzLFHA.1308@TK2MSFTNGP15.phx.gbl...
>> > "Alistair Keay" <AlistairKeay@discussions.microsoft.com> wrote in
> message
>> > news:42FD3794-A8BA-4188-9B91-681CFBE94BEF@microsoft.com...
>> >> Customer issue
>> >> They have a single DC (!) in a child domain.
>> >> Unfortunately a change was made to firewall so replication has not
>> > happened
>> >> since early January.
>> >>
>> >> Firewall fixed but the DC will not replicate _ error 2042 It has been
> too
>> >> long since ... (I don't have the exact message but it appears that the
> DC
>> >> will not replicate with the root domain as the tombstone period has
>> > passed)
>> >>
>> >> In the child domain are 60 users + PCs.
>> >> There is an exchange server but this is in the root domain.
>> >>
>> >> Technet is quite clear about not trying to get replication to work _
>> > however
>> >> this is the only DC in a child domain. However I am open to any
> options.
>> >
>> > For good reason.
>> >
>> > You are likely hosed -- maybe someone else will offer
>> > a trick I don't know however.
>> >
>> >> Can this domain be ever to made to work again _ if so how?
>> >> or should the accounts be moved to another domain
>> >
>> > Probably your best bet is to try to migrate the users out of it,
>> > to an existing (or a temporary) domain. Even using an existing
>> > domain of the same forest will be a bit tricky since the default
>> > "domain trusts" will probably not work anyway.
>> >
>> > You might need to setup explicit "external trusts" to get the
>> > needed trusts operation, or even have to move twice (once
>> > to a trusted external domain and then back into the forest to
>> > a new or existing domain.)
>> >
>> >> Any suggestions on how to salvage as much as possible greatfully
>> >> received.
>> >
>> > I seldom recommend "Migration" but this may be such a case.
>> >
>> >
>>
>>
>
>
>
!