Only DC in child domain disconnected for longer then tombstone per

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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.
 
Alistair Keay said:
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.
Click to expand...

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
Click to expand...

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.
Click to expand...

I seldom recommend "Migration" but this may be such a case.
 
In
Alistair Keay said:
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.
Click to expand...

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.
 
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 said:
Herb,
Click to expand...

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?
Click to expand...

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.

--------------
 
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.
 
Back
Top