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
folder.
N
ote 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
utility.
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
server.
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.
N
ote 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
controller:
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
with time
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
production.
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
controller.
N
ote 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
up-to-date.
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
two options:
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 <F8> 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.
N
ote 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
process
N
ote 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.