If you lose your Active Directory, you lose everything: Your Windows domain will stop working shortly thereafter....
Having a tested plan to back up and restore Active Directory should be on the top of your business continuity list.
Unlike most other applications in your network, Active Directory is a distributed application. It's multiple-master, meaning that (by default) every domain controller has a full copy of the directory and the ability to modify it. (Note that some of what I'm saying in this tip is aimed at midsize networks. If your network is large and you have multiple domains or even multiple forests, all of the principles are still true, but the details are quite different.) Therefore, to keep your Active Directory safe, you need to back up any one of the domain controllers. If you want to be able to restore any controller, however, you'll have to back them all up.
Backing up Active Directory means capturing the System State, a collection of system-specific data that includes the Active Directory database and related log and transaction files, Registry, COM+ configuration information, boot files, the SYSVOL system volume, certificate information (if you're running certificate services) and a few other system files.
You can do this for free with utilities provided by Microsoft in Windows 2000, 2003 and 2008. Your backup tools will probably also be able to capture a System State. Backups prior to Windows 2008 were fairly small, but the size of the System State increased in Longhorn, so plan accordingly.
It's important to remember that just because you've got a way to capture a System State, that doesn't mean you can restore it. If you have a small domain and have co-located your domain controller on the same server with your backup software, you're going to have a very difficult time restoring the domain controller. The solution of using disk imaging software won't help you here either: Active Directory can't be backed up that way, unless you shut down every DC and leave them down before imaging. And don't even think about the shenanigans required to restore.
This means you need to sit back and ask yourself: How am I going to restore a domain controller? It's not the same as restoring any other application server. Generally, the nice thing about Active Directory is that if you're provisioned properly in the first place (with 2 or more AD domain controllers), then you don't need to restore a broken server -- you just need to replace it, and let AD automatically re-replicate the data over to the newly built server. Even in these days of green computing and power savings, I strongly recommend you consider this your "Plan A:" when an AD controller is lost, don't worry about backing up AD, just get the server back up and promote it to a domain controller once everything is stable.
The one exception is Flexible Single Master of Operation (FSMO) roles; these don't automatically failover to other AD servers. These roles have to be assigned to specific domain controllers by the administrator. Fortunately, FSMO roles normally aren't critical to minute-by-minute operation of a domain and can be off-line while you decide what to do about them separately for a few hours. For example, the Schema Master FSMO role is only used when you update your schema, something that may only happen a few times a year. On the other hand, the PDC emulator FSMO role is more critical, since it helps to ensure that any changes to passwords are immediately available across the domain.
The key point of this tip is to have you think about how to backup and restore Active Directory separately from other applications because of its multiple-master distributed database. Take some time out, figure out what you are going to do and, most importantly, test your plan by simulating a failed or unavailable AD domain controller and recovery according to your plan. When you're doing that, make good notes so when you're executing it at 3AM, you won't make expensive mistakes. Every plan will be different -- some of you may follow my Plan A above, while others will have a different strategy. In any case, you should know what your plan is before you have an outage.
About the author:
Joel Snyder is a senior partner at Opus One, an IT consulting firm specializing in security and messaging.
Send comments on this technical tip firstname.lastname@example.org.
Join our IT Knowledge Exchange discussion forum; please use the midmarket security tag.