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.

How to use Ntdsutil to repair the AD database. To perform a repair operation on the AD database file, follow these steps:

  1. Go to the command prompt window, type 
ntdsutil

and press Enter.

  1. At the Ntdsutil prompt, type 
files

The utility will display the File Maintenance category.

  1. At the File Maintenance prompt, type 
repair

 

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:

  • Is only the local DC's copy of AD corrupted or damaged, or are other replicas on other DCs also in the same state?
  • Is the data I'm restoring the definitive copy I should use to overwrite all other copies of AD object data? If so, do I risk losing changes or structural modifications (e.g., added or deleted organizational units—OUs, modifications to user or computer objects) by restoring this copy of AD as a master copy?
  • Should I restore AD on a local DC only to regain functionality on that DC (i.e., is the corruption, damage, or other type of problem isolated to the local copy of AD on that computer), which should then receive updates from other DCs that use AD replication to bring its data store up-to-date?

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.

  • The server name must be identical to the backed-up server's name.
  • The drive letter on which the \%systemroot% folder resides must be the same letter it was when you performed the backup.
  • The \%systemroot% folder must be in the same location as it was when you originally backed it up (e.g., in the C:\winnt directory).

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:

  1. Log on as a member of the Administrator or Backup Operator group.
  2. Run the Win2K backup program and select the Restore Wizard option from the Welcome tab. Choose File, Backup, then select the System State check box. System State data includes the registry, AD, and other key system components.
  3. If you restore the System State data and don't designate an alternative location for it, the utility erases the System State data that's currently on your computer and replaces it with the System State data you're restoring. The AD, Certificate Services database, and COM+ Class Registration databases won't be restored if you designate an alternative location.
  4. After you finish the restore, restart the 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:

  1. Open a command prompt window (select Start, Run, type 
cmd

then press Enter).

  1. Type 
ntdsutil

and press Enter.

  1. At the Ntdsutil prompt, type 
authoritative restore

and press Enter. This action puts Ntdsutil into Authoritative Restore mode.

  1. At the Authoritative Restore prompt, type 
restore database

to set the entire database as authoritative. Alternatively, you can set only a subtree of the database (for example, an individual OU); doing so requires that you use the Lightweight Directory Access Protocol (LDAP) string that identifies the AD portion that you're authoritatively restoring. For example, to authoritatively restore an OU called Engineering in the mycompany.com domain, type the following command at the Authoritative Restore prompt: 

restore subtree ou=engineering,dc=mycompany,dc=com
  1. When the system prompts you to confirm the authoritative restore you specified in Step 4, answer Yes.
  2. Click Quit, then press Enter twice to return to the command prompt.
  3. Close the command prompt session.
  4. After the AD restore operation is complete, answer No to the option to restart the server. This step is crucial; otherwise, the restore will be nonauthoritative when the server restarts, and you'll risk reinheriting unwanted data from other AD replicas.

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.

Table 1

TABLE 1: Ntdsutil Authorative Restore Commands

Command

Description

Authoritative restore

Lets you use the authoritative restore submenu options listed below. Run this option only on a DC that operates in Directory Services Restore Mode.

Restore database

Submenu option that marks the entire AD database (ntds.dit) as authoritative.

Restore database verinc %d

Submenu option that marks the entire AD database (ntds.dit) as authoritative and increments the version number by %d. Use this option only to authoritatively restore a previous sequential authoritative restore.

Restore subtree %s

Submenu option that marks a subtree (all objects in subtree) as authoritative. Use the Fully Distinguished Name (FDN) of the OU object to define the subtree.

Restore subtree %s verinc %d

Submenu option that marks a subtree (all objects in subtree) as authoritative and increments the version number by %d. Use the FDN of the OU object to define the subtree. Use this option only to authoritatively restore from a backup that contains the objects you want to replace.