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.
>> >
>> >
>>
>>
>
>
>
Facebook
Twitter
Instagram