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:
- Go to the command prompt window, type
ntdsutil
and press Enter.
- At the Ntdsutil prompt, type
files
The utility will display the File Maintenance category.
- 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).
Previous
<P>Even with Microsoft's support, we weren't able to fully restore an Active Directory (AD) server if the NICs were different than that of the server we restored to. Restoring to the same server or an identical server was a snap and followed the steps outlined in your article. But in a disaster, you usually wouldn't restore to identical hardware.</P>
<P>I restored from one server to a newer model that had different NICs. I almost had the machine running. One glitch was that I could set the Ethernet address and netmask, but when I opened the dialog box a second time, the system was set to DHCP. I changed the address and closed the box, and the address would remain changed until I rebooted the server. Rebooting reset the address again.</P>
<P>I tried restoring at home on another system and found that if the NIC cards aren't the same, the registry isn't updated and confusion results. I worked with a super Microsoft support person who concluded that no one is exactly sure what registry keys are affected when you do a system state restore. I would be interested to know whether someone has done a system state restore of an AD server from one vendor's server to another vendor's server. Did we just miss something, or is restoring Windows servers to dissimilar hardware a problem? </P>
Edward Cheadle October 30, 2002