Anda di halaman 1dari 58

Planning for Active Directory Forest

Recovery
Microsoft Corporation
First published: October 2006
Updated and republished: May 2009, March 2010

Abstract
This guide contains best-practice recommendations for recovering an Active Directory® forest if
forest-wide failure renders all domain controllers in the forest incapable of functioning normally.
The steps, which you must customize for your particular environment, describe how to recover
the entire Active Directory forest to a point in time before the critical malfunction. They also
ensure that none of the restored domain controllers replicate from a domain controller with
potentially dangerous data.
The steps in this guide apply to Active Directory forests where the domain controllers run
Microsoft® Windows® 2000 Server, Windows Server® 2003, or Windows Server 2008 operating
systems.
Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the example companies, organizations, products,
domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious,
and no association with any real company, organization, product, domain name, e-mail address,
logo, person, place, or event is intended or should be inferred. Complying with all applicable
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part
of this document may be reproduced, stored in, or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.
© 2006-2010 Microsoft Corporation. All rights reserved.
Active Directory, Microsoft, Windows, and Windows Server are either registered trademarks or
trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.
Contents
Planning for Active Directory Forest Recovery................................................................................1
Abstract....................................................................................................................................1

Contents..........................................................................................................................................3

Planning for Active Directory Forest Recovery................................................................................5


Publication and revision history...................................................................................................5

Assumptions and Prerequisites for Using This Guide for Planning Active Directory Forest
Recovery.....................................................................................................................................8
Assumptions for Using This Guide for Planning Active Directory Forest Recovery......................8
Prerequisites for Using This Guide for Planning Active Directory Forest Recovery.....................8

Devising a Custom Forest Recovery Plan.......................................................................................9

Deciding When to Perform Forest Recovery...................................................................................9

Recovering Your Active Directory Forest.......................................................................................10


Determining which backups to use............................................................................................11
Determining which domain controllers to restore.......................................................................12
Recovery roadmap....................................................................................................................12
Prerecovery steps......................................................................................................................15
Recovery steps..........................................................................................................................18
Restore the first writable domain controller for the forest root domain...................................19
Restore the first writable domain controller in each of the remaining domains.......................24
Add the global catalog to a domain controller in the forest root domain.................................27
Recover additional domain controllers in the forest by installing AD DS................................28
Postrecovery steps....................................................................................................................29

Appendix A: Forest Recovery Procedures....................................................................................30


Backing up the System State data.............................................................................................30
Windows Server 2003: Backing up the System State data....................................................30
Windows Server 2008: Backing up the System State data....................................................31
Performing a nonauthoritative restore of Active Directory Domain Services..............................31
Windows Server 2003: Performing a nonauthoritative restore...............................................32
Windows Server 2008: Performing a nonauthoritative restore...............................................33
Configuring the DNS Server service..........................................................................................33
Windows Server 2003: Install and configure the DNS Server service....................................34
Windows Server 2008: Install and configure the DNS Server service....................................35
Removing the global catalog.....................................................................................................36
Raising the value of available RID pools...................................................................................37
Seizing an operations master role.............................................................................................38
Cleaning metadata of removed writable domain controllers......................................................39
Windows Server 2003: Clean metadata of removed writable domain controllers by using
Ntdsutil.exe.........................................................................................................................40
Windows Server 2008: Deleting a domain controller using Active Directory Users and
Computers..........................................................................................................................42
Removing the failed server object..............................................................................................43
Removing the failed computer object.........................................................................................43
Resetting the computer account password of the domain controller..........................................44
Resetting the krbtgt password...................................................................................................44
Resetting a trust password on one side of the trust...................................................................45
Adding the global catalog..........................................................................................................46

Appendix B: Frequently Asked Questions.....................................................................................47


What can I do to speed up recovery?........................................................................................47
Can I automate the forest recovery process?............................................................................49
Can I restore more than one domain controller from backup in each domain?..........................50
Can I restore a global catalog server at an earlier stage?.........................................................54
Should I install AD DS by using the regular dcpromo routine or IFM?.......................................54

Additional Resources....................................................................................................................56
Planning for Active Directory Forest
Recovery
This guide contains best-practice recommendations for recovering an Active Directory® forest if
forest-wide failure renders all domain controllers in the forest incapable of functioning normally.
The steps it contains serve as a template for your forest recovery plan, which you can customize
for your particular environment. These steps apply to domain controllers that run Microsoft®
Windows® 2000 Server, Windows Server® 2003, or Windows Server 2008 operating systems.

Note

In Windows 2000 Server and Windows Server 2003, the directory service is named
Active Directory. In Windows Server 2008, the directory service is named Active Directory
Domain Services (AD DS). The rest of this guide refers to AD DS, but the steps are also
applicable to Active Directory.
To download Planning for Active Directory Forest Recovery as a printable .doc file, see Planning
for Active Directory Forest Recovery (http://go.microsoft.com/fwlink/?LinkId=152459).
In this guide
• Assumptions and Prerequisites for Using This Guide for Planning Active Directory Forest
Recovery
• Devising a Custom Forest Recovery Plan
• Deciding When to Perform Forest Recovery
• Recovering Your Active Directory Forest
• Appendix A: Forest Recovery Procedures
• Appendix B: Frequently Asked Questions
• Additional Resources

Publication and revision history


The following table summarizes the revision history for this guide, including its original publication
on Microsoft TechNet.

Date Revision

October 2006 Original publication on Technet

May2009 An additional instance of this guide was


published in the Windows Server 2008
Technical Library. The guidelines were also
updated to reflect new functionality for

5
Windows Server 2008, including the following:
• In Deciding When to Perform Forest
Recovery and Recovering Your Active
Directory Forest, added information about
how read-only domain controllers (RODCs)
can help to maintain business continuity
during the forest recovery process.
• In the section “Determining which
backups to use,” added information about
using the Active Directory Database
Mounting Tool (Dsamain.exe) and the
ntdsutil snapshot command.
• In the section “Recovery Roadmap,”
added information about a new method for
creating installation media for install from
media (IFM) operations by using the
ntdsutil ifm command.
• In the sections “Restore the first domain
controller for the forest root domain” and
“Restore the first domain controller in each
of the remaining domains,” added
information about how to perform the
restore on a domain controller that runs
Windows Server 2008, including how to
perform an authoritative restore of
SYSVOL, and how to perform metadata
cleanup more simply by using the version of
Active Directory Users and Computers that
is included with Windows Server 2008.
• In the section “Recover additional
domain controllers in the forest by installing
AD DS,” added information about the
Source Domain Controller page that
appears in the Active Directory Domain
Services Installation Wizard.
• In Appendix A: Forest Recovery
Procedures, added information about new
methods in Windows Server 2008 for
performing backup and restore, metadata
cleanup, and deleting a domain controller
object.
• In Appendix B: Frequently Asked

6
Questions, added information about new
functionality provided in
Windows Server 2008 and a new method
for performing an integrity check and
checksum verification on a domain
controller that runs Windows Server 2008
by stopping AD DS and using the ntdsutil
command.

November 2009 The topics Recovering Your Active Directory


Forest and Appendix A: Forest Recovery
Procedures were revised with information about
how to perform an authoritative restore of
SYSVOL without using Wbadmin.exe.
The section “Restore the first domain controller
for the forest root domain,” was revised to
include adding the Repl Perform Initial
Synchronizations registry entry in the steps for
recovering the first writable domain controller in
the forest root domain.
The topic Appendix B: Frequently Asked
Questions, had information added about using
full server recovery instead of system state
restore to recover servers more quickly.
The section “Determining which backups to
use,” was revised to include a warning to not
perform a system state restore to a different
server than the server that was used to create
the backup, along with other best practices for
choosing a backup.

March 2010 Recovering Your Active Directory Forest and


Appendix A: Forest Recovery Procedures were
revised with information about how to install and
configure DNS server for Windows
Server 2008.

7
Assumptions and Prerequisites for Using
This Guide for Planning Active Directory
Forest Recovery
This topic describes the following issues that you can review before you use the forest recovery
guidelines:
• Assumptions for Using This Guide for Planning Active Directory Forest Recovery
• Prerequisites for Using This Guide for Planning Active Directory Forest Recovery

Assumptions for Using This Guide for Planning


Active Directory Forest Recovery
First, this guide assumes that you have:
• Worked with Microsoft Customer Support Services (CSS) to determine the cause of the
forest-wide failure. This guide does not suggest a cause of the failure or recommend any
procedures to prevent the failure.
• Evaluated any possible remedies.
• Concluded, in consultation with CSS, that restoring the whole forest to its state before the
failure occurred is the best way to recover from the failure. In many cases, total forest
recovery should be the last option.
Second, this guide assumes that you have followed the Microsoft best-practice recommendations
for using Active Directory–integrated Domain Name System (DNS). Specifically, there should be
an Active Directory–integrated DNS zone for each Active Directory domain. If this is not the case,
you can still use the basic principles of this guide to perform forest recovery. For more information
about using Active Directory–integrated DNS, see Designing a DNS Infrastructure to Support
Active Directory (http://go.microsoft.com/fwlink/?LinkId=71362).
Although the objectives of this guide are to recover the forest and maintain or restore full DNS
functionality, recovery can result in a DNS configuration that is changed from the prefailure
configuration. After the forest is recovered, you can revert to the original DNS configuration. The
recommendations in this guide do not describe how to configure DNS servers to perform name
resolution of other portions of the corporate namespace where there are DNS zones that are not
stored in AD DS.

Prerequisites for Using This Guide for Planning


Active Directory Forest Recovery
Before you begin planning for recovery of an Active Directory forest, you should be familiar with
the following:
• Fundamental Active Directory concepts

8
• The importance of operations master roles (also known as flexible single master
operations or FSMO). These roles include the following:
• Schema master
• Domain naming master
• Relative ID (RID) master
• Primary domain controller (PDC) emulator master
• Infrastructure master
In addition, you should have backed up and restored AD DS and SYSVOL in a lab environment
on a regular basis. For more information, see "Backing up the System State data" and
"Performing a nonauthoritative restore of Active Directory" in Appendix A: Forest Recovery
Procedures.
Domain controllers that run Windows 2000 Server or Windows Server 2003 have a built-in
backup tool named ntbackup. On domain controllers that run Windows Server 2008, the built-in
backup utility is named Windows Server Backup (or wbadmin as a command-line tool). For best
practices related to backup and restore of domain controllers that run the Windows 2000 Server
or Windows Server 2003, see Active Directory Disaster Recovery (http://go.microsoft.com/fwlink/?
LinkId=70773). For best practices related to backup and restore of domain controllers that run
Windows Server 2008, see Best Practices for AD DS Backup and Recovery
(http://go.microsoft.com/fwlink/?LinkId=132671).

Devising a Custom Forest Recovery Plan


Depending on your environment and business requirements, you might or might not need to
perform all the steps described in this guide to perform a successful forest recovery. Given that
this guide serves only as a template for forest recovery, it is vital that you devise a custom forest
recovery plan that suits your environment and meets your business needs.
For example, in your forest recovery plan, you should have a detailed topology map of your
forests. The map should list all the information about the domain controllers, such as their names
and backup status, and the trust relationships between them. For a tool that you can use to
create a topology map, see Microsoft Active Directory Topology Diagrammer
(http://go.microsoft.com/fwlink/?LinkID=122938).
You should practice your forest recovery plan at least once a year. Also, it is a good idea to
perform a forest recovery drill when there are membership changes to the Enterprise Admins or
Domain Admins group. This helps ensure that your information technology (IT) staff fully
understands the forest recovery plan.

Deciding When to Perform Forest Recovery


In general, a forest recovery is necessary if none of the writable domain controllers in the forest
can function normally or if the corrupted writable domain controllers can spread dangerous data

9
to new domain controllers. You might have fully functional read-only domain controllers (RODCs)
in the forest, but if there is corruption that affects the creation of new objects on writable domain
controllers, you might have to recover the forest. RODCs do not present the same risk of
corrupting other domain controllers because they do not perform outbound replication.
When symptoms of a forest-wide failure appear, such as in event logs or other monitoring
solutions, work with CSS to determine the cause of the failure, and evaluate any possible
remedies.
Examples of forest-wide failures include the following:
• All domain controllers have been logically corrupted or physically damaged to a point that
business continuity is impossible; for example, all business applications that depend on
AD DS are nonfunctional.
• A rogue administrator has compromised the Active Directory environment.
• An attacker intentionally—or an administrator accidentally—runs a script that spreads
data corruption across the forest.
• An attacker intentionally—or an administrator accidentally—extends the Active Directory
schema with malicious or conflicting changes.
• None of the domain controllers can replicate with their replication partners.
• Changes cannot be made to AD DS at any domain controller.
• New domain controllers cannot be installed in any domain.

Recovering Your Active Directory Forest


Recovering an entire Active Directory forest involves either restoring it from backup or reinstalling
Active Directory Domain Services (AD DS) on every domain controller in the forest. Recovering
the forest restores each domain in the forest to its state at the time of the last trusted backup.
Consequently, the restore operation will result in the loss of at least the following Active Directory
data:
• All objects (such as users and computers) that were added after the last trusted backup
• All updates that were made to existing objects since the last trusted backup
• All changes that were made to either the configuration partition or the schema partition in
AD DS (such as schema changes)
For example, Company A has an Active Directory environment where a designated domain
controller in each domain is backed up nightly at 12:00 A.M. (00:00) on Monday morning, a new
employee named Amy is hired, and a user object is created for her in AD DS. On Monday at
12:00 P.M. (12:00), an existing employee named Andrew transfers from the Marketing
Department to the Finance Department. As a consequence, his user account is moved from the
Marketing organizational unit (OU) to the Finance OU.
At 3:00 P.M. (15:00) on the same day, a forest disaster strikes Company A. Only one domain
controller from each domain is restored from backup as part of the forest recovery process, and
the remaining domain controllers are recovered by reinstalling AD DS. After the forest is

10
recovered at 7:00 P.M. (19:00) on the same day, the administrator notices that the user object
Amy is absent, and the user object Andrew still belongs to the Marketing OU. This is because
both of these changes occurred after the Sunday night backup.
In addition, assuming that all the domain controllers in the forest no longer function correctly, any
software applications that were running on the domain controllers must be reinstalled on the
domain controllers after the forest is recovered.

Determining which backups to use


We recommend that you restore the domain controllers by using backups that were taken a few
days before the occurrence of the failure. In general, you must determine a tradeoff between the
recentness and the safeness of the restored data. Choosing a more recent backup recovers more
useful data, but it might increase the risk of reintroducing dangerous data into the restored forest.

Important

Restoring system state backups depends on the original operating system and server of
the backup. For example, you should not restore a system state backup to a different
server. In this case, you may see the following warning:
“The specified backup is of a different server than the current one. We do not recommend
performing a system state recovery with the backup to an alternate server because the
server might become unusable. Are you sure you want to use this backup for recovering
the current server?”
If you need to restore Active Directory to different hardware, create full server backups
and plan to perform a full server recovery.
If the time of the occurrence of the failure is unknown, investigate further to identify backups that
hold the last safe state of the forest. This approach is less desirable. Therefore, we strongly
recommend that you keep detailed logs about the health state of AD DS on a daily basis so that,
if there is a forest-wide failure, the approximate time of failure can be identified. You should also
keep a local copy of backups to enable faster recovery.
If Active Directory Recycle Bin is enabled, the backup lifetime is equal to the
deletedObjectLifetime value or the tombstoneLifetime value, whichever is less. For more
information, see Active Directory Recycle Bin Step-by-Step Guide
(http://go.microsoft.com/fwlink/?LinkId=178657).
As an alternative in Windows Server 2008, you can also use the Active Directory database
mounting tool (Dsamain.exe) and a Lightweight Directory Access Protocol (LDAP) tool, such as
Ldp.exe or Active Directory Users and Computers, to identify which backup has the last safe state
of the forest. The Active Directory database mounting tool exposes Active Directory data that is
stored in backups or snapshots as an LDAP server. Then, you can use an LDAP tool to browse
the data. This approach has the advantage of not requiring you to restart any domain controller in
Directory Services Restore Mode (DSRM) to examine the contents of the backup of AD DS.

11
For more information about using the Active Directory database mounting tool, see the
Active Directory Database Mounting Tool Step-by-Step Guide (http://go.microsoft.com/fwlink/?
LinkId=132577).
In Windows Server 2008, you can also use the ntdsutil snapshot command to create snapshots
of the Active Directory database. By scheduling a task to periodically create snapshots, you can
obtain additional copies of the Active Directory database over time. You can use these copies to
better identify when the forest-wide failure occurred and then choose the best backup to restore.
You can create snapshots on domain controllers that run either Windows Server 2008 or
Windows Server 2003. For more information about using the ntdsutil snapshot command, see
Snapshot (http://go.microsoft.com/fwlink/?LinkId=132578).

Determining which domain controllers to restore


Back up at least two writable domain controllers for each domain regularly. This way, if there is a
disaster, you have several backups to choose from. Note that you cannot use the backup of a
read-only domain controller (RODC) to restore a writable domain controller. Because this guide
recommends that you restore only one domain controller from backup for each domain, choose a
backup that best meets the following criteria:
• A domain controller that is writable.
• A domain controller that was not a global catalog server before the failure. This saves the
time required to remove and add the global catalog during the recovery process.
• A domain controller that was a Domain Name System (DNS) server before the failure.
This saves the time required to reinstall DNS.
• A domain controller that is accessible physically. This way, you can unplug the computer's
network cable and isolate it from the network during forest recovery.
• A domain controller that has a good backup. A good backup is a backup that can be
restored successfully, was taken a few days before the failure, and contains as much useful
data as possible.
• A domain controller that was a schema operations master or domain naming operations
master. This eliminates the need to use Enterprise Admins credentials to seize these
operations master roles (also known as flexible single master operations (FSMO) roles).
• A domain controller that was the relative ID (RID) operations master, so that problems
with managing RIDs during the recovery are less likely to occur.

Recovery roadmap
This section provides an overview of the recommended path for recovering a forest. It is
important to understand the recovery roadmap before you proceed with the forest recovery steps,
which are described in detail later.
The following list summarizes the recovery steps at a high level:
1. Perform prerecovery steps.

12
Prerecovery steps include determining the current forest structure, identifying the functions
that each domain controller performs, and other related tasks.
2. In each domain, perform an offline restore for one writable domain controller.
3. Starting with the forest root domain controller, introduce the restored domain controllers
to the network.
4. Make the forest root domain controller a global catalog server. Perform replication
synchronization between the forest root domain and each domain in the forest.
Although it is preferred that the forest root domain controller become a global catalog, it is
possible to elect any of the restored domain controllers to become a global catalog.
While steps 1 through 4 are being performed, you can simultaneously start installing the
operating system on each of the remaining writable domain controllers in the forest (that is,
on those writable domain controllers that are not being restored from backup). This prepares
them for step 5.
You do not necessarily have to rebuild RODCs at this point in the process. Instead, they can
continue to allow access to local resources that are cached on the RODCs in their respective
sites while the recovery operations are going on in parallel. Local resources, such as users
and computers, that are not cached on the RODC in that site will have authentication
requests forwarded to a writable domain controller. These requests will fail because writable
domain controllers are offline.
If you are using a hub-and-spoke network architecture, you can concentrate first on
recovering the writable domain controllers in the hub sites. Later, you can rebuild the RODCs
in remote sites.
Remember that some operations in the remote sites, such as password changes, will not
work until you recover writable domain controllers.
5. Install AD DS on the remaining domain controllers in the forest. During the AD DS
installation, each remaining domain controller will replicate data from the single domain
controller for the domain that you restored from backup in step 2.
6. Perform postrecovery steps.
The following flowchart shows the recovery process.

13
Recover the forest root domain first. The forest root domain is important because it stores the
Schema Admins and Enterprise Admins groups. It also helps maintain the trust hierarchy in the
forest. In addition, the forest root domain holds the DNS root server for the forest’s DNS
namespace. Consequently, the Active Directory–integrated DNS zone for that domain contains
the alias (CNAME) resource records for all other domain controllers in the forest (which are
required for replication) and the global catalog DNS resource records.
After you recover the forest root domain, recover the remaining domains in the forest. You can
recover more than one domain at a time; however, always recover a parent domain before
recovering a child to prevent any break in the trust hierarchy or DNS name resolution.
For each domain that you recover:
• Restore only one writable domain controller from backup.
This is the most important part of the recovery because the domain controller must have a
database that has not been influenced by whatever caused the forest to fail.
In addition, it is important to have a trusted backup that is thoroughly tested before it is
introduced into the production environment.
• Install AD DS on the remaining domain controllers.
There are two methods to install AD DS, both of which can be automated:
• Use the Active Directory Domain Services Installation Wizard
14
Installing AD DS on the remaining domain controllers, although more time consuming
than restoring them from backup, is safer. This is because you restore the entire domain
to the point where the first domain controller in the domain was restored. By verifying that
the first domain controller does not contain potentially dangerous data, you are assured
that remaining domain controllers will not contain dangerous data as a result of
replication from the trusted domain controller. If you restored every domain controller
from backup, you would have to verify that none of the restored domain controllers
reintroduces dangerous data into the Active Directory forest.
• Install from Media (IFM)
You can create installation media to reduce replication traffic when you install AD DS. You
can create the installation media by restoring a recent backup to an alternate location or
by using the ntdsutil ifm command. For more information about using a backup to install
from media, see article 311078 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkId=70809). For more information about using the
ntdsutil ifm command, see Installing AD DS from Media (http://go.microsoft.com/fwlink/?
LinkId=132630).

Note

If you use a backup, be sure to use a backup of the same operating system
and Service Pack as that of the domain controller that you are installing. For
example, use the backup of a restored domain controller running
Windows Server 2003 with Service Pack 1 (SP1) to install AD DS only on
another server that runs Windows Server 2003 with SP1. Do not use a
Windows Server 2003 with SP1 backup to install AD DS on a server that is
running Windows Server 2003 without SP1 or that is running
Windows Server 2003 R2. In addition, use the backup of a 32-bit installation
to install AD DS on another 32-bit server, and use the backup of a 64-bit
installation to install AD DS on another 64-bit server. However, if you are
using ntdsutil ifm to create the installation media, you can use a 32-bit
server to create media for a 64-bit domain controller, and the reverse.
The following sections describe the exact steps to follow when you recover a forest. The steps
are grouped into three sections:
• Prerecovery steps
• Recovery steps
• Postrecovery steps
Although these sections provide a conceptual view of the recovery process, the procedures to
perform these steps are contained in Appendix A: Forest Recovery Procedures.

Prerecovery steps
Before you start the recovery process, perform the following steps. It is assumed that all writable
domain controllers in the forest are not functional at this point. In addition, an Administrator

15
account password is required for each domain in the forest. Without a global catalog enabled for
the forest, the Administrator account is the only account that can be used to log on to a domain
controller. You must also know the DSRM password to restore a domain controller. In general, it is
a good practice to archive the Administrator account and DSRM password history in a safe place
for as long as the backups are valid, that is, within the tombstone lifetime period.

Note

An administrator is a member of the built-in Administrators group. Members of this group


have full control of all domain controllers in the domain. By default, the Domain Admins
and Enterprise Admins groups are members of the Administrators group. The
Administrator account is also a default member.
1. Determine the current forest structure by identifying all the domains in the forest. Make a
list of all of the domain controllers in each domain, particularly the domain controllers that
have backups. A list of domain controllers for the forest root domain will be the most important
because you will recover this domain first. After you restore the forest root domain, you can
obtain a list of the other domains, domain controllers, and the sites in the forest by using
Active Directory Domains and Trusts and Active Directory Sites and Services.
Prepare a table that shows the functions of each domain controller in the domain, as shown
in the following example. This will help you revert back to the prefailure configuration of the
forest after you recover the forest.

16
Domain Operating system Operations Writable Backup Global DNS
controller installed master roles or read- available catalog server
name only

DC_1 Windows Schema Writable Yes Yes No


Server 2008 master,
primary
domain
controller
(PDC)
emulator
master

DC_2 Windows None Writable Yes Yes Yes


Server 2003

DC_3 Windows Infrastructure Writable No No No


Server 2008 master

DC_4 Windows Domain Writable Yes No Yes


Server 2003 R2 naming
master, RID
master

DC_5 Windows None Writable No Yes No


Server 2003

RODC_1 Windows None Read- Yes Yes Yes


Server 2008 only

RODC_2 Windows None Read- No Yes Yes


Server 2008 only

2. For each domain in the forest, identify a single writable domain controller that has a
trusted backup of the Active Directory database for that domain.
Use caution when you choose a backup to restore a domain controller. If the day and cause
of the failure are approximately known, the general recommendation is to use a backup that
was made a few days before that date.
For the sample domain in this guide, there are three backup candidates: DC_1, DC_2, and
DC_4. Of these backup candidates, you restore only one. The recommended domain
controller is DC_4 for the following reasons:
• It is a DNS server. Therefore, DNS does not have to be reinstalled.
• It is not a global catalog server. Therefore, you do not have to disable global catalog
functionality during the recovery procedure.
• It is a RID master. Therefore, problems with managing RIDs during the recovery are
less likely to occur.

17
For more information, see Determining which domain controllers to restore, earlier in this
topic.
3. Shut down all the domain controllers in the forest.
You must shut down all writable domain controllers before the first restored domain controller
is brought back into production. This ensures that any dangerous data does not replicate
back into the recovered forest. It is particularly important to shut down all operations master
role holders. Disconnect the network cable of the first domain controller that you plan to
restore in the forest root domain. If possible, also disconnect the network cables of all other
domain controllers. This prevents domain controllers from replicating, if they are accidentally
started during the forest recovery process.
In a large forest that is spread across multiple locations, it can be difficult to guarantee that all
writable domain controllers are shut down. For this reason, the recovery steps—such as
resetting the computer account, krbtgt account, and trust passwords, in addition to metadata
cleanup—have been designed to ensure that the recovered writable domain controllers do
not replicate with dangerous writable domain controllers (in case some are still online in the
forest).
However, only by taking writable domain controllers offline can you guarantee that replication
does not occur. Therefore, whenever possible, you should deploy remote management
technology that can help you to shut down and physically isolate the writable domain
controllers during forest recovery.
RODCs can continue to operate while writable domain controllers are offline. Because no
other domain controller will directly replicate any changes from any RODC—especially, no
Schema or Configuration container changes—they do not pose the same risk as writable
domain controllers during recovery, and you can address them later in the process. Because
no writeable copy of AD DS is available, RODCs may experience erratic behavior. After all
the writable domain controllers are recovered and online, you should rebuild all the RODCs.

Recovery steps
After you identify a domain controller for each domain in the forest that you will restore from
backup and you shut down all the domain controllers in the forest, you can perform recovery
steps.
This section includes the following steps:
• Restore the first writable domain controller for the forest root domain
• Restore the first writable domain controller in each of the remaining domains
• Add the global catalog to a domain controller in the forest root domain
• Recover additional domain controllers in the forest by installing AD DS
As stated earlier, the steps in this guide are designed to minimize the possibility of reintroducing
dangerous data into the recovered forest. You might have to modify these steps to account for
such factors as:
• Scalability

18
• Remote manageability
• Speed of recovery
However, modifications to these forest recovery steps can increase the risk of reintroducing
dangerous data. For more information about possible modifications to these forest recovery
steps, see What can I do to speed up recovery?.

Restore the first writable domain controller for the forest root
domain
Ensure that the network cable of the first writable domain controller in the forest root domain is
not attached and therefore is not connected to the production network. Then, perform the
following steps. Procedures for performing certain steps are in Appendix A: Forest Recovery
Procedures.
1. Because this is the first writable domain controller in the domain, you must perform a
nonauthoritative restore of AD DS and an authoritative restore of the SYSVOL folder. An
authoritative restore of SYSVOL is required because replication of the SYSVOL replicated
folder must be started after you recover from a disaster. All subsequent domain controllers
that are added in the domain must resynchronize their SYSVOL folder with a copy of the
folder that has been selected to be authoritative before the folder can be advertised. Restore
operations are performed differently, depending on whether the domain controller runs
Windows Server 2003 or Windows Server 2008. These operating systems include different
tools for restoring the server.
If you are restoring a domain controller that runs Windows Server 2003, use the ntbackup
command to mark SYSVOL as the primary data to be restored. For more information, see
"Performing an authoritative restore of SYSVOL" in Appendix A: Forest Recovery
Procedures.
If you are restoring a domain controller that runs Windows Server 2008, use Wbadmin.exe to
perform a nonauthoritative restore of AD DS. At the same time, perform an authoritative
restore of SYSVOL by including the –authsysvol switch in your recovery command, as
shown in the following example:
wbadmin start systemstaterecovery <otheroptions> -authsysvol

Caution

Perform an authoritative (or primary) restore operation of SYSVOL only for the
first domain controller to be restored in the forest root domain. Incorrectly
performing primary restore operations of the SYSVOL on other domain
controllers leads to replication conflicts of SYSVOL data.
If you are not using Wbadmin.exe to restore the domain controller, you can use alternative
ways to perform an authoritative restore of SYVOL. For example, if you are using File
Replication Service (FRS) to replicate SYSVOL, you can set the BurFlags registry entry to
D4. For more information, see article 290762 in the Microsoft Knowledge Base.

19
If you are using Distributed File System (DFS) Replication for SYSVOL, you can create a new
registry entry of type REG_SZ with the name SYSVOL below the registry key
HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Restore. For authoritative restore, set
the SYSVOL value to authoritative. For nonauthoritative restore, set the SYSVOL value to
non-authoritative. Also, set LastRestoreId. The LastRestoreId is a GUID that is formatted
as 00000000-0000-0000-0000-000000000000. The GUID has to be different each time a
restore is requested. For example, if you have the LastRestoreId set as 10000000-0000-
0000-0000-000000000000, for the next restore you have to set it to a different GUID, such as
20000000-0000-0000-0000-000000000000. For more information about setting
LastRestoreId, see Registry Keys and Values for Backup and Restore
(http://go.microsoft.com/fwlink/?LinkId=178594).
In some situations, you might choose to perform a full server recovery instead of restoring
system state. It is not possible to perform an authoritative restore of SYSVOL during a full
server recovery. If you perform a full server recovery, you might have to start the restored
domain controller in normal mode and then restart it in DSRM before you can perform an
authoritative restore of SYSVOL. If the restored domain controller is not restarted in normal
mode after a full server recovery, the health report for SYSVOL may say "waiting for initial
sync" and you cannot add more domain controllers to the domain.
2. After you restore and restart the writable domain controller, verify that the failure did not
affect the data on the domain controller. If the domain controller data is damaged, repeat
step 1 with a different backup.
Continue to the next steps only after you restore and verify the data and before you join this
computer to the production network.
3. If the first domain controller runs Windows Server 2008, add the following registry entry to
avoid AD DS being unavailable until it has completed replication of a writeable directory
partition. Unless you add this registry entry, you may see Event ID 1555 in the Directory
Services log of the Windows Server 2008 domain controller, which indicates that AD DS is
not available. The registry entry to add is the following:
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Repl Perform Initial
Synchronizations
Create the entry with the data type REG_DWORD and a value of 0. After the forest is
recovered completely, you can reset the value of this entry to 1, which requires a domain
controller that restarts and holds operations master roles to have successful AD DS inbound
and outbound replication with its known replica partners before it advertises itself as domain
controller and starts providing services to clients.
4. If you have DNS zones that are stored in AD DS, ensure that the local DNS Server
service is installed and running on the domain controller that you have restored. Configure
this server with its own IP address (or a loopback address, such as 127.0.0.1) as its preferred
DNS server. You can configure this setting in the TCP/IP properties of the local area network
(LAN) adapter. This is the first DNS server in the forest. For more information, see Configure
TCP/IP to use DNS (http://go.microsoft.com/fwlink/?LinkId=74563).

20
If this domain controller was a DNS server before the forest failure and if it has problems
restarting after the restore, contact Microsoft Customer Service and Support for help in
resolving the problem. If this domain controller was not a DNS server before the forest failure,
you must install and configure DNS. If the restored domain controller runs
Windows Server 2003, it can remain disconnected from the production network while you
install and configure DNS. For more information, see Windows Server 2003: Install and
configure the DNS Server service.
If the restored domain controller runs Windows Server 2008, it must be connected to an
isolated network temporarily for installation and configuration of the DNS server. For more
information about installing and configuring a DNS server for Windows Server 2008, see
Windows Server 2008: Install and configure the DNS Server service. For more information
about the error message that appears when a Windows Server 2008 DNS server without
network connectivity attempts to start, see Article 975654 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkId=184691).
5. If the restored domain controller was a global catalog server before the failure, clear the
Global catalog check box in the NTDS Settings properties to remove the global catalog from
the domain controller. For more information, see "Removing the global catalog" in Appendix
A: Forest Recovery Procedures.
By restoring a global catalog from a backup that is more recent than other backups that are
used to restore other domain controllers, you might introduce lingering objects. Consider the
following example. In domain A, DC1 is restored from a backup that was taken at time T1. In
domain B, DC2 is restored from a global catalog backup that was taken at time T2. Suppose
T2 is more recent than T1, and some objects were created between T1 and T2. After these
domain controllers are restored, DC2, which is a global catalog, holds newer data for
domain A's partial replica than domain A holds itself. DC2, in this case, holds lingering objects
because these objects are not present on DC1.
The presence of lingering objects can lead to problems. For instance, e-mail messages might
not be delivered to a user whose user object was moved between domains. After you bring
the outdated domain controller or global catalog server back online, both instances of the
user object appear in the global catalog. Both objects have the same e-mail address;
therefore, e-mail messages cannot be delivered.
A second problem is that a user account that no longer exists might still appear in the global
address list. A third problem is that a universal group that no longer exists might still appear in
a user's access token.
If you did restore a domain controller that was a global catalog—either inadvertently or
because that was the solitary backup that you trusted—we recommend that you prevent the
occurrence of lingering objects by disabling the global catalog soon after the restore
operation is complete. Disabling the global catalog flag will result in the computer losing all its
partial replicas (partitions) and relegating itself to regular domain controller status.
However, if you have a business need for running a global catalog at this stage, you can do
so as long as you follow the steps to remove lingering objects in the postrecovery stage. For
more information, see Use Repadmin to remove lingering objects
(http://go.microsoft.com/fwlink/?LinkId=70782).
21
6. Raise the value of the current RID pool by 100,000. For more information, see "Raising
the value of available RID pools" in Appendix A: Forest Recovery Procedures.
If new security principals were created in the domain after the time of the backup that you use
for the restore, these security principals might have access rights on certain objects. These
security principals no longer exist after recovery because the recovery has reverted to the
backup; however, their access rights might still exist. If the RID pool is not raised after a
restore, new user objects that are created after the forest recovery might obtain identical
security IDs (SIDs) and could have access to those objects, which was not originally
intended.
To illustrate, consider the example of the new employee named Amy that was mentioned in
the introduction. The user object for Amy no longer exists after the restore operation because
it was created after the backup that was used to restore the domain. However, any access
rights that were assigned to that user object might persist after the restore operation. If the
SID for that user object is reassigned to a new object after the restore operation, the new
object would obtain those access rights.
7. Seize all domain-wide and forest-wide operations master roles. Although you might retain
the operations master roles on the restored domain controller only temporarily, seizing these
roles assures you regarding which domain controller hosts them at this point in the forest
recovery process. As part of your postrecovery process, you can redistribute the operations
master roles as needed. For more information about seizing operations master roles, see
"Seizing an operations master role" in Appendix A: Forest Recovery Procedures. For
recommendations about where to place operations master roles, see What Are Operations
Masters? (http://go.microsoft.com/fwlink/?LinkId=74582).
If your domain was operating at the Windows 2000 native domain functional level or higher
(at this functional level, domain controllers running the Microsoft Windows NT® Server 4.0
operating system or earlier are not supported), and if this domain controller was not a global
catalog before recovery, you will not be able to seize the schema master role on this domain
controller. This is because Schema Admins and Enterprise Admins groups are universal
groups at this functional level. In the absence of a global catalog, your logon security token
does not contain the SIDs of any universal groups. If you cannot seize a particular role, you
can always seize or transfer the role as part of the postrecovery steps.

Note

As stated earlier in Prerecovery steps, you should disconnect the network cable
of the first writable domain controller that you plan to restore in the forest root
domain and, if possible, also disconnect the network cables of all other writable
domain controllers. Steps 7 through 11 ensure that the first domain controller
does not replicate with potentially damaged writable domain controllers in the
same domain if they were not removed from the network.
Although it is not recommended, you can skip steps 7 through 11 if you are absolutely sure
that all writable domain controllers are removed from the network and that they will not be
rejoined to the network until the forest recovery steps are completed. RODCs can remain on
the network because no other domain controllers will replicate from them.
22
8. Clean up metadata of all other writable domain controllers in the forest root domain that
you are restoring from backup, except for this first domain controller. If you use the version of
Active Directory Users and Computers or Active Directory Sites and Services that is included
with Windows Server 2008 or the Microsoft Remote Server Administration Tools (RSAT) for
Windows Vista®, metadata cleanup is performed automatically when you delete a domain
controller object. In addition, the server object and computer object for the deleted domain
controller are also deleted automatically. For more information, see "Cleaning metadata of
removed domain controllers" in Appendix A: Forest Recovery Procedures.
Cleaning up metadata prevents possible duplication of NTDS-settings objects if AD DS is
installed on a domain controller in a different site. Potentially, this could also save the
Knowledge Consistency Checker (KCC) the process of creating replication links when the
domain controllers themselves might not be present. Moreover, as part of metadata cleanup,
DC Locator DNS resource records for all other domain controllers in the domain will be
deleted from DNS.
Until the metadata of all other domain controllers in the domain is removed, this domain
controller, if it were a RID master before recovery, will not assume the RID master role and
therefore will not be able to issue new RIDs. You might see event ID 16650 in the System log
in Event Viewer indicating this failure, but you should see event ID 16648 indicating success
a little while after you have cleaned the metadata.

Note

Steps 8 through 10 ensure that the domain controller does not replicate with
potentially damaged domain controllers in the same domain. Because
subsequent domain controllers in the domain are recovered by installing AD DS,
they will automatically replicate these new passwords during the installation
process.
9. If you used Ntdsutil.exe to perform the metadata cleanup, delete server objects and
computer objects for all domain controllers in the forest root domain that you are restoring
from backup, except for this first domain controller. You must perform these procedures only if
you used Ntdsutil.exe to perform metadata cleanup. For more information, see "Removing
the failed server object" and "Removing the failed computer object" in Appendix A: Forest
Recovery Procedures.
These objects are not required because you will be installing AD DS on all other domain
controllers and, as a result, you will be creating new computer objects and server objects.
10. Reset the computer account password of this domain controller twice. For more
information, see "Resetting the computer account password of the domain controller" in
Appendix A: Forest Recovery Procedures.
11. Reset the krbtgt password twice. For more information, see "Resetting the krbtgt
password" in Appendix A: Forest Recovery Procedures.
Because the krbtgt password history is two passwords, reset passwords twice to remove the
original (prefailure) password from password history.

23
12. Reset the trust password (Trusted Domain Object password) twice for all implicit and
explicit trusts between this domain and all other trusted domains. For more information, see
"Resetting a trust password on one side of the trust" in Appendix A: Forest Recovery
Procedures.

Note

Resetting the trust password ensures that the domain controller does not
replicate with potentially bad domain controllers outside its domain. By setting the
same trust password while restoring the first domain controller in each of the
nonroot domains, you ensure that this domain controller replicates with each of
the recovered domain controllers. Because subsequent domain controllers in the
domain are recovered by installing AD DS, they will automatically replicate these
new passwords during the installation process.

Restore the first writable domain controller in each of the


remaining domains
Ensure that the network cable of the writable first domain controller in each of the remaining
domains is not attached and therefore is not connected to the production network. Then, perform
the following steps. Procedures for performing some of these steps are in Appendix A: Forest
Recovery Procedures.
1. Because this is the writable first domain controller in the domain, you must perform a
nonauthoritative restore of AD DS and an authoritative restore of the SYSVOL folder. You
perform restore operations differently, depending on whether the domain controller runs
Windows Server 2003 or Windows Server 2008. These two operating systems include
different tools for restoring the server.
If you are restoring a domain controller that runs Windows Server 2003, use the ntbackup
command to mark SYSVOL as the primary data to be restored. For more information about
doing this, see "Performing an authoritative restore of SYSVOL" in Appendix A: Forest
Recovery Procedures.
If you are restoring a domain controller that runs Windows Server 2008, use Wbadmin.exe to
perform a nonauthoritative restore of AD DS. At the same time, perform an authoritative
restore of SYSVOL by including the –authsysvol switch in your recovery command, as
shown in the following example:
wbadmin start systemstaterecovery <otheroptions> -authsysvol

Important

Perform an authoritative (or primary) restore operation of SYSVOL only for the
first domain controller to be restored in each of the remaining domains.
Incorrectly performing primary restore operations of SYSVOL on other domain
controllers leads to replication conflicts of SYSVOL data.

24
If you are not using Wbadmin.exe to restore the domain controller, you can use alternative
ways to perform an authoritative restore of SYVOL. For example, if you are using FRS to
replicate SYSVOL, you can set the BurFlags registry entry to D4. For more information, see
article 290762 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?
LinkID=148443).
If you are using Distributed File System (DFS) Replication for SYSVOL, you can create a new
registry entry of type REG_SZ with the name SYSVOL below the registry key
HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Restore. For authoritative restore, set
the SYSVOL value to authoritative. For nonauthoritative restore, set the SYSVOL value to
non-authoritative. Also, set LastRestoreId. The LastRestoreId is a GUID that is formatted
as 00000000-0000-0000-0000-000000000000. The GUID has to be different each time a
restore is requested. For example, if you have LastRestoreId set as 10000000-0000-0000-
0000-000000000000, for the next restore you have to set it to a different GUID, such as
20000000-0000-0000-0000-000000000000. For more information about setting
LastRestoreId, see Registry Keys and Values for Backup and Restore
(http://go.microsoft.com/fwlink/?LinkId=178594).
2. After you restore and restart the writable domain controller, verify that the failure did not
affect the data on the domain controller. If the domain controller data is damaged, repeat
step 1 with a different backup.
Continue to step 3 only after you restore and verify the data and before you join this computer
to the production network.
3. If you have DNS zones that are stored in AD DS, ensure that the local DNS Server
service is installed and running on the domain controller that you have restored. Configure
this server with the IP address of the first DNS server in the forest root domain as its
preferred DNS server. You can configure this setting in the TCP/IP properties of the LAN
adapter. For more information, see Configure TCP/IP to use DNS
(http://go.microsoft.com/fwlink/?LinkId=74563).
Ensure that the parent DNS zone contains delegation resource records (name server (NS)
and host (A) resource records) for the child DNS zone that is hosted on this DNS server. For
more information, see Create a zone delegation (http://go.microsoft.com/fwlink/?
LinkId=74562).
If this domain controller was not a DNS server before the forest failure, you must install and
configure the DNS server. If the restored domain controller runs Windows Server 2003, it can
remain disconnected from the production network while you install and configure DNS. For
more information, see Windows Server 2003: Install and configure the DNS Server service.
If the restored domain controller runs Windows Server 2008, it must be connected to an
isolated network temporarily for installation and configuration of the DNS server. For more
information about installing and configuring a DNS server for Windows Server 2008, see
Windows Server 2008: Install and configure the DNS Server service. For more information
about the error message that appears when a Windows Server 2008 DNS server without
network connectivity attempts to start, see Article 975654 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkId=184691).

25
In this case, you must also ensure that the root DNS server contains alias (CNAME) resource
records for this domain controller. Without the alias (CNAME) resource record, the domain
controller that is restored in the forest root domain will not be able to replicate with this
domain controller. This is required later when you need to make the forest root domain
controller a global catalog server.
Each domain controller in the forest must register its alias (CNAME) resource record for the
name <DsaGuid>._msdcs.<DnsForestName>. DsaGuid is the globally unique identifier
(GUID) of the NTDS Settings object of the domain controller. This appears in Active Directory
Sites and Services as the DNS alias property of NTDS Settings of the Server object for the
domain controller. This record usually belongs to the _msdcs.<ForestName> zone or, if that
zone does not exist, the <ForestName> zone.
After you have one restored domain controller with DNS installed and configured for every
domain, you can reconnect each of them to a mutually shared, isolated network. Run
repadmin /replsum to verify that replication is functioning between the recovered domain
controllers. After you verify replication, you can connect the recovered the production
network.
4. If the restored domain controller was a global catalog server before the failure, clear the
Global catalog check box to remove the global catalog. For more information, see
"Removing the global catalog" in Appendix A: Forest Recovery Procedures.
5. Raise the value of the available RID pool by 100,000. For more information, see "Raising
the value of available RID pools" in Appendix A: Forest Recovery Procedures.
6. Seize all domain-wide operations master roles to this domain controller. For more
information, see "Seizing an operations master role" in Appendix A: Forest Recovery
Procedures.

Note

As stated earlier in Prerecovery steps, you need to disconnect the network cable
of the first writable domain controller that you plan to restore in the forest root
domain and, if possible, also disconnect the network cables of all other writable
domain controllers. Steps 7 through 11 ensure that the first domain controller
does not replicate with potentially damaged writable domain controllers in the
same domain, if they were not removed from the network. RODCs can remain on
the network because no other domain controllers will replicate from them.
7. Clean up the metadata of all writable other domain controllers in the domain that you are
restoring from backup, except for this first domain controller. If you use the version of
Active Directory Users and Computers or Active Directory Sites and Services that is included
with Windows Server 2008 or the Microsoft RSAT for Windows Vista, metadata cleanup is
performed automatically when you delete a domain controller object. In addition, the server
object and computer object for the deleted domain controller are also deleted automatically.
For more information, see "Cleaning metadata of removed domain controllers" in Appendix A:
Forest Recovery Procedures.

26
8. If you used Ntdsutil.exe to perform the metadata cleanup, delete the server objects and
computer objects for all domain controllers in the domain that you are restoring from backup,
except for this first domain controller. You must perform these procedures only if you used
Ntdsutil.exe to perform metadata cleanup. For more information, see "Removing the failed
server object" and "Removing the failed computer object" in Appendix A: Forest Recovery
Procedures.
9. Reset the computer account password of this domain controller twice. For more
information, see "Resetting the computer account password of the domain controller" in
Appendix A: Forest Recovery Procedures.
10. Reset the krbtgt password twice. For more information, see "Resetting the krbtgt
password" in Appendix A: Forest Recovery Procedures.
11. Reset the trust password (Trusted Domain Object password) twice for all implicit and
explicit trusts between this domain and all other trusted domains. For more information, see
"Resetting a trust password on one side of the trust" in Appendix A: Forest Recovery
Procedures.
12.
At this stage you should have one domain controller restored (and recovery steps performed) in
the forest root domain and one domain controller restored (and recovery steps performed) in
each of the remaining domains. If a domain controller that you restored was not a DNS server
and it runs Windows Server 2008, you should disconnect it from the isolated network and
reconnect it to the production network. You should now join these domain controllers to the
production network before performing the next step.

Add the global catalog to a domain controller in the forest root


domain
A global catalog is required for these and other reasons:
• Without a global catalog in a domain that has a functional level of Windows 2000 native
or higher, users cannot log on.
• In the absence of a global catalog, the Net Logon service running on the domain
controllers in each domain (other than the root domain) cannot register (or remove) records
on the DNS server in the root domain.

Note

This domain controller will not be advertised as a global catalog server until it has
completed a full synchronization of all directory partitions in the forest. Therefore,
this domain controller should be forced to replicate with each of the restored
domain controllers in the forest.
Monitor the Directory Service event log in Event Viewer for event ID 1119, which indicates
that this domain controller is a global catalog server. You can also verify this by examining the
following registry key to see if it has a value of 1:

27
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Global Catalog
Promotion Complete
For more information, see "Adding the global catalog" in Appendix A: Forest Recovery
Procedures.
At this stage you should have a stable forest, with one domain controller for each domain and one
global catalog in the forest. You should make a new backup of each of the domain controllers that
you have just restored. You can now begin recovering other domain controllers in the forest by
installing AD DS.

Recover additional domain controllers in the forest by installing


AD DS
Consider the following points for every domain controller that is recovered in the forest by
installing AD DS, as opposed to restoring from backup:
• There is no restriction on the host name of the server on which you want to install AD DS.
You can use the same premalfunction host name or choose a different one. For more
information about DNS host name syntax, see Creating DNS Computer Names
(http://go.microsoft.com/fwlink/?LinkId=74564).
• Configure each server with the first DNS server in the forest (the first domain controller
that was restored in the root domain) as the preferred DNS server in the TCP/IP properties of
its LAN adapter. For more information, see Configure TCP/IP to use DNS
(http://go.microsoft.com/fwlink/?LinkId=74563).
• When you install AD DS on the additional writable domain controllers, point the
Active Directory Domain Services Installation Wizard (Dcpromo.exe) to a source domain
controller that you trust has been recovered and is free of damaged data. You can do this on
the Source Domain Controller page in the wizard or by specifying the ReplicationSourceDC
parameter in the answer file or at the command line during an unattended installation of
AD DS. To make the Source Domain Controller page appear, you must select the Use
advanced mode installation check box on the Welcome page of the Active Directory
Domain Services Installation Wizard.
• Rebuild all RODCs in the domain by removing and reinstalling AD DS. Rebuilding
RODCs ensures that they do not contain any lingering objects and can help prevent
replication conflicts from occurring later. When you remove AD DS, use the dcpromo
/retainDCMetadata parameter. Using this parameter retains the krbtgt account for the RODC
and retains the permissions for the delegated RODC administrator account and the Password
Replication Policy (PRP). Using the dcpromo /retainDCMetadata parameter prevents you
from having to use Domain Admin credentials to remove and reinstall AD DS on an RODC. It
also retains the DNS server and global catalog if they are installed on the RODC originally.

Important

If you do not use the dcpromo /retainDCMetadata parameter, we recommend


that you select the option to install the global catalog server when you install
AD DS on an RODC.
28
When you rebuild RODCs, there may be increased replication traffic during their
reinstallation. To help reduce that impact, you can stagger the schedule of the RODC
installations, and you can use the Install From Media (IFM) option. If you use the IFM option,
run the ntdsutil ifm command on a writable domain controller that you trust to be free of
damaged data. This helps prevent possible corruption from appearing on the RODC after the
AD DS reinstallation is complete. For more information about IFM, see Installing Active
Directory Domain Services from Media (http://go.microsoft.com/fwlink/?LinkId=132630).
For more information about rebuilding RODCs, see RODC Removal and Reinstallation
(http://go.microsoft.com/fwlink/?LinkId=149695).
• If a domain controller was running the DNS Server service before the forest malfunction,
install and configure the DNS Server service during the installation of AD DS. Otherwise,
configure its former DNS clients with other DNS servers.
• You can make a domain controller a global catalog server during the installation of AD DS
if you require additional global catalogs to share authentication or query load for users or
applications.

Postrecovery steps
Perform the following postrecovery steps as needed:
• After the entire forest is recovered, you can revert to the original DNS configuration,
including configuration of the preferred and alternate DNS servers on each of the domain
controllers. After the DNS servers are configured as they were before the malfunction, their
previous name resolution capabilities will be restored. Delete any DNS records for domain
controllers that have not been recovered.
• Delete Windows Internet Name Service (WINS) records for all domain controllers that
have not been recovered.
• You can transfer the operations master roles to other domain controllers in the domain or
forest and add more global catalog servers based on your prefailure configuration.
• Because the entire forest is restored to a previous state, any objects (such as users and
computers) that were added and all updates (such as password changes) that were made to
existing objects after this point are lost. Therefore, you should re-create these missing objects
and reapply the missing updates as appropriate.
• You might also need to restore outgoing trusts with external domains, because these
external trust relationships are not restored automatically from backups.
• If you suspect that the forest-wide failure was related to network intrusion or malicious
attack, you can reset the account passwords for members of the Enterprise Admins and
Domain Admins groups.
• Restore or reinstall any software applications that were running on domain controllers
before recovery. Restoring AD DS on the first domain controller in the domain also restores
the registry because they both are part of System State data. Keep this in mind if you had any
applications running on these domain controllers and if they had any information stored in the
registry.

29
• For client computers, you might have to reset their secure channel with domain
controllers or rejoin them to the domain. To reset the secure channel, you can use
Netdom.exe. At a command prompt, type the following command, and then press ENTER:
netdom reset <computername> /domain:<domainname>

Appendix A: Forest Recovery Procedures


This appendix contains the following procedures, which are related to the steps described earlier
in this guide:
• Backing up the System State data
• Performing a nonauthoritative restore of Active Directory Domain Services
These steps explain how to performing an authoritative restore of SYSVOL at the same time.
• Configuring the DNS Server service
• Removing the global catalog
• Raising the value of available RID pools
• Seizing an operations master role
• Cleaning metadata of removed writable domain controllers
• Removing the failed server object
• Removing the failed computer object
• Resetting the computer account password of the domain controller
• Resetting the krbtgt password
• Resetting a trust password on one side of the trust
• Adding the global catalog

Backing up the System State data


To back up System State data, complete either of the following procedures, depending on which
operating system is running on the domain controller:
• Windows Server 2003: Backing up the System State data
• Windows Server 2008: Backing up the System State data

Windows Server 2003: Backing up the System State data


Use the following procedure to back up the System State data, along with any other data you
have selected for the current backup operation, of a domain controller that runs
Windows Server 2003. Windows Server 2003 includes the Ntbackup tool, which you can use to
back up System State data.
Membership in Administrators or Backup Operators, or equivalent, is the minimum required to
back up files and folders. Review details about using the appropriate accounts and group

30
memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?
LinkId=83477).
If you are backing up the System State data to a tape, and the Backup program indicates that
there is no unused media available, you might have to use Removable Storage. This adds your
tape to the free media pool so that Backup can use it.
You can only back up the System State data on a local computer. You cannot back it up on a
remote computer.

To back up the System State data on a domain controller that runs


Windows Server 2003

1. Click Start, point to All Programs, point to Accessories, point to System Tools,
and then click Backup.
2. On the Welcome page, click Advanced Mode.
3. On the Backup tab, select the check box for any drive, folder, or file that you want to
back up.
4. Select the System State check box.
5. Click Start Backup.

Windows Server 2008: Backing up the System State data


If your domain controller is running Windows Server 2008, you can use Windows Server Backup
or Wbadmin.exe to back up a domain controller. For more information, see Performing an
Unscheduled Backup of a Domain Controller (http://go.microsoft.com/fwlink/?LinkId=132632).

Performing a nonauthoritative restore of


Active Directory Domain Services
To perform a nonauthoritative restore, complete either of the following procedures, depending on
which operating system is running on the domain controller:
• Windows Server 2003: Performing a nonauthoritative restore
• Windows Server 2008: Performing a nonauthoritative restore
The following procedures use the Wbadmin.exe or Ntbackup tools to perform a nonauthoritative
restore of Active Directory or Active Directory Domain Services (AD DS). If you are using a
different backup solution or if you intend to complete the authoritative restore of SYSVOL later in
the forest recovery process, you can perform an authoritative restore of SYSVOL by using these
alternative methods:
• If you are using File Replication Service (FRS) to replicate SYSVOL, follow the steps in
article 290762 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?
LinkId=148443), using the BurFlags registry key to reinitialize FRS replica sets.
• If you are using Distributed File System (DFS) Replication to replicate SYSVOL, you can
create a new registry entry of the type REG_SZ with the name SYSVOL below the registry

31
key HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Restore. For authoritative restore,
set the SYSVOL value to authoritative. For nonauthoritative restore, set the SYSVOL value
to non-authoritative. Also, set LastRestoreId. LastRestoreId is a globally unique identifier
(GUID) formatted as 00000000-0000-0000-0000-000000000000. The GUID has to be
different each time that a restore is requested. For example, if you have LastRestoreId set
as 10000000-0000-0000-0000-000000000000, for the next restore you have to set it to a
different GUID, such as 20000000-0000-0000-0000-000000000000. For more information
about setting LastRestoreId, see Registry Keys and Values for Backup and Restore
(http://go.microsoft.com/fwlink/?LinkId=178594).

Windows Server 2003: Performing a nonauthoritative restore


Use the following procedure to perform a nonauthoritative restore of a domain controller that runs
Windows Server 2003. By performing a nonauthoritative restore on Active Directory in
Windows Server 2003, you automatically perform a nonauthoritative restore of SYSVOL. No
additional steps are required.

Note

If you are also reinstalling the Windows Server 2003 operating system, you might or
might not join the computer to the domain and you can give any name to the computer
during setup of the operating system. Do not install Active Directory. After reinstalling the
operating system, go directly to step 4.
Some of the remaining procedures require Windows Support Tools. These tools are available on
the Windows Server 2003 operating system installation disc in the \Support\Tools folder. For more
information about Windows Support Tools, click Start, click Help and Support, click Tools, and
then click Windows Support Tools. To download these tools from the Microsoft Download
Center, see Windows Server 2003 Service Pack 1 32-bit Support Tools
(http://go.microsoft.com/fwlink/?LinkId=70775).

To perform a nonauthoritative restore of a domain controller that runs


Windows Server 2003

1. After you start the domain controller, press F8 to restart the computer in Directory
Services Restore Mode (DSRM).
2. Select Directory Services Restore Mode (Windows domain controllers only).
3. Select the operating system that you want to start in restore mode.
4. Log on as an administrator (you can only use a local computer account, no domain
logon option is available).
5. At a command prompt, type ntbackup, and then press ENTER.
6. On the Welcome page, click Advanced Mode, and then select the Restore and
Manage Media tab. (Do not select Restore Wizard.)
7. Select the appropriate backup file to restore from and ensure that the System disk
and System State check boxes are selected.

32
8. Click Start Restore.
9. When the restore operation is complete, restart the computer.

Use the following procedure to perform an authoritative (also known as primary) restore of
SYSVOL on a domain controller that runs Windows Server 2003. Perform this procedure only on
the first Windows Server 2003 domain controller that is restored in the domain. If the domain
controller runs Windows Server 2008, see the next procedure: “To perform an authoritative
restore of SYSVOL on a domain controller that runs Windows Server 2008.”

To perform an authoritative restore of SYSVOL on a domain controller that runs


Windows Server 2003

1. Perform steps 1 through 8 in the procedure for Performing a nonauthoritative restore


of Active Directory.
2. In the Confirm Restore dialog box, click Advanced.
3. To perform an authoritative restore of SYSVOL, select the check box When
restoring replicated data sets, mark the restored data as the primary data for all
replicas.

Notes
Marking the restored data as the primary data in the Backup is equivalent to
setting the BurFlags entry to D4 under the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Pa
rameters\Cumulative Replica Sets\GUID
4. When the restore operation is complete, restart the computer.

Windows Server 2008: Performing a nonauthoritative restore


Complete the steps to perform a nonauthoritative restore of AD DS. For more information, see
Performing a Nonauthoritative Restore of AD DS (http://go.microsoft.com/fwlink/?LinkId=132637).

To perform an authoritative restore of SYSVOL on a domain controller that runs


Windows Server 2008

• Include the -authsysvol switch in your recovery command, as shown in the following
example:
wbadmin start systemstaterecovery <otheroptions> -authsysvol

Configuring the DNS Server service


If the DNS server role is not installed on the domain controller that you restore from backup, you
must install and configure the DNS server. Windows Server 2003 and Windows Server 2008
require different procedures for installing and configuring a DNS server if the server is not
connected to a network, which will be the case after the first domain controller in each domain is
restored from backup.
33
• Windows Server 2003: Install and configure the DNS Server service
• Windows Server 2008: Install and configure the DNS Server service

Windows Server 2003: Install and configure the DNS Server


service
If the domain controller that you restored from backup is running Windows Server 2003, you can
install DNS server without connecting the domain controller to any network.

To install and configure the DNS Server service for Windows Server 2003

1. Open Windows Components Wizard. To open the wizard:


• Click Start, click Control Panel, and then click Add or Remove Programs.
• Click Add/Remove Windows Components.
2. In Components, select the Networking Services check box, and then click Details.
3. In Subcomponents of Networking Services, select the Domain Name System
(DNS) check box, click OK, and then click Next.
4. If you are prompted, in Copy files from, type the full path of the distribution files, and
then click OK.
After the installation, complete the following steps to configure the DNS server.
5. Click Start, point to All Programs, point to Administrative Tools, and then click
DNS.
6. Create DNS zones for the same DNS domain names that were hosted on the DNS
servers before the critical malfunction. For more information, see Add a Forward Lookup
Zone (http://go.microsoft.com/fwlink/?LinkId=74574).
7. Configure the DNS data as it existed before the critical malfunction. For example:
• Configure DNS zones to be stored in AD DS. For more information, see Change
the Zone Type (http://go.microsoft.com/fwlink/?LinkId=74579).
• Configure the DNS zone that is authoritative for domain controller locator
(DC Locator) resource records to allow secure dynamic update. For more
information, see Allow Only Secure Dynamic Updates
(http://go.microsoft.com/fwlink/?LinkId=74580).
8. Ensure that the parent DNS zone contains delegation resource records (name server
(NS) and glue host (A) resource records) for the child zone that is hosted on this DNS
server. For more information, see Create a Zone Delegation
(http://go.microsoft.com/fwlink/?LinkId=74562).
9. After you configure DNS, at the command prompt, type the following command, and
then press ENTER:
net stop netlogon
10. Type the following command, and then press ENTER:
net start netlogon

34
Note
Net Logon will register the DC Locator resource records in DNS for this
domain controller. If you are installing the DNS Server service on a server in
the child domain, this domain controller will not be able to register its records
immediately. This is because it is currently isolated as part of the recovery
process, and its primary DNS server is the forest root DNS server. Configure
this computer with the same IP address as it had before the disaster to avoid
domain controller service lookup failures.

Windows Server 2008: Install and configure the DNS Server


service
If the domain controller that you restored from backup is running Windows Server 2008, you must
connect the domain controller to an isolated network in order to install DNS server. If the DNS
server role is already installed, you can apply a hotfix that makes it possible for a DNS server to
start while the server is not connected to any network. You should slipstream the hotfix into the
operating system installation image during your automated build processes. For more information
about the hotfix, see Article 975654 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkId=184691).
Complete this step for each domain. After you have one restored domain controller with DNS
installed and configured for every domain, you can reconnect each of them to a mutually shared,
isolated network. Run repadmin /replsum to verify that replication is functioning between the
recovered domain controllers. After you verify replication, you can connect the recovered the
production network.

To install and configure the DNS Server service for Windows Server 2008

1. Open Server Manager. To open Server Manager, click Start, and then click Server
Manager.
2. In the results pane, under Roles Summary, click Add roles.
3. In the Add Roles Wizard, if the Before You Begin page appears, click Next.
4. In the Roles list, click DNS Server, and then click Next.
5. Read the information on the DNS Server page, and then click Next.
6. On the Confirm Installation Options page, verify that the DNS Server role will be
installed, and then click Install.
After the installation, complete the following steps to configure the DNS server.
7. Click Start, point to All Programs, point to Administrative Tools, and then click
DNS.
8. Create DNS zones for the same DNS domain names that were hosted on the DNS
servers before the critical malfunction. For more information, see Add a Forward Lookup
Zone (http://go.microsoft.com/fwlink/?LinkId=74574).

35
9. Configure the DNS data as it existed before the critical malfunction. For example:
• Configure DNS zones to be stored in AD DS. For more information, see Change
the Zone Type (http://go.microsoft.com/fwlink/?LinkId=74579).
• Configure the DNS zone that is authoritative for domain controller locator
(DC Locator) resource records to allow secure dynamic update. For more
information, see Allow Only Secure Dynamic Updates
(http://go.microsoft.com/fwlink/?LinkId=74580).
10. Ensure that the parent DNS zone contains delegation resource records (name server
(NS) and glue host (A) resource records) for the child zone that is hosted on this DNS
server. For more information, see Create a Zone Delegation
(http://go.microsoft.com/fwlink/?LinkId=74562).
11. After you configure DNS, at the command prompt, type the following command, and
then press ENTER:
net stop netlogon
12. Type the following command, and then press ENTER:
net start netlogon

Removing the global catalog


Use the following procedure to remove the global catalog from a domain controller.
Restoring a global catalog server from backup could result in the global catalog holding newer
data for one of its partial replicas than the corresponding domain that is authoritative for that
partial replica. In such a case, the newer data will not be removed from the global catalog and
might even replicate to other global catalog servers. As a result, even if you did restore a domain
controller that was a global catalog server, either inadvertently or because that was the solitary
backup you trusted, you should remove the global catalog soon after the restore operation is
complete. When the global catalog is removed, the computer removes all its partial replicas. The
following procedure applies to domain controllers that run Windows Server 2003 or
Windows Server 2008.

To remove the global catalog

1. Click Start, point to All Programs, point to Administrative Tools, and then click
Active Directory Sites and Services.
2. In the console tree, expand the Sites container, and then select the appropriate site
that contains the target server.
3. Expand the Servers container, and then expand the server object for the domain
controller from which you want to remove the global catalog.
4. Right-click NTDS Settings, and then click Properties.
5. Clear the Global Catalog check box.

36
Raising the value of available RID pools
Use the following procedure to raise the value of the relative ID (RID) pools that the RID
operations master will allocate after that domain controller is restored. By raising the value of the
available RID pools, you can ensure that no domain controller allocates a RID for a security
principal that was created after the backup that was used to restore the domain. The following
procedure applies to domain controllers that run Windows Server 2003 or Windows Server 2008.

To raise the value of available RID pools

1. At the command prompt, change directories to the folder that contains the Windows
Support Tools, type the following command, and then press ENTER:
ldp
2. Click Connection, click Connect, type the name of the server on which you want to
raise the RID pool, and then click OK.
3. Click Connection, click Bind, type your administrative credentials, and then click
OK.
4. Click View, click Tree, and then type the following distinguished name path:
CN=RID Manager$,CN=System,DC=<domain name>
This account has an attribute named rIDAvailablePool. This attribute value maintains the
global RID space for an entire domain. The value is a large integer with upper and lower
parts. The upper part defines the number of security principals that can be allocated for
each domain (0x3FFFFFFF or just over 1 billion). The lower part is the number of RIDs
that have been allocated in the domain. To view both parts, in Ldp.exe use the Large
Integer Converter command in the Utilities menu.
• Sample Value: 4611686014132422708 (Insert in Large Integer Calculator in the
Utilities menu of Ldp.exe)
• Low Part: 2100 (beginning of the next RID pool to be allocated)
• Upper Part: 1073741823 (total number of RIDs that can be created in a domain)
When you increase the value of the large integer, you increase the value of the low part.
For example, if you add 100,000 to the sample value of 4611686014132422708 for a
sum of 4611686014132522708, the new low part is 102100. This indicates that the next
RID pool that will be allocated by the RID master will begin with 102100 instead of 2100.
5. Click Browse, and then click Modify.
6. Add 100,000 to the current rIDAvailablePool value, and then type the sum into
Values.
7. In Dn, type cn=RID Manager$,cn=System,dc=<domain name>.
8. In Edit Entry Attribute, type rIDAvailablePool.
9. Select Replace as the operation, and then click Enter.
10. Click Run to run the operation.

37
Seizing an operations master role
Use the following procedure to seize an operations master role (also known as a flexible single
master operations (FSMO) role). You can use Ntdsutil.exe, a command-line tool that is installed
automatically on all domain controllers. The following procedure applies to domain controllers that
run Windows Server 2003 or Windows Server 2008.

To seize an operations master role

1. At the command prompt, type the following command, and then press ENTER:
ntdsutil
2. At the ntdsutil: prompt, type the following command, and then press ENTER:
roles
3. At the FSMO maintenance: prompt, type the following command, and then press
ENTER:
connections
4. At the server connections: prompt, type the following command, and then press
ENTER:
Connect to server ServerFQDN
Where ServerFQDN is the fully qualified domain name (FQDN) of this domain controller,
for example: connect to server nycdc01.example.com.
If ServerFQDN does not succeed, use the NetBIOS name of the domain controller.
5. At the server connections: prompt, type the following command, and then press
ENTER:
quit
6. Depending on the role that you want to seize, at the FSMO maintenance: prompt,
type the appropriate command as described in the following table, and then press
ENTER.

38
Role Credentials Command

Domain naming master Enterprise Admins For Windows Server 2003:


Seize domain naming
master
For Windows Server 2008:
Seize naming master

Schema master Schema Admins Seize schema master

Infrastructure master Domain Admins Seize infrastructure


master

PDC emulator master Domain Admins Seize pdc

RID master Domain Admins Seize rid master

After you confirm the request, Active Directory or AD DS attempts to transfer the role.
When the transfer fails, some error information appears, and Active Directory or AD DS
proceeds with the seizure. After the seizure is complete, a list of the roles and the
Lightweight Directory Access Protocol (LDAP) name of the server that currently holds
each role appears.

Note
If this computer was not a RID master before the failure and you attempt to
seize the RID master role, the computer tries to synchronize with a
replication partner before accepting this role. However, because this step is
performed when the computer is isolated, it will not succeed in synchronizing
with a partner. Therefore, a dialog box appears asking you whether you want
to continue with the operation despite this computer not being able to
synchronize with a partner. Click Yes.

Cleaning metadata of removed writable domain


controllers
Metadata cleanup removes Active Directory data that identifies a domain controller to the
replication system. On a domain controller that is running Windows Server 2003 with
Service Pack 1 (SP1), metadata cleanup also removes FRS member and subscriber objects and
attempts to transfer or seize any operations master roles that the retired domain controller holds.
The cleanup process performs these additional processes automatically.
Use the following procedure to delete the domain controller objects for domain controllers that
you plan to add back to the network by reinstalling AD DS.
• Windows Server 2003: Clean metadata of removed writable domain controllers by using
Ntdsutil.exe

39
• Windows Server 2008: Deleting a domain controller using Active Directory Users and
Computers
If you are using the version of Active Directory Users and Computers or Active Directory Sites
and Services that is included in Windows Server 2008 or the Microsoft Remote Server
Administration Tools (RSAT) for Windows Vista, metadata cleanup is performed automatically
when you delete a domain controller object.

Windows Server 2003: Clean metadata of removed writable


domain controllers by using Ntdsutil.exe
1. At a command prompt, type the following command, and then press ENTER:
ntdsutil
2. At the ntdsutil: prompt, type the following command, and then press ENTER:
metadata cleanup
3. Perform metadata cleanup as follows:
If you are performing metadata cleanup by using the version of Ntdsutil.exe that is
included with Windows Server 2003 with SP1, at the metadata cleanup: prompt, type
the following command, and then press ENTER:
remove selected server ServerName
-or-
remove selected server ServerName1 on ServerName2

Value Definition

ServerName, ServerName1 The distinguished name of the domain controller


whose metadata you want to remove, in the form
cn=ServerName,cn=Servers,cn=SiteName,
cn=Sites,cn=Configuration,dc=ForestRootDomain

ServerName2 The DNS name of the domain controller to which


you want to connect and from which you want to
remove server metadata

If you are performing metadata cleanup by using the version of Ntdsutil.exe that is
included with Windows Server 2003 with no service pack, perform metadata cleanup as
follows:
a. At the metadata cleanup: prompt, type the following command, and then press
ENTER:
connection
b. At the server connections: prompt, type the following command, and then press
ENTER:
connect to server Server

40
c. At the server connections: prompt, type the following command, and then press
ENTER:
quit
d. At the metadata cleanup: prompt, type the following command, and then press
ENTER:
select operation target
e. At the select operation target: prompt, type the following command, and then
press ENTER:
list sites
A numbered list of sites appears.
f. At the select operation target: prompt, type the following command, and then
press ENTER:
select site SiteNumber
g. At the select operation target: prompt, type the following command, and then
press ENTER:
list domains in site
A numbered list of domains in the selected site appears.
h. At the select operation target: prompt, type the following command, and then
press ENTER:
select domain DomainNumber
i. At the select operation target: prompt, type the following command, and then
press ENTER:
list servers in site
A numbered list of servers in a domain and site appears.
j. At the select operation target: prompt, type the following command, and then
press ENTER:
select server ServerNumber
k. At the select operation target: prompt, type the following command, and then
press ENTER:
quit
l. At the metadata cleanup: prompt, type the following command, and then press
ENTER:
remove selected server

41
Value Definition

Server The DNS name of a domain controller


that you want to connect to.

SiteNumber The number associated with the site of


the server that you want to clean up that
appears in the list.

DomainNumber The number associated with the domain


of the server that you want to clean up
that appears in the list.

ServerNumber The number associated with the server


that you want to clean up that appears
in the list.

At this point, Active Directory or AD DS confirms that the domain controller was removed
successfully. If you receive an error message that indicates that the object cannot be
found, Active Directory might have already removed the domain controller.
Repeat step 3 to remove metadata for all other domain controllers in each site for the
domain in which this domain controller (the domain controller that is being restored from
backup) is a member.
4. At the metadata cleanup: and ntdsutil: prompts, type the following command, and
then press ENTER:
quit

Windows Server 2008: Deleting a domain controller using Active


Directory Users and Computers
When you use the version of Active Directory Users and Computers in Windows Server 2008,
metadata cleanup is performed automatically when you delete the domain controller object. In
addition, the server object and the computer object are also deleted automatically, which
eliminates the need to perform those additional procedures.
As an alternative, you can also use Active Directory Sites and Services in Windows Server 2008
to delete a domain controller object. If you use Active Directory Sites and Services, you must
delete the associated server object and NTDS Settings object before you can delete the domain
controller object.
If you do not have Windows Server 2008, you can instead download and use the Microsoft
Remote Server Administration Tools for Windows Vista (http://go.microsoft.com/fwlink/?
LinkID=115118) to perform this procedure.

42
To delete a domain controller object using Active Directory Users and Computers in
Windows Server 2008

1. Click Start, click Administrative Tools, and then click Active Directory Users and
Computers.
2. In the console tree, double-click the domain container, and then double-click the
Domain Controllers organizational unit (OU).
3. In the details pane, right-click the domain controller that you want to delete, and then
click Delete.

Removing the failed server object


Use the following procedure to delete the server object of removed domain controllers. You must
perform this procedure only if you used Ntdsutil.exe to perform metadata cleanup.

To remove the failed server object

1. Click Start, point to All Programs, point to Administrative Tools, and then click
Active Directory Sites and Services.
2. In the console tree, expand the Sites container, and then select the appropriate site
that contains the target server.
3. Expand the Servers container, right-click the server object for the domain controller
that you want to remove, and then click Delete.

Removing the failed computer object


Use the following procedure to delete the computer object of removed domain controllers. You
must perform this procedure only if you used Ntdsutil.exe to perform metadata cleanup.

To remove the failed computer object

1. Click Start, click Run, type adsiedit.msc, and then click OK.
By default, the ADSI Edit support tool is connected to this local domain controller.
2. To make the domain container appear in the console tree, click Action, click
Connect to, and then click OK.
3. In the console tree, double-click the default naming context, and then double-click the
domain container.
4. Double-click the OU for Domain Controllers.

Note
If the domain controller computer accounts have been moved out of the
Domain Controllers OU, double-click the container in which they now
reside.

43
5. Right-click the computer object associated with the failed domain controller, and then
click Delete.

Resetting the computer account password of the


domain controller
Use the following procedure to reset the computer account password of the domain controller.
The following procedure applies to domain controllers that run Windows Server 2003 or
Windows Server 2008.

To reset the computer account password of the domain controller

1. At a command prompt, type the following command, and then press ENTER:
netdom help resetpwd
2. Use the syntax that this command provides for using the NetDom command-line tool
to reset the computer account password, for example:
netdom resetpwd /server:<domain controller name> /userD:administrator
/passwordd:*
Where <domain controller name> is the local domain controller that you are recovering.

Note
As mentioned in "Recovery steps," earlier in this guide, you should run this
command twice.

Resetting the krbtgt password


Use the following procedure to reset the krbtgt password for the domain. The following procedure
applies to domain controllers that run Windows Server 2003 or writable domain controllers (not
read-only domain controllers (RODCs)) that run Windows Server 2008.

Important

If you leave RODCs online during the forest recovery, do not delete the krbtgt accounts
for the RODCs. The krbtgt account for an RODC is listed in the format krbtgt_number.

To reset the krbtgt password

1. Click Start, point to Control Panel, point to Administrative Tools, and then click
Active Directory Users and Computers.
2. In the console tree, double-click the domain container, and then click Users.
3. In the details pane, right-click the krbtgt user account, and then click Reset
Password.

44
4. In New password, type a new password, retype the password in Confirm
password, and then click OK.

Notes
As mentioned in "Recovery steps," earlier in this guide, you should perform
this operation twice.

Resetting a trust password on one side of the


trust
Use the following procedure to reset a trust password on one side of the trust. This includes
implicit trusts between child and parent domains as well as explicit trusts between this domain
(the trusting domain) and another domain (the trusted domain).
Reset the password on only the trusting domain side of the trust, known in Windows Server 2003
as the incoming trust (the side where this domain belongs). Then, use the same password on the
trusted domain side of the trust. In Windows Server 2003, this trusted domain is called the
specified domain, and the trust is called the outgoing trust. Reset the password of the outgoing
trust when you restore the first domain controller in each of the other (trusted) domains.

Important

To perform the following procedure, use the latest Netdom.exe command-line tool in the
Windows Server 2003 Service Pack 1 32-bit Support Tools, which you can download
from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=70775), or
use Netdom.exe, which is included in Windows Server 2008 or in the Microsoft Remote
Server Administration Tools for Windows Vista. Do not use older versions of the
Netdom.exe command-line tool.

To reset a trust password on one side of the trust

1. At a command prompt, type the following command, and then press ENTER:
netdom experthelp trust
2. Use the syntax that this command provides for using the NetDom tool to reset the
trust password.
For example, if there are two domains in the forest—parent and child—and you are
running this command on the restored domain controller in the parent domain, use the
following command syntax:
netdom trust <parent domain name> /domain:<child domain name>
/resetOneSide /passwordT:<password> /userO:administrator /passwordO:*
When you run this command in the child domain, use the following command syntax:
netdom trust <child domain name> /domain:<parent domain name>

45
/resetOneSide /passwordT:<password> /userO:administrator /passwordO:*

Note
passwordT should be the same value on both sides of the trust. Run this
command only once (unlike the netdom resetpwd command) because it
automatically resets the password twice.

Adding the global catalog


Use the following procedure to add the global catalog to a domain controller. The following
procedure applies to domain controllers that run Windows Server 2003 or Windows Server 2008.

To add the global catalog

1. Click Start, point to All Programs, point to Administrative Tools, and then click
Active Directory Sites and Services.
2. In the console tree, expand the Sites container, and then select the appropriate site
that contains the target server.
3. Expand the Servers container, and then expand the server object for the domain
controller to which you want to add the global catalog.
4. Right-click NTDS Settings, and then click Properties.
5. Select the Global Catalog check box.

The following are ways to speed up the process of adding the global catalog to the domain
controller in the root domain:
• Ideally, the domain controller in the root domain should be a replication partner of the
restored domain controllers in the nonroot domains. If so, confirm that the Knowledge
Consistency Checker (KCC) has created the corresponding repsFrom object for the source
domain controller and partition in the root domain controller. You can confirm this by running
the repadmin /showreps /v command.
• If there is no repsFrom object created, create this object for the configuration partition.
This way, the domain controller in the root domain can determine which domain controllers in
the nonroot domain have been deleted. You can do this with the following commands:
repadmin /options DSA +Disable_NTDSCONN_XLATE
repadmin /add ConfigurationNamingContext DestinationDomainController
SourceDomainControllerCNAME
repadmin /options DSA -Disable_NTDSCONN_XLATE
The format for the SourceDomainControllerCNAME is:
sourceDCGuid._msdcs.<root domain>
For example, the repadmin /add command for the configuration partition of the contoso.com
domain could be:

46
repadmin /add cn=configuration,DC=contoso,DC=com DC01 937ef930-7356-43c8-88dc-
8baaaa781cf6._msdcs.dDSP17A22.contoso.com

• If the repsFrom object is present, try to sync the domain controller in the root domain
with the domain controller in the nonroot domain as follows:
repadmin /sync DomainNamingContext DestinationDomainController
SourceDomainControllerGUID
Where DestinationDomainController is the domain controller in the root domain and
SourceDomainController is the restored domain controller in the nonroot domain.
• The root domain DNS server should have the alias (CNAME) resource records for the
source domain controller. Ensure that the parent DNS zone contains delegation resource
records (name server (NS) and host (A) resource records) for the correct domain controllers
(the domain controllers that have been restored from backup) in the child zone.
• Make sure that the domain controller in the root domain is contacting the correct Key
Distribution Center (KDC) in the nonroot domain. To test this, at the command prompt, type
the following command, and then press ENTER:
run nltest /dsgetdc:<nonroot domain name> /KDC

Appendix B: Frequently Asked Questions


This appendix contains frequently asked questions (FAQs) regarding forest recovery:
• What can I do to speed up recovery?
• Can I automate the forest recovery process?
• Can I restore more than one domain controller from backup in each domain?
• Can I restore a global catalog server at an earlier stage?
• Should I install AD DS by using the regular dcpromo routine or IFM?

What can I do to speed up recovery?


Although speed of recovery is not the primary goal of this guide, you can achieve shorter
recovery times by deploying read-only domain controllers (RODCs) and by creating a detailed
forest recovery plan, updating it on a regular basis, and practicing it in a simulated test
environment of reasonable size at least once a year.
RODCs can provide business continuity during the recovery process because they do not have to
be disconnected from the network as writable domain controllers do. RODCs do not perform
outbound replication. Therefore, they do not present the same risk that writable domain
controllers pose for replicating damaging data back into the recovered environment.
If you use RODCs, you can reduce the complexity and the time required to complete the forest
recovery because you can focus your initial effort on recovering only writable domain controllers.
In a hub-and-spoke deployment with many branch offices, writable domain controllers can be a
small percentage of the total number of domain controllers that you deploy.

47
Accounts that are cached on RODCs can continue to be authenticated and authorized to access
resources while you recover the writable domain controllers. After writable domain controllers are
recovered, you can rebuild RODCs by removing and reinstalling Active Directory Domain
Services (AD DS). Rebuilding RODCs ensures that they do not contain any lingering objects,
which can help prevent replication conflicts from occurring later.
Only domain controllers that run Windows Server 2008 or Windows Server 2008 R2 can be
RODCs.
Other factors that affect the duration of the forest recovery process include the following:
• When you restore domain controllers from backups, it takes time to:
• Locate the physical backup media, such as tapes.
• Reinstall the operating system.
• Restore data from backup media.
You can reduce the time required to reinstall the operating system and restore data from
backup by performing full server recovery instead of system state restore. Because full server
recovery is binary-based, it completes much faster than system state restore.
However, if the server contains data that is excluded from system state data that you do not
want to restore, full server recovery might not be a viable alternative to system state restore.
Consider the advantages of performing a full server recovery instead of a system state
restore for your servers specifically, and prepare accordingly by performing the appropriate
type of backup that you plan to restore later.
• When you rebuild domain controllers, it takes time to replicate data for network-based
promotions.
You can decrease the time required for restoring domain controllers by performing the following
steps:
• Reduce the time for retrieving backup media by:
• Using the Active Directory Database Mounting Tool (Dsamain.exe) to identify the best
backup to use for restore operations. For more information about using the
Active Directory Database Mounting Tool, see the Active Directory Database Mounting
Tool Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=132577).
• Labeling the backup media clearly and storing the media in an organized fashion at a
convenient, yet secure, location that allows fast retrieval.
• Using the Volume Shadow Copy Service with a storage area network (SAN) to
maintain backups from different points in time. For more information, see
Windows Server 2003 Active Directory Fast Recovery with Volume Shadow Copy Service
and Virtual Disk Service (http://go.microsoft.com/fwlink/?LinkId=70781). As an alternative,
you can use the ntdsutil snapshot command to create snapshots of the Active Directory
database. For more information about using the ntdsutil snapshot command, see the
Active Directory Database Mounting Tool Step-by-Step Guide
(http://go.microsoft.com/fwlink/?LinkId=132577) and see Snapshot
(http://go.microsoft.com/fwlink/?LinkId=132578).

48
• Force the removal of AD DS from the domain controllers instead of reinstalling the
operating system. If the cause of the forest-wide failure has been identified to be purely within
the scope of AD DS, you do not have to reinstall the operating system on the domain
controllers. Instead, you can run the following command to force the removal of AD DS from
the domain controllers:
dcpromo /forceremoval
For more information about forcing the removal of AD DS from a domain controller that runs
Windows Server 2003, see article 332199 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkId=70780). For more information about forcing the
removal of AD DS from a domain controller that runs Windows Server 2008, see Forcing the
Removal of a Windows Server 2008 Domain Controller (http://go.microsoft.com/fwlink/?
LinkId=132627).
• Use faster tape devices or disk backups to reduce the time that is required for restore
operations.
You can also help accelerate the forest recovery process by using the Install from Media (IFM)
feature to rebuild domain controllers in each domain. IFM reduces the replication latency that is
incurred when you rebuild domain controllers in each domain. For more information, see Should I
install AD DS by using the regular dcpromo routine or IFM? later in this appendix.
Businesses that have a more aggressive service-level agreement (SLA) might consider altering
the forest recovery procedures to speed recovery. The following are possible approaches.
However, each approach is associated with some level of risk of reintroducing dangerous data
into the recovered forest:
• Automate some or all forest recovery steps using thoroughly tested scripts. For more
information, see Can I automate the forest recovery process? later in this appendix.
• Restore multiple domain controllers from backups in each domain. This also reduces
replication latency that is incurred when you use Dcpromo.exe to rebuild domain controllers in
each domain. For more information, see Can I restore more than one domain controller from
backup in each domain? later in this appendix.
• Restore global catalog servers from backups directly, and remove lingering objects later
by using the repadmin /removelingeringobjects command. This approach is the most
complex and therefore the most error prone of these three options. You should consider it
only as a last resort to meet an aggressive forest recovery timeline. For more information, see
Can I restore a global catalog server at an earlier stage? later in this appendix.
Refer to the following FAQs for more detailed explanations of each of these approaches.

Can I automate the forest recovery process?


Because of the complex and critical nature of the forest recovery process, there is currently no
end-to-end automation of it. The forest recovery process is more a logistical and organizational
challenge of recovering business continuity than a technical problem of process automation.
Therefore, the individual who administers the environment should create a forest recovery plan

49
that is specific to that environment and then automate sections of it that can be automated
successfully.
You can perform most of the forest recovery steps by using command-line tools. Therefore, most
of the steps are scriptable. For example, Ntdsutil.exe is one of the most frequently used tools in
the forest recovery process. This tool has been greatly enhanced in Windows Server 2003 with
Service Pack 1 (SP1) and later Windows Server operating systems for easier scripting and
improved metadata cleanup. For more information about improvements to Ntdsutil in
Windows Server 2003 with SP1, see Active Directory Directory Services Maintenance Utility
(ntdsutil.exe) (http://go.microsoft.com/fwlink/?LinkId=70810). For more information about using
Ntdsutil in Windows Server 2008, see Ntdsutil (http://go.microsoft.com/fwlink/?LinkId=132629).
Although scripts can speed recovery, you must thoroughly test these scripts before you apply
them in a real environment. Also, you must update them according to changes in the
Active Directory environment, such as the addition of a new domain or domain controller.

Can I restore more than one domain controller


from backup in each domain?
This guide recommends restoring only one domain controller from a good backup in each
domain. Assuming that the backup has been tested thoroughly, you can be confident that the
domain being rebuilt is safe. This is because all the remaining domain controllers in the domain
replicate Active Directory data from a healthy, authoritative domain controller.
However, if you have to rebuild many domain controllers in each domain, the business cost of the
unavailability of those domain controllers can be quite exorbitant. If you have multiple good
backups for each domain, consider restoring multiple domain controllers from backups to reduce
replication overhead. However, also consider the following:
• You must test each backup thoroughly. Restoring multiple domain controllers from
backup is riskier than restoring a single domain controller from backup. This is especially true
when the source of the forest-wide failure is not obvious because there is a higher chance
that you will reintroduce dangerous data into the restored forest. Backups of various domain
controllers can take place at different times; therefore, they can hold different Active Directory
states. For a nonauthoritative restore operation, objects that are recovered from the most
recent backup take precedence in replication because they have a more recent time stamp.
Also, restoring backups that were taken at different times increases the likelihood of
introducing lingering objects on global catalog servers.
The Active Directory Database Mounting Tool (Dsamain.exe) can help you test backups
because you can use this tool to view the data that is contained in the backup without having
to restore the backup. For more information about using the Active Directory Database
Mounting Tool, see the Active Directory Database Mounting Tool Step-by-Step Guide
(http://go.microsoft.com/fwlink/?LinkId=132577).
• You should designate one domain controller in each domain and, if the domain controller
is running Windows Server 2003, mark only this restored domain controller as primary for

50
SYSVOL in the domain. If the domain controller is running Windows Server 2008, you can
use Wbadmin.exe to perform an authoritative restore of SYSVOL.
Use the following forest recovery procedures to restore multiple domain controllers from backups
in the forest root domain and other domains.
Complete the following steps to recover the forest root domain:
1. For the first domain controller that you restore from backup in the forest root domain, do
the following:

Note

The following steps are similar to the steps for restoring only one domain
controller in the forest root domain. The differences are that the steps for
cleaning metadata, deleting server and computer objects, and resetting trust
passwords are postponed until all domain controllers that you plan to restore
from backup for this domain are restored.
a. While you restore AD DS, mark SYSVOL as the primary data to be restored or
perform an authoritative restore of SYSVOL, because this is the first domain controller in
the domain.
b. After you restore and restart the domain controller, verify that the failure did not affect
the data on the domain controller. If the domain controller data is damaged, repeat step a
by using a different backup.
Continue to the next step only after you restore and verify the data—and before you join
this computer to the production network.
c. If you have Domain Name System (DNS) zones for this domain that are stored in
AD DS, ensure that the local DNS Server service is installed and running on the domain
controller that you have restored. Configure this server with its own IP address (or a
loopback address, such as 127.0.0.1) as its preferred DNS server. You can configure this
in the TCP/IP properties of the local area network (LAN) adapter. This is the first DNS
server in the forest.
d. If the restored domain controller was a global catalog server before the failure, clear
the global catalog check box to remove the global catalog from the domain controller.
e. Raise the value of the available relative ID (RID) pools by 100,000.
f. Seize all domain-wide and forest-wide operations master roles (also known as
flexible single master operations (FSMO) roles). Although you might retain the operations
master roles on the restored domain controller only temporarily, seizing these roles
assures that you know which domain controller hosts each role at this point in the forest
recovery process. As part of your postrecovery process, you can redistribute the
operations master roles as needed.
g. Reset the computer account password of this domain controller twice.
h. Reset the krbtgt password twice.
2. For other domain controllers that you restore from backups in the forest root domain,
complete the following steps on each of these domain controllers:

51
Note

The following steps are similar to the steps for restoring the first domain
controller in the domain, except that you do not have to raise the RID pool and
seize the operations master roles again. These steps are domain-wide
operations that you already performed when you restored the first domain
controller in this domain.
a. After you restore and reboot the domain controller, verify that the data on the domain
controller was not affected by the failure. If the domain controller data is damaged, repeat
step a by using a different backup.
Continue to the next step only after you restore and verify the data and before you join
this computer to the production network.
b. Configure this domain controller with the IP address of the first DNS server in the
forest root domain as its preferred DNS server in the TCP/IP properties of the local area
network adapter.
c. If the restored domain controller is added as a global catalog server, remove the
global catalog.
d. Reset the computer account password of this domain controller twice.
e. Reset the krbtgt password twice.
3. Complete the following steps after you restore all the selected domain controllers from
backups in the forest root domain:
a. Clean up metadata for all other domain controllers in the domain that you plan to
create by reinstalling AD DS (that is, for all domain controllers in the domain except those
domain controllers that are restored from backups). You can clean up metadata most
simply by using the version of Active Directory Users and Computers that is included with
Windows Server 2008 or by using the Microsoft Remote Server Administration Tools
(RSAT) for Windows Vista.
b. Delete server and computer objects for all other domain controllers in the domain that
you plan to create by reinstalling AD DS (that is, for all domain controllers in the domain
except those domain controllers that are restored from backups). If you used the version
of Active Directory Users and Computers that is included with Windows Server 2008 or
RSAT to clean up metadata, you can skip this step.

Important

You must clearly identify the domain controllers in the domain that you will be
creating by reinstalling AD DS instead of restoring them from backup. You
clean up metadata for and delete server and computer objects only for those
domain controllers that you will be creating by reinstalling AD DS.
c. Reset the trust password (Trusted Domain Object password) twice for all trusts
between this domain and all other trusted domains.
Complete the following steps to recover each of the remaining domains.

52
1. For the first domain controller that you restore from backup in the domain, complete the
following steps:

Note

The following steps are similar to the steps for restoring only one domain
controller in each of the remaining domains. The differences are that the steps for
cleaning metadata, deleting server and computer objects, and resetting trust
passwords are postponed until all domain controllers that you plan to restore
from backup for this domain are restored.
a. Restore AD DS on the first domain controller in each domain. While you are restoring
AD DS, mark SYSVOL as the primary data to be restored or perform an authoritative
restore of SYSVOL, because this is the first domain controller in the domain.
b. After you restore and restart the domain controller, verify that the failure did not affect
the data on the domain controller. If the domain controller data is damaged, repeat step a
by using a different backup.
Continue to the next step only after you restore and verify the data—and before you join
this computer to the production network.
c. If you have DNS zones that are stored in AD DS, ensure that the local DNS Server
service is installed and running on the domain controller that you have restored.
Configure this server with the IP address of the first DNS server in the forest root domain
as its preferred DNS server. You can configure this in the TCP/IP properties of the LAN
adapter.
d. Ensure that the parent DNS zone contains delegation resource records (name server
(NS) and host (A) resource records) for the child DNS zone that is hosted on this DNS
server.
e. If the restored domain controller was a global catalog server before the failure, clear
the global catalog check box to remove the global catalog.
f. Raise the value of the available RID pools by 100,000.
g. Seize all domain-wide operations master roles to this domain controller.
h. Reset the computer account password of this domain controller twice.
i. Reset the krbtgt password twice.
2. For other domain controllers that you want to restore from backups in the domain,
complete the tasks in step 2 of the process for recovering the forest root domain, as
explained earlier in this section, on each of these domain controllers.
3. After you restore all the selected domain controllers from backups in the domain,
complete the actions in step 3 of the process for recovering the forest root domain, as
explained earlier in this section.
4. Make the domain controller in the root domain a global catalog server.
5. Recover additional domain controllers in the forest by installing AD DS.

53
Can I restore a global catalog server at an earlier
stage?
You should remove the global catalog when you restore domain controllers and then wait until all
the restored domain controllers are joined back to the network before you make selected domain
controllers global catalog servers. This prevents the introduction of lingering objects, which can
cause replication inconsistencies. This in turn can cause AD DS and applications that depend on
AD DS to malfunction.
However, you might face the following issues before you add a global catalog server:
• Domain controllers cannot register certain DNS records because secure dynamic
updates fail.
• Disabling and re-enabling a global catalog server can take a long time.
• AD DS installation might fail.
• Microsoft Outlook needs a global catalog server for global address list lookups.
• Certain operations master roles cannot be seized.
You might find that restoring a single global catalog server from backup in the forest root domain
can alleviate these issues. You can remove lingering objects as a postrecovery step by using
Repadmin.exe.
Although restoring a global catalog server from backups directly is not a best practice, you might
find this approach necessary to meet an aggressive forest recovery timeline. Consider the
following issues before using this approach:
• Restoring a global catalog server from backup results in lingering objects and causes
replication inconsistencies.
• If lingering objects are introduced, you must perform an extra postrecovery step to
remove them.
• You must take extra care when you verify a global catalog server backup. A restored
global catalog server not only contains the restored data for its domain but also some data for
all the other domains in the forest. Therefore, restoring a global catalog server has a much
higher risk of reintroducing dangerous data into the restored forest.
However, you can prevent the introduction of lingering objects if you restore domain
controllers and global catalogs from backups that are taken at the same time (or relatively
close in time). This way, there is no discrepancy between the authoritative domains and their
partial replicas in the restored global catalogs.

Should I install AD DS by using the regular


dcpromo routine or IFM?
Another way to reduce replication overhead in the forest recovery process is to rebuild domain
controllers by using Install from Media (IFM). IFM is an option that allows you to use media as an
AD DS installation source instead of replicating all AD DS data over the network. You can create
the installation media by using either of the following methods:

54
• Run the ntdsutil ifm command on a domain controller that runs Windows Server 2008.
For more information about running the ntdsutil ifm command, see Installing Active Directory
Domain Services from Media (http://go.microsoft.com/fwlink/?LinkId=132630).
• Back up the source domain controller to a removable medium, ship the backup to the
location, and restore the backup on the target computer.
Then, you can source the partitions from the installation medium by running the dcpromo /adv
command or by specifying the location of the installation media on the Install From Media page
in the Active Directory Domain Services Installation Wizard. You must select the Use advanced
mode installation check box on the Welcome page of the wizard for the Install from Media
page to appear.
Keep the following in mind if you plan to use IFM:
• Although you might avoid replication latency of Active Directory data by using IFM, you
must still replicate SYSVOL information.

Note

By default, IFM uses only the Active Directory database; SYSVOL data must still
be replicated over the network. With additional configuration, you can avoid this
situation for the third restored domain controller and subsequent domain
controllers. For more information, see “Seeding the SYSVOL tree from restored
files during IFM promotion” in article 311078 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkId=74557).
• Depending on the size of the Active Directory database and the availability and cost of
the wide area network (WAN) link between the source and target domain controllers, IFM
might or might not be a better solution. IFM is targeted at branch office scenarios in which
network bandwidth is expensive, unstable, and limited. However, the regular Dcpromo routine
is more suitable for promoting domain controllers within the same site where network
bandwidth is not so limited.
• Before you back up a donor domain controller or run the ntdsutil ifm command on a
Windows Server 2008 domain controller for the purpose of IFM, consider running the
following commands to perform checksum and integrity verifications of the Active Directory
database. You can use ntdsutil to run these commands, but you must stop AD DS.
If the domain controller runs Windows Server 2003, run the following commands:
Checksum Verification: esentutl /k
Integrity Check: esentutl /g
If the domain controller runs Windows Server 2008, run the following commands:
a. Run the following command to stop AD DS:
net stop ntds
b. Run the following commands to perform the checksum verification and the integrity
check:
ntdsutil

55
ntdsutil: activate instance ntds
ntdsutil: files
file maintenance: checksum
file maintenance: Integrity
file maintenance: q
ntdsutil: q
c. Run the following command to restart AD DS:
net start ntds
Although these operations might be time consuming to run, they can prevent certain types of
database corruptions, such as a lost page flush, from propagating from the source domain
controller to the target domain controllers. A domain controller that is installed by means of
AD DS replication is less susceptible to these database corruptions because stringent
semantic checks are built into full replications. A domain controller that is installed by IFM only
replicates information incrementally. Furthermore, it presumes that all data that comes from
the donor domain controller is safe.

Additional Resources
This section contains additional resources related to forest recovery.
The following resources are useful for recovering domain controllers that run
Windows Server 2008:
• Microsoft Remote Server Administration Tools for Windows Vista
(http://go.microsoft.com/fwlink/?LinkID=115118)
• Active Directory Database Mounting Tool Step-by-Step Guide
(http://go.microsoft.com/fwlink/?LinkId=132577)
• Ntdsutil (http://go.microsoft.com/fwlink/?LinkId=132629)
• Snapshot (http://go.microsoft.com/fwlink/?LinkId=132578)
• Forcing the Removal of a Windows Server 2008 Domain Controller
(http://go.microsoft.com/fwlink/?LinkID=132627)
• Installing Active Directory Domain Services from Media (http://go.microsoft.com/fwlink/?
LinkId=132630)
• Performing an Unscheduled Backup of a Domain Controller
(http://go.microsoft.com/fwlink/?LinkId=132632)
• Performing a Nonauthoritative Restore of AD DS (http://go.microsoft.com/fwlink/?
LinkId=132637)
The following resources are useful for recovering domain controllers that run
Windows Server 2003:

56
• Active Directory Disaster Recovery (http://go.microsoft.com/fwlink/?LinkId=70773). All
procedures in the document apply to both Microsoft Windows 2000 Server and
Windows Server 2003.
• Windows Server 2003 Service Pack 1 32-bit Support Tools
(http://go.microsoft.com/fwlink/?LinkId=70775)
• DNS Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=74561)
• Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller
(http://go.microsoft.com/fwlink/?LinkId=70776)
• Clean up server metadata (http://go.microsoft.com/fwlink/?LinkId=70779)
• Microsoft Knowledge Base article 332199, Domain controllers do not demote gracefully
when you use the Active Directory Installation Wizard to force demotion in
Windows Server 2003 and in Windows 2000 Server (http://go.microsoft.com/fwlink/?
LinkId=70780)
• Windows Server 2003 Active Directory Fast Recovery with Volume Shadow Copy Service
and Virtual Disk Service (http://go.microsoft.com/fwlink/?LinkId=70781)
• Use Repadmin to remove lingering objects (http://go.microsoft.com/fwlink/?LinkId=70782)
• Active Directory in Windows Server 2003 Service Pack 1 (http://go.microsoft.com/fwlink/?
LinkId=70783)
• Active Directory Directory Services Maintenance Utility (ntdsutil.exe)
(http://go.microsoft.com/fwlink/?LinkId=70810)
• How Operations Masters Work (http://go.microsoft.com/fwlink/?LinkId=70799)
• How Domain Controllers Are Located in Windows (http://go.microsoft.com/fwlink/?
LinkId=70800)
• Best practices for DNS client settings in Windows 2000 Server and in
Windows Server 2003 (http://go.microsoft.com/fwlink/?LinkId=70801)
• Microsoft Knowledge Base article 315457, How to rebuild the SYSVOL tree and its
content in a domain (http://go.microsoft.com/fwlink/?LinkId=70802)
• Microsoft Knowledge Base article 216498, How to remove data in Active Directory after
an unsuccessful domain controller demotion (http://go.microsoft.com/fwlink/?LinkId=70803)
• Microsoft Knowledge Base article 311078, How to use the Install from Media feature to
promote Windows Server 2003–based domain controllers (http://go.microsoft.com/fwlink/?
LinkId=74557)
• Windows Server 2003 Active Directory Diagnostics, Troubleshooting, and Recovery
(http://go.microsoft.com/fwlink/?LinkId=70804)
• Windows Server 2003 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=70805)
• Microsoft Knowledge base article 840001, How to restore deleted user accounts and their
group memberships in Active Directory (http://go.microsoft.com/fwlink/?LinkId=70806)
• Back up a Group Policy object using GPMC (http://go.microsoft.com/fwlink/?
LinkId=70807)

57
• Enterprise Management with the Group Policy Management Console
(http://go.microsoft.com/fwlink/?LinkId=70808)

58