- Active Directory Emergency Recovery
Similar to the system registry, which is often referred to as the "heart and soul" of any
local computer running Windows NT, Windows 2000, Windows XP, or Windows Server
2003, Active Directory is the "heart and soul" of a corporate Windows-based network.
This essential network component must be available to applications and users at all times.
There are other similarities between the system registry and the AD, but this is the most
important one. In contrast to the registry, which is a local configuration database, AD is a
replicated database, and as such, it is vulnerable to the same problems that can damage
any distributed database, including:
A corrupted or invalid database schema (defines the structure of the database —
what type of data it contains and how that data is arranged)
Missing DNS records
Damaged or corrupted information
Human errors, including accidental errors of the system administrator
Consequently, if you have implemented AD domains in your organization, it is
imperative that you develop disaster-prevention and disaster-recovery procedures for
your AD infrastructure.
Physical AD Structure
As previously mentioned in this chapter, the Active Directory information, which now
replaces the SAM registry hive, is physically stored as an on-disk database. The actual
database file is called Ntds.dit, and by default, it resides under %SystemRoot%\ntds
Note On Windows 2000 Server or Windows Server 2003, a pristine copy of the AD
database is stored in the %SystemRoot%\system32\ntds.dit file. This copy is used
when a member server is promoted to a domain controller using the DCPromo
In Chapter 1, I introduced mechanisms implemented by Microsoft to ensure that changes
to the system registry are consistently and successfully written and are not easily
corrupted by system crashes or hard-disk problems. Since AD is a centralized registry
storing all user- and computer-related information for an entire organization, it would be
logical to expect that similar mechanisms are implemented for the Ntds.dit database. The
Ntds.dit is a database file that uses Microsoft's Extensible Storage Engine (ESE)
technology, also known as Jet. All changes to AD are transactional, which means that
each discrete change is committed to the database individually. For example, if a system
- administrator resets the password for one AD user, the administrator would be making a
single, discrete transaction.
To ensure that all database transactions occur consistently, AD implements a circular log.
When a change is made to the AD database, it is written first to the copy of AD running
in memory on the domain controller on which the change was made. The change is also
written to a change log file stored on disk. If you look in the directory where the Ntds.dit
file is stored on a given domain controller (Fig. 11.1), you'll see several files in addition
to the database file:
Figure 11.1: The contents of the %SystemRoot%\ntds folder on a given domain controller
Three log files — Edb.log (the main log file for the AD database), Res1.log, and
Res2.log. Each log file is roughly 10 MB. Res1.log and Res2.log files serve as
reserves in case the disk partition that stores these log files runs out of disk space.
If this happens, reserve log files ensure that there is enough space on the disk to
write any uncommitted transactions to the database before shutting down the
Transaction checkpoint file — Edb.chk. This file keeps track of the last transaction
successfully committed to the Ntds.dit file. If the domain controller crashes before
all in-memory changes are committed to the Ntds.dit file, the checkpoint file
would allow a quick and easy replay of any transactions in the log that hadn't been
committed before the crash.
Note The checkpoint file isn't required for AD to recover itself after a crash. But
recovering without it takes much longer because the system must scan the entire
transaction log to determine which changes were committed to the database file.
When designing and implementing AD infrastructure, it is essential to take into account
performance, fault tolerance and disaster recovery. While promoting a member server
into a domain controller using the DCPromo utility, you're given the choice of where you
want to store the Ntds.dit file (the AD database), the SYSVOL directory (a required
shared directory that exists on domain controllers), and the AD log files. Note that there
are lots of recommendations for choosing the right configuration for servers that you plan
to promote to AD domain controllers. In general, the ideal configuration of a domain
controller must have several physical disks. Most authors, including those of Microsoft's
- official documentation, recommend the following disk configuration for an AD domain
One physical disk for the operating system files and page files
One physical disk for the Ntds.dit database file, which tends to grow significantly
One physical disk for AD log files
At a minimum, try to ensure that the system page file and AD log files are on separate
disk spindles; both typically see the largest disk activity when a domain controller is in
Backing Up Active Directory
Since all the files comprising AD (including Ntds.dit) are continually in use on Windows
2000 and Windows Server 2003 domain controllers, you can't simply copy the AD
database to the backup media as you would with any standard user data file (Fig. 11.2).
Note that in this respect, the AD database behaves similarly to the SAM registry hive.
(This was shown in Chapter 9.)
Figure 11.2: During an attempt to copy the AD database of the running Windows 2000 or
Windows Server 2003 domain controller, the system displays this error message
As explained in Chapter 2, the built-in Backup utility enables you to perform an online
backup of Active Directory. A backup of AD is performed whenever you include System
State data as part of a backup on a Windows 2000 or Windows Server 2003 domain
Note Although the built-in Backup utility supplied with Windows 2000 Server and
Windows Server 2003 can perform an online backup of the Active Directory
database, some organizations may prefer to use more robust third-party
applications. If you want a third-party backup solution, chose a product compatible
with your OS (Windows 2000 or Windows Server 2003). The product must be able
to backup Active Directory or provide a separate addon component capable of
performing this task. Note that legacy versions of backup products cannot
understand the AD format and are unable to back it up. Several leading
manufacturers in the field of Windows Servers backup and recovery already supply
the products supporting Windows Server 2003. For example, VERITAS
- (http://www.veritas.com) has released the BackupExec 9.0 for Windows Servers,
which includes support for Windows 2000 and Windows Server 2003.
Restoring Active Directory
Physically restoring the Active Directory database on the domain controller from a
backup is a straightforward procedure. However, there are some important issues that
need to be taken into account when performing any AD restore operation, including:
On networks with more than one domain controller, the AD database is
automatically replicated and updated among domain controllers. Therefore, the
AD database exists in several locations.
You can perform AD backup only in its entirety, using a full backup. It is
impossible perform an incremental backup of AD.
For example, if you decide to restore the AD database from the backup, you will need to
make the following decisions:
Do you need to restore AD on a local domain controller only? If the problem is
limited to the local domain controller, and if other domain controllers contain
valid replicas of the AD database, you can perform a non-authoritative restore.
After you regain functionality on the failed domain controller, it will receive
updates from other domain controllers using AD replication to bring its data store
Have other domain controllers also failed, or do you think their AD replicas may
contain invalid or undesirable data? In either situation, you'll need to perform
authoritative restore. To do so, you must manually designate the copy of the AD
database that you want to restore. The local domain controller will be
authoritative, and the "master" copy of the AD database from this domain
controller will be replicated to other domain controllers.
Performing a Non-Authoritative Restore
It makes sense to perform non-authoritative restore if only the local domain controller has
failed; other domain controllers on your network should be up and running, and AD
replicas on those domain controllers should be intact and valid. In this case, you will have
Simply reinstall the OS (Windows 2000 Server or Windows Server 2003), join the
newly installed server to a domain, and promote it to a domain controller. The
normal AD replication process will then repopulate the domain controller with
current directory information.
- Start the failed domain controller in Directory Services Restore Mode, and then
restore the AD database from the backup copy.
To use the second approach:
1. Start the failed domain controller and press at the Boot Loader menu.
2. When the Windows Advanced Options Menu appears, select the Directory
Services Restore Mode (Windows domain controllers only) option.
3. Once you select Directory Services Restore Mode, Windows will start in a safe
mode and ask you to log on. Log on as a member of the Administrators group.
Note The processes that take place when any Windows NT-based operating
system (including Windows 2000, Windows XP, and Windows Server 2003)
is starting up, as well as the Boot Loader menu and the Windows Advanced
Options Menu, were covered in detail in Chapter 6.
4. After successful logon, run your backup application and use the option to restore
AD. For example, using the built-in Backup utility, you must select the backup
media and then set the System State checkbox (Fig. 11.3).
Figure 11.3: Restoring Active Directory as part of the System State data restore
Note If you restore System State data to restore AD and don't designate an
alternate location for the restored data, you'll overwrite all System State data
in the current installation with that from the backup.
5. Having set the required restore options, click the Start Restore button. Once the
restore procedure is accomplished, Backup will display a dialog prompting you to
restart the domain controller. Click Yes.
- Once the restored domain controller restarts, it should begin participating in AD
replication and receiving directory updates from the other domain controllers.
Performing an Authoritative Restore
Authoritative restore is required when other domain controllers fail or if their replicas of
the AD database contain corrupted or invalid data. In either case:
1. Manually designate the copy of the AD database that you restore.
2. Perform an authoritative restore of AD. This is similar to performing a non-
authoritative restore except that it requires an extra step after the restore operation
(using either the built-in Backup utility or a third-party tool) is complete.
Therefore, proceed as though performing a non-authoritative restore, until the last
step of this procedure — answer No, when prompted to restart the server.
Note This step is critical; without it, the restore will be non-authoritative when the
server restarts. Thus, if other domain controllers contain undesirable data,
you will reinherit it from other AD replicas.
3. After performing the AD restoration, you will need to tag the restored copy of the
AD database as an authoritative copy. To do so, open a Command Prompt
window and issue the following command: ntdsutil.
4. At the ntdsutil: prompt, type authoritative restore and press . This puts
ntdsutil into Authoritative Restore mode.
5. At the authoritative restore: prompt, type restore database to set the entire database
you just restored as authoritative. Alternately, you can tag as authoritative any
subtree of the restored AD database (for example, an individual organizational
unit). To do so, type in the LDAP (Lightweight Directory Access Protocol) string
identifying the portion of AD being authoritatively restored, for example: restore
subtree OU=managers, DC=Alist, DC=com
6. Answer Yes when prompted to confirm authoritative restore.
7. Select the Quit option, then press twice to exit back to a command
8. Close the Command Prompt session, then restart the computer.
When the system restarts, all other domain controllers in this domain will designate the
AD database (or a portion of it) as the authoritative "master" copy and use it to reinitiate
the contents of their own AD replicas.
Note When you perform an authoritative restore of AD, you'll lose any object and schema
configuration data created after the AD backup was created (or in the branch of AD
being authoritatively restored).
- Resetting the Recovery Console Administrator Password on a Domain Controller
When you promote your computer running Windows 2000 Server or Windows Server
2003 to a domain controller, you enter a Directory Service Restore Mode Administrator
password, which is used by the Recovery Console. This password is required to login to
Directory Services Restore Mode; without it, you will be unable to perform the AD
restore procedures. This password is separate from the Administrator password stored in
Active Directory. As previously noted in this chapter, the Directory Service Restore
Mode Administrator password is stored in the local SAM registry hive
To reset this password:
1. Shut down and restart the domain controller.
2. When the Boot Loader screen appears, press to open the Advanced
Windows Options Menu.
3. Select the Directory Service Restore Mode option and log on as Administrator or
as a member of the local Administrators group. (Notice that you already need the
4. Use the Local User and Groups MMC snap-in or issue the following command
from the command prompt: net user Administrator *.
5. Shut down and restart.
Note As previously mentioned, if you have forgotten the password, you will not be able
to login. Consequently, you will not be able to use the Directory Service Restore
Mode to perform the AD restore operation or to reset the Directory Service Restore
Mode Administrator password. However, if you remember (or guess) the original
Administrator password used when Windows 2000 Server or Windows Server 2003
was installed, you can resolve this situation by following these steps:
1. Perform an alternate installation of Windows 2000/XP or Windows Server 2003 to
a different drive. During installation, specify a new computer name.
2. Access the files of the Windows installation for which you need to reset the
password, and replace the %SystemRoot%\System32\Config\SAM registry hive
with the SAM registry hive created during the original installation (this will be the
%SystemRoot% Repair\SAM file).
If you don't remember the original Administrator password of your Windows 2000
Server or Windows Server 2003 installation, demote the domain controller and repromote