I guess I should have called this how to be successful with BCDR. I have heard of people saying DR orchestration tools just works. It doesn’t quite mind you. It is a BCDR tool so it is only – at best – 15% of a BCDR project. The rest is the investigation and learning you need to do to make it possible to have a successful BCDR project. So you investigate, search, discuss, talk, decide and then you have the info you need to start making VAO useful. We are going to look at what you need to think about and look into to be successful at the at the investigation and research.
The Business Impact Assessment (BIA) is the quick way to making a DR orchestration tool work successfully due to the fact it contains so much useful information. But not everyone will have a BIA or time or money to do one. But if you have one, make sure it is current, and it will have all of the info to make your tool work real good!
So you do it manual – which I call an application catalog.
You need to fill in the form below.
short form, Name of app, business contact, technical contact, data, comments, components of the app, misc info, RTO, importance
Exchange, v2016. www.microsoft.com, AppOwner – John Smith, Lead Support – Jane Doe, 24 VMs, requires – AD / DNS / DHCP, 1 desktop, minimum of 8 of the VMs, and DC with global catalog role, Barracuda Anti-Spam appliance, physical requirements – Barracuda Anti-Spam appliance. Miscellaneous notes – spare Barracuda appliance on DR site, and virtual is possible. RTO – 2 hours. Importance – 1.
Sometimes you can work with the Help Desk – if you have one, as it often has a basic form of this kind of doc, and you can improve it. The components is the hard part, often it is Active Directory for credentials, DNS for directory services, but it can be things like database servers, or anti spam appliances for example.
Now you have an application catalog, you need to talk to your management to understand the priority of each app. Hopefully you will select email to be the first recovered.
The important apps should be packaged on their own – Email, SharePoint, Accts Payable, Accts Rec, SQL for example. The less important apps can be bundled together and protected together. But often in DR the outage is only partial so you may only fail over email for example and so packaging with that granularity is important.
Now that you have an application catalog you can start using the info in it to do your DR tool build-out of plans and start doing your test failover.
If you got all your info right in the catalog, you should have successful test failover. But if you don’t check out the info in the execution report and it will likely have what you need to modify and try again.
I like to document my recovery plan using info from the application catalog so I am ready to work in my DR tool, but have handy what is necessary. Here is an example.
I hope this information gives you some help and guidance so when you sit down with VAO you are going to be more quickly successful with it.
I would add to this the fact that an executive sponsor is important to have on your team. As things get complicated between application and infrastructure and network teams, that sponsor can sometimes make things go very smoothly. And starting with a simple app is important (to learn), and sometime the executive sponsor can make sure no one gets excited about that.
BTW, using DR Tools is not hard. But it is hard knowing all the info you need to know to be successful with it. So that is what I am trying to help with in this article.
Let me know if you have questions or comments.
- 5/2/20 – made it about DR orchestration tools rather than VAO.
- 2/6/19 – add the bit on executive sponsor.
=== END ===