Restore Active Directory into a LAB - simple question...

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

Guest

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.
 
One other option for possible consideration:

dcpromo a DC, say DC_VM01 into a VM environment and detach it from the
live production environment. In the latter, clean up all references to
DC_VM01.

Make sure that DC_VM01 runs in its own isoloated lab environment to
avoid potential AD problems.
 
Desmond,

Thanks much for the quick response. We have actually been successful in
doing just as you have suggested, however, we are still hoping to be
successful with our AD system state restore in addition to this solution.
 
Simple question but involves quite a bit of work ....

Problem is that System State is machine specific and this is no guarantee
that the restored data match 1-to-1, even on physical machines with same
make, brand and model (except from the backup original source).

This could well be one of the best and safest approach, although it does not
give you a ready and up-to-date AD database to test in a Win 2000 lab
environment. Win 2003 has this "dcpromo /adv" option where this could be
deployed (in conjunction with Backup applet) though.

See
"How to use the Install from Media feature to promote Windows Server
2003-based domain controllers"
http://support.microsoft.com/default.aspx?scid=kb;en-us;311078


Minor variation of this approach. Make an additional copy of this VM image.
Use
one only for all lab experiments and use the other as follows:
- take this machine off-line
- re-introduce it onto the live network (to allow AD replication to propogate
to it) at regular intervals, but not longer than 60 days at any one time.

Since the 2 VMs are the same (file based images), you can then run a
backup from the updated VM and restore it to the other.

Hope this works for you. Let us know how it develops.
 
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.
 
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 said:
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.
Click to expand...
 
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 said:
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
Click to expand...
 
Yeah that sounds like the process alright... Isn't ntdsutils absolutely
evil?

I think its that way to make sure you don't think its a good idea unless you
absolutely have to do it. (Just like an authoritative restore.)
 
No question... Avoid doing an authoritative restore at all costs!
The less you use the ntdsutils the better off you will be...
 
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 ;)
 
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
 
Back
Top