On May 25th, I published this post covering some scenarios on how to use Site Recovery Manager & Active Directory.  Michael White from VMware responded with some good info.  He had an awesome suggestion of using a script to cold clone a DC daily to use for testing.

Let’s take a look at some ways we can get this done:

To include Active Directory or not to include Active Directory, that is the question.

I’ve been reading a lot around VMware’s Site Recovery Manager and considerations surrounding Active Directory. Most of what you will read says ‘NEVER’ protect AD with SRM, only use native AD replication, especially since SRM & vCenter at your Recovery Site require AD to be running anyway.

But what if you have multiple domains for different uses? This is where the lines become blurred. Think about this for a second:

• One AD environment (single forest/domain, no trusts) where vCenter & SRM live, call it infrastructure AD
• A second AD environment (also single forest/domain, no trusts) for your application servers, call it application AD
• You have infrastructure AD at both sites, SRM & vCenter authenticate accordingly
• Protected site has application AD
• Recovery site has nothing

Now here is where I say ‘why wouldn’t you protect AD with SRM?’  In a true disaster, the protected site is gone, no AD exists anywhere, so using SRM to bring them up on the recovery site makes sense. Is my logic flawed?

However, if I had my application AD living at both sites, using native replication, I agree 100% in not including your Domain Controllers in your SRM Recovery Plan. This leads to my concern…

Testing vs Planned vs Unplanned

This post will cover testing only. I’ll write a follow-up covering planned & unplanned failovers later.

To me, the only way to really test your DR plan (in this instance, your SRM Recovery Plan) is to not have anything different between them.