When Microsoft introduced Active Directory (AD) with Windows 2000, it was a huge step forward compared to the aged NT 4.0 domain model. AD has since evolved even more and emerged as almost the de-facto standard for corporate directory services.
Today, if an organization is running a Windows Server based infrastructure, then they are almost certainly running AD. There are still some organizations that have NT 4.0 DCs, though that is quickly changing.
AD is often used as THE authentication database even for non-Windows-based systems because of its stability and flexibility. There are many network-based applications relying on AD without its users being aware of it. For example, an HR application can use AD as a directory for personnel information such as name, phone number, email address, location in the company, and even the computer of the user. Yet the HR personnel may not be aware that the same information directory is used to fetch all the information for the global address book in the email system, and to authenticate the user when he or she logs on to his or her workstation.
Due to the strong integration between applications and AD, an event that could cause an outage could have quite a huge impact on systems, from sales to human resources, all the way to payroll and even logistics in manufacturing companies.
In most cases where AD is used for more than just authentication, it quickly becomes the IT infrastructures' lifeline, which, if interrupted or stopped, causes chain reactions of failures that can bring a company to a halt, and stop production, communications, and delivery of goods.
Of course, once you have an AD running, a logical step is to have Exchange as your email and collaboration system. If you have both systems, then you know how critical AD is for Exchange. Without an AD, the email and collaboration systems will not function. For many companies, being without email functionality for even a day can be catastrophic. If email is your main method of communication within the organization, then picture having your preferred method of communicating taken away for an entire day (or more) within your entire organization. This applies to receiving as well as sending, and access to your mailbox and related functions.
As you might have noted by now, a proper Disaster Recovery (DR) plan is a necessity, and a proper DR is just as critical. You need to cut the possible downtime of your mission-critical systems to a minimum.
Disaster Recovery (DR) is, or should be part of your Business Continuity plan. It is defined as the way of recovering from a disturbance to, or a destructive incident in, your daily operations. In the context of Information Systems and Technology, this means that if an incident completely destroys data, slows down productivity, or causes any other major interruptions of your operations or your business, the process of reverting to normal operations with minimum outage from that incident is called Business Continuity. Disaster Recovery is, or should be, a part of that process.
You could say that Business Continuity and Disaster Recovery go hand in hand, but they do vary depending on the area and subject. For example, if your WAN connection goes offline, it means that your business units can no longer communicate via email or share documents with each other, although each local unit can still operate and continue to work. This scenario would definitely be outlined in your Business Continuity Plan. However, if your server room burns down in one location, the rebuilding of the server room and the data housed in it would be Disaster Recovery.
The problem with Disaster Recovery is that the approach varies for different domains and applications. Also, the urgency and criticality vary across areas and subjects. A lot of companies have a very superficial Business Continuity plan, if they have any plan at all, and have Disaster Recovery plans that are just as superficial. A visual outline of a sample Business Continuity plan is shown below:
As you can see, DR is only a part of the greater picture. It is, however, one of the most crucial parts that many IT departments forget, or decide to overlook. Some even seem to think that DR is not an important step at all.