Interesting question from a customer who wants to have a completely isolated, but very "production-like" testing/integration environment for their apps. To do this, they need AD - not only schema but data, but want to isolate it from their production environment. I hadn't thought of it - seems like you could since a DC, and then break it off periodically. Does anyone have something they can point to to help with here?
I am going to keep this reply short as I am not an expert on the subject but we do do something similar to this in EMC IT when I was there a long time ago.
I believe you could do this with inter-Site repclition within AD. Sync then disable or fracture replication between multple sites in the forest.
I suspect our MS ninjas will have more to add then me.
Typically this requires that you take a DC that has the Global Catalog to it, break it off, isolate it on another network and have it take over all the FSMO roles (schema master, etc). Then it's ready fro test use.
Once this server or VM is changed like this, though, it can never be put back into production as is (duplicate SIDs, et al). You'd have to dcpromo it to remove AD, re-join it to the domain, then re-dcpromo it to make it a DC again.
If the original DC to be used is virtualized, it's easier just to make a clone of the VM and move the VM over to the test network to use. This leaves the original VM in place and can be used to make future VM clones.
My first question would be, is the entire environment virtual?
If so, maybe leveraging vCloud Director would be a good fit. VMs can be imported from vSphere into an isolated vApp environment. Additionally, as different versions of AD/Applications occur, they can be imported into different vApps, giving some rudamentary "versioning."
That's how I would have done it in my last position, had vCloud Director been around when we started...
You did say isolated right?
There are a couple of ways to make this happen...you "could" spin up a DC and ensure that it also holds a Global Catalog Role, wait for replication to occur, and then physically take it off of the network...and move it to another network...I wouldn't bring that DC back into production for an update....
The other way would be to spin up a new DC and perform a bulk export/import into the new domain with the data from the production domain, and make it a one-way thing.
Here's a link to do that from the MS site...
Hope this answers the question...
+ 1 on Lozano's point. DON'T EVEr mix production and Lab DCs you can harm yourself really quickly.
I used to do that with "good old" Lab Manager by importing (P2V / V2V) a couple of Domain Controllers ( basically the couple holding the FSMO roles) into the Lab Manager environment and by spinning them up in different "network bubbles" to have different test environments. Always keep them separated from the Production network.
If you are a purist you may need to do some cleanup of the DCs (removing othr DCs and so on) but 90% of the time they work good.
You can also take a single DC and then move all the FSMOs roles to that one: it is easier and doesn't force you to stop two DCs. There are some powershell script that can automate the cleaning and the FSMO movement.
We used to do this for DR testing in my last place, we used to use platespin to periodically copy one of the DC's that held some of the main FSMO roles. We would bring it up on the DR VMware environment where the DR network was ring fenced, we had a procedure for seizing FSMO roles the DC didn't have and for removing site links that obviously did not exist in the DR world and a few other things to get it up and running cleanly.
The same principal could be applied to a test environment, it seems Fabio was doing something similar with Lab Manager.
I will be the one guy who will say something different...
I did something like this is a former role. We actually broken out seperate child domains per regression/integration for products but with trust from production.
The question doesn't share enough detail on the schema or data required. If the schema needs to change based on versioning or they are doing integration testing against it with it being updated by out of cycle updates; then the VMware clone/copy method is best.
If it is more about the data and it is something that can be captured from the production and replication/mocked via AD command-sets. Then standing up for-purpose domains that can be snappped and cycled will be much easier long term.
vCloud Director would be a great tool for the latter use case.
I should also mention. We used lab manager for this and had at the time 12 seperate environments.
This is still in use today 2+ years later.