Best practice for testing DR using SRM and bringing AD Domain Controllers up in test enviornment

[yorkshireit]

I hope someone can help with this....

12 months ago we had consultants in to help configure SRM and automate failover into DR if/when required. My question relates to testing DR and how domain controllers are best configured to be able to provide services to application servers,etc when testing in our DR test network.

Currently, we have been told to bring up the DC in test only after reverting to the latest VMware snapshot due to 'USN issues'. After this, we can then fire up the rest of the servers. Is this best practice? It doesn't seem that 'automated' to me and am wanting further advice from others on this. The tests we do always seem unreliable at best, therefore my post on here.

For reference, we have 2 sites. One production with all our DC's, app servers, Vcenter and SRM server. The DR site has a DC, Vcenter and SRM server.

We have had another third party look over the setup and they have questioned certain practices with the above, such as the way we have to revert to a DC snapshot. Also, is SRM sensitive to differences in versions of VMware tools? We had 1 or 2 servers with version differences. Could this upset any testing we do?

Many thanks for any help you give.

[jhague]

‌Is your test network isolated from Production? Are the servers destroyed after the test?

As far as I know USN issues would only come into play if there is connectivity with other domain controllers which are out of sync I.e. inconsistent in terms of date/time.

Probably depends on your testing scenario...

VMware Tools is used for things like heartbeats and IP address changes from an SRM perspective - it's good practice to keep it up to date and makes things easier from a troubleshooting / consistency perspective.