Sign in with
Sign up | Sign in
Your question

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

Last response: in Windows 2000/NT
Share
Anonymous
December 20, 2004 3:15:04 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

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
Anonymous
December 20, 2004 3:29:03 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

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.


"MDH" wrote:

> 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
Anonymous
December 20, 2004 3:35:02 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

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.

"Desmond Lee" wrote:

> 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.
>
>
> "MDH" wrote:
>
> > 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
Related resources
Anonymous
December 20, 2004 4:11:02 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

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" wrote:

> 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.
>
> "Desmond Lee" wrote:
>
> > 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.
> >
> >
> > "MDH" wrote:
> >
> > > 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
Anonymous
December 20, 2004 8:15:00 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

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
Anonymous
December 21, 2004 9:21:03 AM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

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
>
>
>
Anonymous
December 21, 2004 10:29:03 AM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

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
> >
> >
> >
Anonymous
December 21, 2004 6:43:26 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

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.)
--
Ryan Hanisco
MCSE, MCDBA
Flagship Integration Services

"MDH" <horistm@shape-corp.com> wrote in message
news:1F4C99E3-6A67-4B95-B444-5CAF060E01FA@microsoft.com...
> 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
> > >
> > >
> > >
Anonymous
December 22, 2004 1:47:02 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

No question... Avoid doing an authoritative restore at all costs!
The less you use the ntdsutils the better off you will be...



"Ryan Hanisco" wrote:

> 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.)
> --
> Ryan Hanisco
> MCSE, MCDBA
> Flagship Integration Services
>
> "MDH" <horistm@shape-corp.com> wrote in message
> news:1F4C99E3-6A67-4B95-B444-5CAF060E01FA@microsoft.com...
> > 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
> > > >
> > > >
> > > >
>
>
>
Anonymous
December 22, 2004 2:05:02 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

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
> > >
> > >
> > >
Anonymous
December 22, 2004 4:23:02 PM

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
> > > >
> > > >
> > > >
!