Sometimes a test failover needs to have external resources inside it so that applications work properly. Or sometimes to support authentication. I once knew a customer who put a domain controller on the network that the test failover was on, and once the test was successful he put it back on the production network. Lots of issues occurred. What we are going to talk about here is put a domain controller in a test failover safely.
While this article is about getting a domain controller into a test failover - I was asked about that recently - the fact is you can use the same or similar process for other things.
The most important thing is that stuff in the test failover should NEVER get into production.
- You need to create a distributed switch port group that is an isolated network and connected to all your servers. I call it TestNetwork. Here is what it looks like:
- Configure your DR orchestration tool - Cleondris in my case - to use that network during a test failover.
- Now you should have a script executed that does a number of things.
- Power off a domain controller (which should not be an issue if you have multiple)
- Clone the domain controller
- Power on the orginal domain controller.
- Change the network on the cloned DC to the TestNetwork.
- Power on the cloned DC.
- Now you will have a DC in your test failover.
- When the test failover is done, you should execute anohter script.
- Power off the cloned DC.
- Delete the cloned DC.
The deleting of the cloned DC is important. That is how you do not get test data into production. If you are lucky you can have both scripts executed as part of the test failover. But test carefully.
If you have questions or comments let me know.
BTW, you can use this link to see all my BCDR articles.
Michael
=== END ===
