The last time I recreated our test bed environment, I used VMWare and it worked great, just as expected. It was relatively quick and painless.
We have a multiple domain forest but really only cared about recreating our empty root and our largest production domains. We had earlier implemented what I call our OnlineRecovery site that contains a domain controller but replication is only enabled for one hour in the middle of the night. What that gives us is the ability to recover a deleted object during the day without negatively affecting any users. As long as we catch the deletion (or any change) during the day that it occurred, we simply reboot this domain controller in Restore mode, mark that object as being authorative and reboot back into normal mode. We then force replication out from that DC and the object will reappear on the other DCs. All this without affecting any other user as that DC is not doing anything else.
I used this DC to create my test bed by loading VMWare, setting up a DC in each domain in VMWare, shutting them down, making copies, moving them to the test bed and then going thru the normal clean up (ie role seizures, deleting 'dead DCs etc - not trivial but straight forward). Back on the production side, I started the VMWare sessions back up and DCPromoed them back down and stopped them altogether. I have recently started this process again using Microsoft's Virtual PC but have run into some issues. I highly recommend this OnlineRecovery site (personally save my butt more than once and another's in my department as well) and the use of a virtual machine software to make copies for a test bed environment. Currently I would lean towards the VMWare product. This process does require additional hardware and software licenses but in our environment has paid for itself already.
mark hocraffer
[EMAIL PROTECTED]
Principle Software Systems Engineer
Rockwell Collins
| "joe" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 01/12/2004 11:38 PM
|
|
We are just starting to look at this and haven't implemented. Done some rough experimentation, the hardware is in place to do more large scale testing. In the end the idea is that the machines will be production domain controllers but will be segmented off in a site that shouldn't be used by anyone. We don't want them processing authentication or other ldap requests, we simply want them replicating to get the DIT so we can shut them down daily and back up the virtual disk file.
The huge benefit is that if we have a catastrophic failure, we take any server capable of running Virtual Server and copy these files to it and turn then on and our old environment is back up and running again much faster than any other method we can think of.
As for the lab, you occasionally grab the disk file and transport to the lab and bam, you have production in the lab to see what that schema change will do to a live production environment before going into the real production environment. Mirroring production will never be truly close for everything, there will always be something different. I can visualize of no better way to be this close this easily and if done correctly most all of it can be scripted.
joe
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of marcus
Sent: Monday, January 12, 2004 11:57 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Lab Refresh Process
Are your virtual servers production servers? This sounds like a pretty cool idea…
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Monday, January 12, 2004 12:04 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Lab Refresh Process
What we are looking at for this is a virtual server setup. We pull the disk file image from production to the lab occasionally and spin it up in the protected network of the lab. It will be a side effect of our disaster recover model we are working on. Every day the virtual servers will be spun down and the disk files backed up and then the virtual servers will be spun back up. The images can then be used to restore the forest in case of huge disaster or could be pulled into a segregated lab for testing.
Still a swing server but not as involved as physical hardware.
joe
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Seielstad
Sent: Monday, January 12, 2004 11:21 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [ActiveDir] Lab Refresh Process
I was trying to think of a way in which I can get the SIDS & GUIDs without the swing server, but I can't think of another way.
--------------------------------------------------------------
Roger D. Seielstad - MTS MCSE MS-MVP
Sr. Systems Administrator
Inovis Inc.
-----Original Message-----
From: Myrick, Todd (NIH/CIT) [mailto:[EMAIL PROTECTED]
Sent: Monday, January 12, 2004 10:48 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [ActiveDir] Lab Refresh Process
Depends on what you
want to accomplish. Initially we had full production simulation of
our multi-domain AD forest. Today we simulate most of the deployments
using a few servers. I do more work, using VMware.
As to how to keep them
synced, if having the same SIDS and GUID is important, try joining and
removing a DC to the forest, then standing up a separate forest with the
rotated DC.
Todd
-----Original Message-----
From: Roger Seielstad [mailto:[EMAIL PROTECTED]
Sent: Monday, January 12, 2004 10:42 AM
To: '[EMAIL PROTECTED]'
Subject: [ActiveDir] Lab Refresh Process
I'm looking for info on how (and if) you are doing lab refreshes from your production forest.
My current test forest is, well, premigration (18 months old) at this point, and I'm staring down the barrel of a year or so of AD related projects, and I'd like to rebuild the lab environment from scratch.
Roger
--------------------------------------------------------------
Roger D. Seielstad - MTS MCSE MS-MVP
Sr. Systems Administrator
Inovis Inc.
