Archived from groups: microsoft.public.win2000.active_directory (
More info?)
Took us a week, but I believe the knowledge we have gained throughout this
weeks trials will pay off ten-fold.
Thanks all for the input.
I have simplified the process a bit...
These are still informal, but here is what we have thus far...
I have been able to recover without the use of a Non-Authoritative (or
Authritative) restore.
1) build new DC
2) introduce new DC into production domain
2.a) make the new DC a GC
3) let stand to room temp.
4) just before you make your changes to AD (ie. schema extending software
install) take a system state backup of all DCs
5) remove newly introduced DC from production domain (unplug network cable)
6) commit changes to domain (ie. install your schema extending software)
7) YOU HIT FAILURE AND LOOSE YOUR AD
8) remove all production DCs from network (unplug network cables)
9) plug your newly created DC back into production
10) remove all reference of the failed DCs that you just unplugged
(use the ntdsutils for this... metadata cleanup)
11) make this new DC no longer a GC (uncheck the box)
12) move the PDC, Infrastructure, RID, and Schema Master Roles to the new DC
12a) RID, and Schema seizures must be done via the ntdsutils
13) verify (netdom query domainname.com fsmo)
14) reinstall windows server OS on all failed DCs
15) reinstall components that where previously installed on those DCs (DNS,
DHCP, WINS)
16) dcpromo all new DCs with new hostnames (we have decided going forward
that we will introduce failed DC rebuilds with new hostnames)
We have reproduced this method of recovery 3 times now. We plan to re-test
one more time before making our documentation official.
Once again thanks for all the support.
Kind Regards,
MDH
"Desmond Lee" wrote:
>
> That looks just about right. At a minimum, you have a basis for documentation.
> As a reference, you can test, iterate and refine the process until everything
> can work like clockwork. Testing is imperative.
>
> Good luck, hope this helped, and keep us all posted should things turn
> interesting
>
>
> "MDH" wrote:
>
> > Couple things.
> >
> > 1) We added a tempDC to the domain as a "fail safe DC"
> > 2) let stand for replication
> > 3) realized that this tempDC must be a GC (check the box)
> > 4) take system state backup of prodDC01
> > 5) remove tempDC from production
> > 6) move tempDC into dev network
> > 7) Non-Authoritative restore of prodDC01 onto exact model of hardware in dev
> > network (I will call this devDC01 to avoid confusion)
> > 7a) wait wait and wait some more
> > 8) Uncheck the box on the tempDC in dev network (no longer can be GC)
> > 9) affirm devDC01 is schema master of dev domain
> > 10) seize other 4 FSMO roles to tempDC
> > 11) wait some more (replication gives us time to reflect... NOT)
> > 12) voila!
> > 13) the KCC is complaining about DCs that where in prod but do not exist in
> > dev so we graciously remove any reference of all DCs that are no longer
> > available (bit of an effort - ntdsutils)
> > 14) SAM was upset until we seized FSMO roles to dev - happy now
> > 15) Now we wait some more and hope for the best
> >
> >
> > "MDH" wrote:
> >
> > > Thanks Desmond and Ryan,
> > >
> > > This reaffirms the fact that it is a better practice to promote a DC, let
> > > stand to room temp., take system state of each DC in Production, remove
> > > tempDC from the domain, and then make your changes (install software that
> > > extends the schema). In the case of a failure we will seize all 5 roles to
> > > the DC we pulled and recover by rebuilding each of the Production DCs with a
> > > W2K reinstall then performing a system state restore (Non-Authoritative
> > > Restore) taken from each particular box just before making changes to domain.
> > >
> > > What do you think?
> > >
> > > Happy Holidays,
> > >
> > > Matt
> > >
> > > "Ryan Hanisco" wrote:
> > >
> > > > MDH,
> > > >
> > > > The quick answer is that it is not worth it unless you can guarantee that
> > > > you have the EXACT same hardware. Even then its not a cakewalk. This is
> > > > one of those procedures that usually only done when your server is in ruins,
> > > > its 4am, and you haven't slept in far too long.
> > > >
> > > > Generally its easier and just as effective to promote a DC, break it away,
> > > > seize the FSMO roles, then import the filesystem later.
> > > >
> > > > One last thought, if you are using mirrored RAID drives for your system
> > > > drive (you are, right?), you can break the array and rebuild onto a new
> > > > drive, essentially duplicating the server. Again... you need identical or
> > > > near identical hardware.
> > > >
> > > > --
> > > > Ryan Hanisco
> > > > MCSE, MCDBA
> > > > Flagship Integration Services
> > > >
> > > > "MDH" <horistm@shape-corp.com> wrote in message
> > > > news:B4374D4B-37F8-428F-BB39-2CE59805EE9B@microsoft.com...
> > > > > Can anyone point me to a document that will walk me through creating a
> > > > > replica of my production Windows 2000 domain into a lab environment?
> > > > >
> > > > > In a nutshell we would like take a 'system state backup' and restore it
> > > > into
> > > > > a lab environment. Seems like a simple task, but have had many issues
> > > > thus
> > > > > far...
> > > > > Have had no success in finding a concrete document on this process.
> > > > >
> > > > > --
> > > > > Thanks in advance,
> > > > >
> > > > > MDH
> > > >
> > > >
> > > >
Facebook
Twitter
Instagram