If you've ever had to perform a recovery of a domain controller or of an entire Active Directory database, then you have no doubt discovered that restoring domain controllers is something of an art form. With Active Directory restorations, it is important that you understand how the restoration process works and that you are aware of the various caveats to the process.
Here are my top tips for successfully restoring the Active Directory database:
- Be sure that you know the difference between an authoritative restore and a non-authoritative restore, and that you know when to use each technique. An authoritative restore reverts the entire Active Directory to its previous state as it existed at the time that the backup was made.
A non-authoritative restore restores a single domain controller to its previous state, but then the Active Directory replication process brings that domain controller up to date. When you perform a non-authoritative restore, you revert a single domain controller to its state at the time of the backup. The Active Directory information from the remaining domain controllers is then used to bring the recently restored domain controller up to date.
- Back up at least two domain controllers. You should be backing up at least two of your domain controllers, but it is a fairly common practice for large organizations not to back up every domain controller. If a domain controller fails, but has not been backed up, you cannot use the backup of another domain controller to restore the failed domain controller.
- When designing a data backup strategy for your domain controllers, be sure to take into account that not all domain controllers are created equally. In Windows Server 2008, for example, you can optionally create Read Only Domain Controllers (RODCs). If you are planning on only backing up a limited number of domain controllers, then RODCs make a poor choice as a backup target, because they are not capable of replicating their Active Directory information to other domain controllers.
There are also five Flexible Single Master Operations (FSMO) Roles that are used by Active Directory. Some of these roles exist at the forest level, and others exist at the domain level. It is important that you know which domain controllers these roles have been assigned to because there are consequences to restoring these domain controllers.
For example, the Relative Identifier (RID) Master maintains a list of all of the objects within a domain. Restoring the RID master can sometimes result in Active Directory corruption (this is especially true of Windows 2000), so you should try to avoid restoring the Relative Identifier Master unless you are performing an authoritative Active Directory restoration.
The same can be said of the Schema Master. The Schema Master is responsible for maintaining the Active Directory schema. If you restore the Schema Master, you can end up with orphaned objects or attributes in the Active Directory. You should therefore try to avoid restoring the Schema Master unless you are performing an authoritative restoration.
- It is important for you to understand the difference between transferring and seizing Flexible Single Master Operations roles. Transferring an FSMO role involves manually assigning that role to another domain controller. You can only transfer a role while the server that is currently assigned the role is available and in a healthy state. For example, you would transfer the FSMO roles to another domain controller if you are planning on gracefully demoting the domain controller to member server status, or if you are planning on taking the domain controller offline for an extended period of time.
Transferring Flexible Single Master Operations roles is the preferred method for reassigning the FSMO roles to a different domain controller, but you can only transfer a role if the server that currently holds the role is available and healthy. In situations in which a role holder has failed catastrophically and there is no chance of recovering it server, you will have to seize the role. Seizing a role should generally be used as a last resort.
- Although not technically classified as an FSMO role, you need to be aware of the Global Catalog role. You also need to make sure you know which domain controllers have been designated as global catalogs.
A Global Catalog server contains a record of every object in the forest. Global catalog failures can have some interesting consequences. For example, many applications perform Active Directory searches over port 3268. These searches will fail if a global catalog server is not present. I have also seen situations in which a global catalog failure prevented all users except for the domain administrator from being able to log in. In other words, make sure that you are backing up at least one global catalog server.
In these types of situations, the best thing that you can do is to manually reinstall Microsoft Windows, and then join the server to the domain. Keep in mind that if you are using the same server name, then you will need to clean out the existing Active Directory records for the computer account (or reset the computer account) before you attempt to join the domain.
The last step in the procedure is to designate the server to act as a domain controller. After you do, then your remaining domain controllers will replicate the contents of the Active Directory database to your newly rebuilt domain controller.
About the author: Brien M. Posey, MCSE, has previously received Microsoft's MVP award for Exchange Server, Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. You can visit Brien's personal website at www.brienposey.com.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip was via the rating scale below. Do you know a helpful backup tip, timesaver or workaround? Email the editors to talk about writing for SearchDataBackup.com.