Copying Active Directory for a lab

[yojimbo]

Hi,

I’m setting up a lab to test our new exchange disaster recovery process.

To do this I need a copy of the real AD infrastructure from our DC and GC. I’m starting to look at ways of copying our AD to another domain with damaging our real systems in any way.

I’m looking at MS’s Active Directory Migration Tool first but will look at other 3rd party ways as well if needed.

Has anyone done this before? Are there better ways of doing this or better tools you know of

Thanks

[PuddingCat]

I’d suggest that you build a domain controller in your production domain and turn it off once it’s synched.

Then do a metadata cleanup in production to remove the DC you just built. Turn on the new DC in an isolated network environment and sieze the FSMO roles to this machine. Make sure you have DNS working on it then use it as a master to promote a whole load of new test DCs.

You’ll have an identical config to production and your prod network won’t be affected.

cheers,
tim

[yojimbo]

@trmatthe

I’d suggest that you build a domain controller in your production domain and turn it off once it’s synched.

Then do a metadata cleanup in production to remove the DC you just built. Turn on the new DC in an isolated network environment and sieze the FSMO roles to this machine. Make sure you have DNS working on it then use it as a master to promote a whole load of new test DCs.

You’ll have an identical config to production and your prod network won’t be affected.

cheers,
tim

That’s actually what I’ve just been discussing. It’s a posibility. IT projects being what they are however there’s already a good chance of scope creep.

The other thing we are looking at is. Recoverying our legato server into the test domain and then using that to recover the DC and GC on it. So instead of just disaster recovering our exchange system we’ll also be doing legato and DC+GC. Now I just have to wait for the servers to be delivered and bring a spare jukebox up from the basement.

Thanks for the reply.

[ishamael69]

We’re in the process of doing the same thing. Well, not testing exchange, but building a test environment with AD.

We happen to have a domain controller running on our production VMWare Server, and we just shut it down for 15 minutes, made a copy, and fired it back up. That gives us a copy that we can disconnect from the domain and do whatever with. Very easy to do, plus no cleanup or damage to the domain, since the production box just keeps running.

[yojimbo]

@ishamael69

We’re in the process of doing the same thing. Well, not testing exchange, but building a test environment with AD.

We happen to have a domain controller running on our production VMWare Server, and we just shut it down for 15 minutes, made a copy, and fired it back up. That gives us a copy that we can disconnect from the domain and do whatever with. Very easy to do, plus no cleanup or damage to the domain, since the production box just keeps running.

That would be the way to go apart from the fact that the director what’s a physical recovery process tested and as that is what will be required IRL if something happens to the site with our main exchange server in it.

[Bricker]

@ishamael69

We’re in the process of doing the same thing. Well, not testing exchange, but building a test environment with AD.

We happen to have a domain controller running on our production VMWare Server, and we just shut it down for 15 minutes, made a copy, and fired it back up. That gives us a copy that we can disconnect from the domain and do whatever with. Very easy to do, plus no cleanup or damage to the domain, since the production box just keeps running.

You still have to follow the steps outlined by trmatthe – the copy of the DC in the new environment won’t be able to see any of the other DCs, so you’ll have replication failures. It also won’t necessarily have all five FSMO roles, so you’ll have to use ntdsutil to seize those roles and clean up any references to DCs that no longer “exist” in the new environment.

[ishamael69]

@Bricker

You still have to follow the steps outlined by trmatthe – the copy of the DC in the new environment won’t be able to see any of the other DCs, so you’ll have replication failures. It also won’t necessarily have all five FSMO roles, so you’ll have to use ntdsutil to seize those roles and clean up any references to DCs that no longer “exist” in the new environment.

True, but it doesn’t involve any cleanup on the production AD site, which is something we were looking for. Most of the time, we’re just using the DC to test, so replication errors and such are not a priority.

For instance, today I’m testing an upgrade to our ERP system. This really doesn’t HAVE to have AD to function correctly, but I thought it would be more accurate. Once I’m finished testing the upgrade, I’ll just throw the VMs I use away.

[PuddingCat]

@ishamael69

True, but it doesn’t involve any cleanup on the production AD site, which is something we were looking for. Most of the time, we’re just using the DC to test, so replication errors and such are not a priority…

What I’m quoting to you is considered best practise, certainly amongst the Premier Field Engineer wizards I hang out with. Anything else and you risk not having a proper DR simulation. Out of interest how many DCs do you run? A metadata cleanup isn’t normally considered an extraordinary situation in my experience. You’re just prematurely tombstoning some objects

@ishamael69

For instance, today I’m testing an upgrade to our ERP system. This really doesn’t HAVE to have AD to function correctly, but I thought it would be more accurate.

In a relatively large scale AD I’m not sure how you can run a proper integration test without having your AD present. Doesn’t your ERP have any domain ties?

As for VMs, I always get a nasty feeling in the pit of my stomach when talking about DCs, and not just due to the Microsoft ‘supportability’ requirements. Even with a well managed ESX test/dev/pre-prod environment we’ve still had DC rollbacks :smack:

tim