Building a business case for Recovery Manager for Active Directory Forest Edition

Language 

 If your organization is not a tech company, there is a good likelihood that your Executive Leadership may not understand WHY they need to be concerned about system downtime.  If it doesn’t affect them or their customers, why should they spend money?  While Active Directory availability is a concern for those of a technical mindset, sometimes this does not make sense in the business world.  To help with this, we should change our vocabulary when speaking to those not so tech savvy and speak in their language.

Business Impact Analysis

It’s easy to analyze what you should have done AFTER an event has occurred.  It is the responsibility of Executive Management to identify WHAT you should do to keep the business running prior to an event occurring.  This is a useful exercise not just for Active Directory, but for everything that your business relies on to function.  Seeing that Active Directory is the primary authentication source in most organizations, this may be one of those items that needs to be brought up first in the event of a disaster (especially if you need it to authenticate to your other applications).

There are different worksheets you can fill out to help you prioritize what in your environment should be brought up first.  FEMA has provided a sample Business Impact Analysis Worksheet that you can use.  By filling this out you can prioritize the order of operations of what should be restored.  As an example, some organizations may consider SAP as missions critical, but if Active Directory is the primary authentication source for SAP, you would want to restore Active Directory prior to SAP so that you can authenticate into that application.

RTO and RPO

Recovery Time Objective (RTO) is the duration of time which a business process must be restored after an outage.  Recovery Point Objective (RPO) is the point in time in which you want to have the ability to revert back to.  Having a longer RPO usually has a higher costs with systems as there are higher storage costs.

After completing your business impact analysis your executives can then decide on what their RTO (Recovery Time Objective) and RPO (Recovery Point Objective) should be.  Having the financial impact thought of prior to an event occurring helps to prioritize what amount of loss is acceptable to the business.  Some industries may have a lower RTO than other organizations.  Some people think that by having one Domain Controller back up and running that their Active Directory is operational, however if they have an application hard coded to a specific Domain controller that dependency can affect the RTO of that application.

Sometimes you may not know at what point the environment went bad.  This is why it may be good to have a longer recovery point to be able to revert back to that specific point in time.  These situations need to be considered and a decision needs to be made prior to an incident occurring.

Testing

Just because you have established your RTO and RPO doesn’t mean anything unless you can test it.  It’s a good idea to test on a scheduled interval and with different people.  Using native tools we have seen some Active Directory Forests take weeks to do a full recovery, the value of the products from Quest is that we can shorten the RTO considerably as it is automated restoration of your entire forest.  If you are interested in testing this with our product, please contact your Account Executive and we can discuss how we can expedite your recovery times.

Download Free Trial

About the Author
Bryan.Patton
Bryan Patton is a Principal Strategic Systems Consultant with technical knowledge in the entire Quest portfolio. He started at Quest in January of 2002.