Repairing and Recovering AD

Editor's Note: Portions of this article were excerpted from Sean Daily's The Definitive Guide to Active Directory Troubleshooting (Realtimepublishers.com, 2001).

In "Practice Proactive AD Maintenance," August 2002, InstantDoc ID 25637, I looked at some Active Directory (AD) maintenance and disaster-prevention activities that you should regularly undertake. Now let's take a look at a topic you need to know about when everything else fails: AD repair and recovery.

Repairing AD with Ntdsutil
If you suspect—because of error messages, log entries, or application errors—that the AD replica on a domain controller (DC) is corrupted, you might consider using the Ntdsutil utility's Repair feature to repair the damage. However, I recommend that you use this method only as a last resort. If a valid backup is available, restoring the database, which I discuss later, should be your first course of action.

Repairing the directory database doesn't always achieve successful results. For example, if a database file is corrupted, using the Ntdsutil Repair feature might not restore all objects and attributes. In fact, in some cases, using the Repair feature could cause further data loss. Isolating a DC from the rest of the network before you attempt this kind of repair can prevent additional corruption to other DCs' AD replicas. After you ensure that all is well, you can reattach the DC to the network.

Figure 1, page 54, shows how to use Ntdsutil to repair the AD database. To perform a repair operation on the AD database file, follow these steps:

Restoring AD
When all else fails, you might find that restoring functionality to a Windows 2000 DC (or the entire AD network) requires that you restore AD from backup. Although the process of physically restoring the AD database on a Win2K DC from a backup isn't a logistically complex procedure, you need to consider some important logical and architectural factors before you perform any type of AD restore operation. On networks that have more than one Win2K DC, AD doesn't exist in only one location—an important factor to consider because it relates to the AD restore process. Ask yourself the following questions:

Answering these questions will help you determine which AD restore modes—nonauthoritative or authoritative—to use. (To read more about recovering AD, see the sidebar "AD Recovery Resources.")

Nonauthoritative restore. Most restore operations use the nonauthoritative restore mode. You typically perform a nonauthoritative restore when the problem is limited to the local Win2K DC and you believe that the AD replicas housed on other Win2K DCs are valid. During a nonauthoritative restore, any data that you restore (including AD objects) will retain its original update sequence number (USN). AD replication then uses this number to detect and propagate any changes to other DCs in the same domain.

Authoritative restore. Perform an authoritative restore when the other Win2K DCs contain invalid replicas or undesirable data. In this case, you manually designate the copy of the AD database that you want to restore. Designate only the local DC as authoritative (i.e., the master copy from which all other DCs seed their AD replicas). Authoritative restores modify the AD objects' USNs so that each object's USN is higher than those of any other AD database replicas; as a result, all the restored objects will be replicated to the other DCs' AD replicas.

You can use backup data from one DC to restore to only the same DC; you can't use a backup of one DC to restore another machine. However, if the DC system fails, you can restore the backup data to another computer that replaces the original DC. Keep this restriction in mind when you develop your backup strategy. To completely back up your environment, you need a backup of every DC in the network. In addition, you need to frequently back up the first DC that you installed in the forest root domain. This DC typically hosts unique forestwide roles and contains unique data essential to network operation.

If you're using Win2K's backup utility (ntbackup.exe) to perform a restore, you must meet the following additional conditions to successfully restore the system state (including AD). If you don't meet all these conditions, the restore operation will fail.

Performing Nonauthoritative Restores
If the AD replicas on DCs other than the DC you're restoring are intact and valid, you'll probably want to perform a nonauthoritative restore, which is a typical restore of the AD objects to the DC that originally contained them. Although you can back up AD either online (while the directory service is running) or offline (when the services are stopped), you can restore AD only when the directory services are offline.

To restore AD, start the Win2K DC in a special startup mode called Directory Services Restore Mode. Select this mode at system startup by pressing F8 when the Win2K Boot Loader menu appears, then selecting the option from the alternative boot menu. Win2K will start in Safe Mode, and you can use the following steps to restore AD information on a DC:

The DC will now participate in AD replication and will receive directory updates from the other DCs. After the completion of the nonauthoritative restore, the restored data (which might be out of date) is synchronized.

Use the nonauthoritative restore if the DC fails or the entire AD database is corrupted. A nonauthoritative restore will maintain its original USN. (AD uses this number to detect and propagate the most recent changes to other DCs.)

To minimize replication traffic on the network, the nonauthoritative restore provides a start point (the point at which backup began) for data replication—only changed data (rather than the entire directory) is replicated. Without this start point, all data from other servers would be replicated. Simply reinstalling Win2K and reconfiguring the system as a DC (through dcpromo.exe) is another option for restoring AD on a Win2K DC. The AD-replication process will automatically repopulate the DC with current directory information.

Performing Authoritative Restores
An authoritative restore lets you recover a DC, restore it to a specific point in time, and mark AD objects as authoritative with respect to their replication partners. For example, you might need to perform an authoritative restore if an administrator inadvertently deletes an OU that contains many users. You can use the authoritative restore process to recover the AD information and mark it as the definitive source for replication to the other DCs in the domain.

The authoritative restore modifies the USN of the AD objects that you're restoring to the DC so that each object has the highest value of any AD replica on any DC in the domain. This, in turn, forces replication of the newly restored objects to the other replicas residing on all other DCs.

Authoritative restores are unusual; they can roll back all the AD objects in the DC to the point in time when you performed the original backup. You can use this action to restore information that was erroneously deleted from a replicated data set. For example, if you inadvertently delete or modify objects stored in AD, you can authoritatively restore those objects so that you can replicate them again to the other DCs. If you don't authoritatively restore the missing objects, they'll never get replicated to the other DCs in the same domain because the missing or deleted objects you're restoring appear to be older than the objects currently on your DC.

To mark the target objects for authoritative restore, you can use the Ntdsutil utility, which ensures that the data you want to restore is replicated to the appropriate DCs after the restoration. Table 1 lists and describes the authoritative Ntdsutil restore commands.

By definition, an authoritative restore replicates any changes you made to the current data set to its outbound replication partners. Use the following steps to perform an authoritative restore of AD on a specific DC:

Always authoritatively restore the Sysvol folder whenever you authoritatively restore AD. This process ensures that Sysvol and AD remain synchronized. Also, be aware that authoritative restores have several potentially negative consequences.

One such effect relates to trust relationships and computer account passwords, which are automatically negotiated at a specific interval (every 7 days by default, except for computer accounts that administrators can disable). During an authoritative restore, you can restore a previously used password for the AD objects that maintain trust relationships and computer accounts. For trust relationships, this action could void communication with DCs from other domains. For computer account passwords, it could void communications between the member workstation or server and a DC.

In this article, I've attempted to cover some of the more important maintenance activities related to AD upkeep and give you information about how to repair and restore AD when things go awry. Following these recommendations can help ensure that your network stays healthy and available, that your users are productive, and that the boss stays off your back.