The nature of Active Directory directory service - details about how it works, and about the singular Flexible Single Master Operations (FSMO) roles that are attached to specific Active Directory servers - demands special treatment in the Backup, Restore and Recovery (BRR) plan. For all other servers in the solution, you should restore from a complete backup image. This process restores the entire system state and all hard disk content. On an Active Directory domain controller, this system state includes the FSMO roles and associated data. There are several potential issues when you restore this way:

1. Restoration of a relative identifier (RID) master can result in corruption of the Active Directory database.
   
2. Restoration of the schema master (SID) can result in orphaned objects.
   
3. The Hosting infrastructure recommends distributing the FSMO roles of RID and schema master on different domain controllers.
   
4. Active Directory replication will automatically distribute all needed data to a new domain controller when it is brought into the domain.
   

Therefore, as long as there is a working domain controller in the infrastructure, you should recover from an Active Directory domain controller failure by building a new domain controller, joining it to the existing domain, and allowing Active Directory replication to update it to the current state.

The only time you should use domain controller backup images is when the failure has resulted in loss of all the domain controllers in the infrastructure or if one or more objects have been deleted from Active Directory by accident and need to be authoritatively restored.

Along with this process, it is critical to understand that the domain controllers in the infrastructure must be completely backed up on a regular schedule. Even if you use these backup images only for testing and disaster recovery drills, should the ultimate catastrophe occur where all domain controllers are lost, there will be no recovery possible without them.

The recovery process recommended here takes one of two paths, based on whether or not a working domain controller is available. If a working domain controller continues to function, the recommended procedure is to seize any FSMO roles that the failed server had been supporting onto the working domain controller, rebuild the failed server from scratch, and allow replication to bring it up to date rather than using a backup of the failed server. Only if there is no functioning domain controller in the solution should the recovery process use the backup image.

To restore a server when you have a working domain controller, take the following actions:

Seize all FSMO roles

Seize those that the failed server had been providing on the working domain controller. If there is more than one working domain controller, seize them on a domain controller that is in the same site as the target domain controller.

The details for role seizing are unique to the role, and can be found in the Windows Server 2003 online Help. Perform this action carefully - it may be that these roles have automatically been taken over by other domain controllers in the hierarchy. Role seizure is only performed if the target domain controller to be recovered was supporting FSMO roles that have not been taken over by other domain controllers in the infrastructure.

Rebuild the failed domain controller

Rebuild per the original server build process. However, a new computer name should be used because remnants of the original domain controller may still exist in Active Directory.

Redeploy the FSMO roles

For more information, see Using Ntdsutil.exe to seize or transfer FSMO roles to a domain controller

If for some reason this process fails, you have two choices:

• Completely recover the Active Directory infrastructure, as if there were no working domain controller. This option is not recommended.
  
• Implement a careful and custom restoration process. This process is beyond the scope of this guide. You may consider employing Microsoft Consulting Services to assist you with this task.
  

In a catastrophic event where all domain controllers in the solution are lost, and the only backup of the Active Directory data is in the backup images, the restore process must restore each failed server in turn. This process must be performed with recent backups for all domain controllers in the solution. It will recover the Windows Server 2003 Server operating system configuration; Active Directory, including database and registry settings; and the File Replication Service.

The restoration of a domain controller can be performed in one of two ways: Non-authoritative and Authoritative.

Non-authoritative restore

Is the default Active Directory restoration method, and is the one that Windows Server 2003 Backup tool will perform. Basically it restores the target server to the exact state captured in the backup image. In particular, it will make no changes to internal version numbers that are used by Active Directory to track all changes to the database and to support replication. What this means is that any objects that exist in the Active Directory infrastructure with more recent version numbers will eventually update the restored server.

For more information about this tool, see the Backup Technical Reference.

Authoritative restore

Takes the restoration process one step further. It has the ability to increment the version number of the attributes of all objects in the entire directory. This in effect makes the associated data authoritative in the Active Directory infrastructure - replication will in general update any other existing domain controllers from the restored computer's database. Note that the only tool that supports authoritative restoration is the Ntdsutil tool - neither the Windows Server 2003 Backup tool nor third-party tools will perform this type of restore.

This capability was created to assist in the restoration of the database to a known good copy. In other words, it allows an administrator to compensate for human error such as accidental deletion of objects among other potential events.