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

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
5 answers Last reply
More about only child domain disconnected longer tombs
  1. 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.
  2. 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
    ===================================
  3. 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:OeiEAIzLFHA.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.
    >
    >
  4. 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:OeiEAIzLFHA.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.
    > >
    > >
    >
    >
  5. 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:OeiEAIzLFHA.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.
    >> >
    >> >
    >>
    >>
    >
    >
    >
Ask a new question

Read More

Domain Connection Active Directory Windows