Title: Message
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.

Reply via email to