Best Practice Recommendation

for Recovering your

Active Directory Forest
Microsoft Corporation
Published: June 2002

Abstract

This paper is a best practice recommendation for recovering an Active Directory forest after
forest-wide failure has rendered all domain controllers (DCs) in the forest incapable of functioning
normally. The steps describe how to restore the entire Active Directory forest to a point in time
before the critical malfunction and ensure that each of the recovered DCs does not replicate from
a DC with potentially dangerous data.

The information contained in this document represents the current

view of Microsoft Corporation on the issues discussed as of the date
of publication. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the
part of Microsoft, and Microsoft cannot guarantee the accuracy of
any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT
MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE
INFORMATION IN THIS DOCUMENT.
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.
The example companies, organizations, products, people and
events depicted herein are fictitious. No association with any real
company, organization, product, person or event is intended or
should be inferred.
2002 Microsoft Corporation. All rights reserved.
Microsoft, and Active Directory are either registered trademarks or
trademarks of Microsoft Corporation in the United States and/or
other countries.

Contents
Introduction......................................................................................................................................................
Recovering Your Active Directory Forest.......................................................................................................
Recovery Roadmap
Pre-Recovery Steps
Recovery Steps
Post-Recovery Steps

Appendix I: Pre-Recovery Steps...................................................................................................................

A. Selecting a candidate domain controller
B. Understanding the forest recovery time-line

Appendix II: Steps to backup and restore a domain controller..................................................................

To backup a domain controller using the Windows 2000 backup utility
To perform a non-authoritative restore using the Windows 2000 backup utility

Appendix III: Tasks Performed during Recovery.........................................................................................

To install the DNS Server service
To disable a Global Catalog
To raise the current RID pool
To seize an Operation Master role
To clean metadata of removed DCs
To delete server and computer objects of removed DCs
To reset machine account password of the DC
To reset krbtgt password
Reset trust passwords on one side of the trust
To enable the DC in the root domain to be a Global Catalog

Related Links..................................................................................................................................................

Introduction
While there are recovery procedures in place for cases where one or more directory objects have
been accidentally deleted (namely, authoritative restore) or where hardware failure (for example,
disk corruption) causes a domain controller (DC) to fail, this paper is a best practice
recommendation for recovering an Active Directory forest after forest-wide failure has rendered
all DCs in the forest incapable of functioning normally.
This paper assumes that the Active Directory administrator has worked with Microsoft Product
Support (PSS) to determine the cause of the failure, evaluated any possible remedies, and
reached the conclusion that restoring the whole forest to a point in time before the failure
occurred is the best way to recover from the failure. In many cases, total Active Directory forest
restoration should be the last option. This paper does not suggest a cause of such a failure or
recommend any procedures to prevent the failure.
It is assumed that the Active Directory administrator is aware of fundamental Active Directory
concepts and the importance of operations master roles (also known as a flexible single master
operation or FSMO), such as schema master, domain naming master, RID master, PDC emulator,
and infrastructure master. In addition, the Active Directory administrator should be aware of how
to backup and restore Active Directory and the SYSVOL (both of which are part of System State)
and have performed this procedure in a lab environment on a regular basis. For these and other
backup and restore best practices, refer to the Active Directory Disaster Recovery document
(http://www.microsoft.com/windows2000/docs/disaster.doc).
The paper assumes that you have followed the Microsoft Best Practice Recommendations for
using Active Directory-integrated DNS where there is an Active Directory-integrated DNS zone for
each Active Directory domain. If this is not the case, you could still use the basic tenets of this
paper to perform forest recovery. While the objective of this paper is to recover the Active
Directory forest and maintain or restore full DNS functionality, recovery can result in a DNS
configuration that is changed from the pre-failure configuration. Once the Active Directory forest is
restored, you can revert back to the original DNS configuration. These recommendations do not
provide a description on how to configure DNS servers to perform name resolution of other
portions of the corporate namespace where there are DNS zones not stored in Active Directory.

Recovering Your Active Directory Forest

Recovering the entire Active Directory forest involves restoring every DC in the forest. Recovery
will take place from either backup or by reinstalling Active Directory using the Active Directory
Installation Wizard. Recovering the forest effectively restores each domain in the forest to the
time when the last trusted backup was performed. Consequently, the restoration procedure will
result in the loss of at least the following Active Directory data:

All objects (users, computers, etc.) that were added after the last trusted backup.

All updates made to existing objects since the last trusted backup.

Additionally, assuming that all the DCs in the forest no longer function correctly, any software
applications that were running on the DCs will need to be reinstalled on the DCs after the forest is
recovered.
Recovery Roadmap
This section provides an overview of the path recommended for recovering an Active Directory
forest.

It is important to understand the recovery roadmap before proceeding with the Active Directory forest
recovery steps, which are described in detail later.

General steps in the recovery process:

1.

Recover the forest root domain first.

The forest root domain is very important because it stores the Schema Admins and Enterprise
Admins groups. It also helps maintain the trust hierarchy in the forest. Additionally, as the forest
root domain holds the DNS root server for the forests DNS namespace, the Active
Directory-integrated DNS zone for that domain will contain the CNAME records for all other
DCs in the forest (which are required for replication) and the global catalog DNS resource
records.

2.

Recover the remaining domains in the forest.

You can restore more than one domain at the same time; however, always restore a parent
domain before restoring a child to prevent any break in the trust hierarchy or DNS name
resolution.

For each domain that you recover:

Restore only one DC from backup.

This is the most important part of the recovery because the DC 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 Active Directory on the remaining DCs using the Active Directory Installation
Wizard.
Installing Active Directory, although more time consuming than restoring from backup, is
safer because you will restore the entire domain to the point where the first DC in the
domain was restored. By verifying that the first DC does not contain potentially
dangerous data, you are assured that subsequent DCs will not contain dangerous data
as a result of replication from the trusted DC. If you restored every DC from backup, you
would have to verify that each of the restored DCs does not reintroduce dangerous data
into the Active Directory forest.

The following sections describe the exact steps for the Active Directory administrator to follow
while recovering a forest. The steps are grouped into three sections: Pre-recovery, Recovery and
Post-recovery. While these sections give a conceptual view of the recovery process, the
procedures to perform these steps are described in Appendix III.
Pre-Recovery Steps
Before starting the recovery process, the Active Directory administrator will perform the following
steps. It is assumed that all DCs in the Active Directory forest are not functional at this point.
To perform pre-recovery
1.

Determine the current forest structure by identifying all domains in the forest and making a list
of all of the DCs in each domain, particularly the DCs that have backups. Most importantly, the
administrator will need to identify the forest root domain because this domain will be restored
first. Once the forest root domain is restored, a list of the domains, sites, and DCs in the forest
can be obtained using Active Directory Domains and Trusts and Active Directory Sites and
Services.
Additionally, an administrator account password will be 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 DC.
It can be useful to prepare a table of domains and DCs in each domain and a list of their
functions as described in Appendix I-A. This list will help the administrator to revert back to the
pre-failure topology of the forest once the forest recovery is completed.

2.

For each domain in the forest, identify a single DC that has a trusted backup of the Active
Directory database for that domain.
It is very important that the single DC (per domain) to be restored from backup does not
contain any potentially dangerous data. Use caution when choosing a backup to restore a DC.
If the day and cause of the failure are approximately known, the general recommendation
would be to use a backup that was made a few days before that date.

3.

Shut down all DCs in the forest.

All DCs should be shut down before the first recovered DC is brought back into production.

This ensures that any dangerous data does not replicate back into the restored forest. It is
particularly important to shut down all FSMO role holders.
In a large forest that is spread across multiple locations, it can be difficult to guarantee that all
DCs are shut down. For this reason, the recovery steps have been designed to ensure that the
recovered DCs do not replicate with dangerous DCs (in case some are still online in the forest).
At this point, the administrator will have a list of exactly one DC per domain in the forest that will
be used to restore from backup. The administrator will install Active Directory on the remaining
servers after the first DC in each domain is restored using backup data, and, at this point, the
administrator will begin to reinstall the operating system on the remaining DCs and prepare them
for the installation of Active Directory. Refer to Appendix I B for a timeline of events.
Recovery Steps
Restore the first DC for the forest root domain

Perform the following steps while the restored machine is physically isolated (i.e. its network cable
is not attached and therefore it is not connected to the production network). Procedures for performing
these steps are present in Appendix III.

1. While restoring Active Directory, mark the SYSVOL primary since this is the first DC in the
domain.
2. After restoring and rebooting the DC, verify that the data on the DC was not affected by the
failure. If the DC data is damaged, then repeat step 1 using a different backup.
Continue to step 3 only after restoring and verifying the data, and before joining this
computer onto the production network.
3. If you have DNS zones stored in Active Directory, then you need to ensure that the local DNS
Server service is installed and running on the DC that you have restored. This server should
be configured with its own IP address as its preferred DNS server, which is configured in its
TCP/IP properties. This is the first DNS server in the forest.

If this DC was not a DNS server prior to forest failure, then follow steps for configuring DNS in Appendix III.

4. If the restored DC is enabled as a global catalog, then disable the global catalog flag.

Restoring a global catalog from backup could result in the global catalog holding newer data for one of its
partial replicas than the corresponding domain (the domain that is authoritative for that partition). In such a
case, the newer data would not be removed from the global catalog and might even replicate to other global
catalogs. As a result, even if you did restore a DC that was a global catalog, either inadvertently or because
that was the solitary backup you trusted, you should disable the global catalog soon after the restore is
completed. Disabling the global catalog flag will result in the computer losing all its partial replicas
(partitions) and relegating itself to a regular DC.

5. Raise the value of the current RID pool by 100,000.

After the backup was taken, new security principals might have been created in the domain. These security
principals might have access rights on certain objects. These security principals no longer exist because the
recovery has reverted to the backup, but their access rights might still exist. If the RID pool is not raised after
a restore, new users 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.

6. Seize all domain- and forest-wide operation master (FSMO) roles. Seizing these roles will
give the administrator an idea of where the roles are present.

There are some cases when you will not be allowed to seize a particular role. It does not matter if you
cannot seize a particular role. You can always seize or transfer the role as part of the post-recovery steps.
For example, if a machine is not a GC, you will not be able to seize the domain naming master role. Only a
GC can hold the domain naming master role.
If your domain was in native mode (DCs running Windows NT 4.0 or earlier are not supported), and if this
DC was not a GC prior to recovery, you will not be able to seize the schema master role on this DC. This is
because schema and enterprise admin groups are universal groups (in native mode) and in the absence of
a GC, your login security token does not contain the SIDs of any universal groups.

7. Clean up metadata of all other DCs in the forest root domain which you are restoring from
backup, except for this DC.

Cleaning up metadata prevents possible duplication of NTDS-settings objects if Active Directory is installed
on a DC in a different site. Potentially, this could also save the Knowledge Consistency Checker (KCC) the
process of creating replication links when the DCs themselves might not be present. Moreover as part of
metadata cleanup, DNS locator resource records for all other DCs in the domain will be deleted from DNS.
Until the metadata of all other DCs in the domain is removed, this DC, if it were a RID master before
recovery, will not assume its role and hence will not be able to issue new RIDs. You might see event ID
16650 in the System event log, indicating this failure, but you should see event ID 16648 indicating success
a little while after you have cleaned the metadata.

8. Delete server and computer objects for all other DCs in the forest root domain which you
are restoring from backup, except for this DC.

These objects are not required because you will be installing Active Directory on all other DCs and, as a
result, creating new computer and server objects.

9. Reset the computer account password of this DC twice.

10. Reset the krbtgt password twice.

The reason for resetting passwords twice is to remove the original (pre-malfunction) password from
password history (assuming that the default password history is 2).
Steps 8-10 ensure that the DC does not replicate with potentially damaged DCs in the same domain. Since
subsequent DCs in the domain are recovered using the Active Directory Installation Wizard, they will
automatically replicate these new passwords during the installation process.

11. Reset the trust password twice (Trusted Domain Object password) for all trusts between this
domain and all other trusted domains.
This includes implicit trusts between child and parent domains as well as explicit trusts
created between this domain and another domain. Reset the password on only the trusting
domain side of the trust (the side where this domain belongs) and then use the same
password on the trusted domain side of the trust. The latter is done when you restore the first
DC in each of the other (trusted) domains.

Resetting the trust password ensures that the DC does not replicate with potentially bad DCs outside of its
domain. By setting the same trust password while restoring the first DC in each of the non-root domains, you
will ensure that this DC will replicate with each of the recovered DCs. Since subsequent DCs in the domain
are recovered using the Active Directory Installation Wizard, they will automatically replicate these new
passwords during the installation process.

Restore the first DC in each of the remaining domains

Perform the following steps while the restored machine is physically isolated (i.e. its network cable
is not attached and therefore it is not connected to the network). Procedures for performing these steps
are present in Appendix III.

1. Restore Active Directory on the first DC in each domain.

2. While restoring Active Directory, mark the SYSVOL primary because this is the first DC in the
domain.
3. After restoring and restarting the DC, verify that the data on the DC was not damaged by the
malfunction. If the data is damaged, then repeat the restore using a different backup.
After the restoring and verifying the data, but before connecting this computer to the network,
continue to step 4:
4. If you have DNS zones stored in Active Directory, then you need to ensure that the local DNS
Server service is installed and running on the DC that you have restored. This server should
be configured with the IP address of the first DNS server in the forest root domain as its
preferred DNS server, which is configured in its TCP/IP properties.
Ensure that the parent DNS zone contains delegation resource records (NS and glue A
resource records) for the child DNS zone hosted on this DNS server.

If this DC was not a DNS server prior to forest failure, then follow the steps for configuring DNS in Appendix
III. In this case, you must also ensure that the root DNS server contains CNAME records for this DC.
Without the CNAME record, the DC restored in the root domain, will not be able to replicate with this DC and
replication is essential to make the root DC a GC. (Each DC in the forest must register its CNAME resource
record for the name <DsaGuid>._msdcs.<DnsForestName>. DsaGuid is the GUID of the NTDS Settings
object of the DC (visible in Active Directory Sites and Services as the DNS alias property of the server
object's NTDS settings). This record usually belongs to the _msdcs.<ForestName> zone or, if that zone
does not exist, the <ForestName> zone.)

5. If the restored machine is enabled as a global catalog, then disable the global catalog flag.

Restoring a global catalog from backup could result in the global catalog holding newer data for one of its
partial replicas than the corresponding domain (the domain that is authoritative for that partition). In such a
case, the newer data would not be removed from the global catalog and might even replicate to other global
catalogs. As a result, even if you did restore a DC that was a global catalog, either inadvertently or because
that was the solitary backup you trusted, you should disable the global catalog soon after the restore is
completed. Disabling the global catalog flag will result in the computer losing all its partial replicas
(partitions) and relegating itself to a regular DC.

6. Raise the value of the current RID pool by 100,000.

7. Seize all domain-wide operations master roles (FSMO) to this DC.
8. Clean up the metadata of all other DCs in the domain which you are restoring from backup,
except for this DC.
9. Delete server and computer objects for all other DCs in the domain which you are restoring
from backup, except for this DC.
10. Reset the computer account password of this DC twice.
11. Reset the krbtgt password twice.

The reason for resetting passwords twice is to remove the original (pre-malfunction) password from
password history (assuming that the default password history is 2).

12. Reset the trust password twice (Trusted Domain Object password) for all trusts between this
domain and all other trusted domains.
This includes implicit trusts between child and parent domains as well as explicit trusts
created between this domain (trusting) and another domain (trusted). Reset the password on
only the trusting side of the trust (the side where this domain belongs) and then use the same
password on the trusted side of the trust. The latter is done when you restore the first DC in
each of the other (trusted) domains.
At this stage you should have one DC restored (and recovery steps performed) in the root domain
and one DC restored (and recovery steps performed) in each of the remaining domains. You
should now join these DCs to the network before performing the next step.

Enable the DC in the root domain to be a GC

While it is preferred that the root domain DC become a GC, it is possible to elect any of the
restored DCs to become a GC.
A GC is vital for these and more reasons:

Without a GC in a Windows 2000 native domain, users cannot logon.

In the absence of a GC, the Net Logon service running on the DCs in each domain (other
than the root domain) will not be able to register (or remove) records on the DNS server
in the root domain.

This DC 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 machine should be forced to replicate with each of the
restored DCs in the forest.
Monitor the Directory Service Event Log for event ID 1119 to indicate that this DC is a global catalog server.
You can also verify this by examining the registry key to see if it has a value of 1:
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Global Catalog Promotion Complete.

At this stage you should have a stable forest, with one DC for each domain and one GC in the
forest. You should take a fresh backup of each of the DCs that you have just restored. You can
now begin recovering other DCs in the forest by installing Active Directory using the Active
Directory Installation Wizard (dcpromo.exe).

Recover additional DCs in the forest by installing Active Directory

Consider the following for every DC that is recovered in the forest by installing Active Directory
(as opposed to restoring from backup):

There is no restriction on the host name of the server on which you want to install Active
Directory. You could use the same pre-malfunction host name or choose a different one.

Configure each server with the first DNS server in the forest (the first DC restored in the root
domain) as the preferred DNS server in its TCP/IP properties.

When installing Active Directory on this server, point the Active Directory Installation Wizard
(dcpromo.exe) to a source DC that you trust has been recovered and is free of damaged
data. You can do this using the unattend file in dcpromo.exe by specifying the
ReplicationSourceDC parameter in the file.

If this DC was running the DNS Server service prior to forest malfunction, the DNS Server
service should be installed and configured or its former DNS clients should be configured with
other DNS servers.

You could make this DC a global catalog server if you require additional global catalogs to
share the user (or application) authentication (or query) load.

Post-Recovery Steps
Once the entire forest is restored, the administrator can revert back to the original DNS
configuration, including configuration of the preferred and alternate DNS servers on each of the
DCs. Once the DNS servers are configured as they were before the malfunction, their previous
name resolution capabilities will be restored. You should delete any DNS records for DCs that
have not been recovered.
You should delete WINS records for all DCs that have not been recovered.
You could distribute the operation master roles to other DCs in the domain or forest and enable
more global catalogs servers based on your pre-failure configuration.
Restore or reinstall any software applications that were running on DCs prior to recovery. By
restoring Active Directory on the first DC in the domain, the registry was also restored because
they both are part of System State data. Keep this mind if you had any applications running on
these DCs and if they had any information stored in the registry.

10

Appendix I: Pre-Recovery Steps

A. Selecting a candidate domain controller
Domain: ExampleDom
Domain
controller
name

Operating
system
installed

Operations
master roles

Backup
available

Global
catalog

DNS
server

DC_1

Windows 2000

Schema; PDC

Yes

Yes

No

DC_2

Windows 2000

None

Yes

Yes

Yes

DC_3

Windows 2000

Infrastructure

No

No

No

DC_4

Windows 2000

Domain
Naming; RID
master

Yes

No

Yes

DC_5

Windows 2000

None

No

Yes

No

For ExampleDom, there are 3 backup candidates: DC_1, DC_2, and DC_4. Of these backup
candidates you would restore only one. The recommended domain controller would be DC_4 for
the following reasons:

It is a DNS server, so DNS does not need to be reinstalled.

It is not a global catalog server, and therefore it saves the process of disabling global catalog
functionality during the recovery procedure.

B. Understanding the forest recovery time-line

The following procedure summarizes the recovery steps.
1. For each domain, select a single DC to restore from backup.
2. Shut down all DCs in the forest.
3. In each domain, perform an offline restore for each DC you have selected.
4. Starting with the forest root DC, introduce the restored DCs to the network.
5. Enable the forest root DC as a global catalog server. Perform replication sync between the
forest root domain and each domain in the forest.
6. Install Active Directory on the remaining DCs in the forest using the Active Directory
Installation Wizard.

11

7. Perform the post-recovery steps.

You must know the administrator password for each domain.

While steps 1-5 are being performed, you could simultaneously start installing the operating system on each
of the remaining DCs in the forest (those that are not being restored from backup), preparing them for step
6.

12

Appendix II: Steps to backup and restore a domain controller

To backup a domain controller using the Windows 2000 backup utility
1. Click Start, point to All Programs, point to Accessories, point to System Tools, and then
click Backup to start the Backup Utility Wizard.
2. Click Advanced Mode in the Backup Utility Wizard.
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.
This will back up the System State data along with any other data you have selected for the
current backup operation.

You must be a member of the Administrators or a Backup Operator groups to back up files and folders.
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 may have to use Removable Storage to add your tape to the free media pool
so Backup can use it.
You can only back up the System State data on a local computer. You cannot back up the System State
data on a remote computer.

To perform a non-authoritative restore using the Windows 2000 backup utility

If reinstalling the operating system, you may or may not join the computer to the domain and could give any
name to the machine during set up of the operating system. Do not install Active Directory. After reinstalling
the operating system, go directly to step 4 below.

1. Restart the computer in Directory Services Restore Mode by pressing F8 upon system
startup.
2. Select Directory Services Restore Mode (Windows 2000 DCs only).
3. Select the operating system that you want to start in restore mode.
4. Log on as an administrator (local system account, no domain selection is available).
5. Run the Windows 2000 Backup utility and click Restore (DO NOT select the Restore
Wizard).
6. Select the appropriate backup location and ensure that the System disk and System State
check boxes are selected.
7. Click on the restore button in right hand corner of the page.

13

8. Before you start the restore however, you should click the Advanced button and ensure that
you are performing a primary restore of the Sysvol. This is achieved by enabling the When
restoring replicated data sets, mark the restored data as the primary data for all
replicas checkbox in the Advanced options.
9. Begin the restore process.
10. Once the restore is completed, restart the computer.
By executing a non-authoritative restore on Active Directory, you automatically execute a nonauthoritative restore of SYSVOL. No additional steps are required.

14

Appendix III: Tasks Performed during Recovery

Some of the following procedures require Windows .NET command-line tools. These tools are known as the
Support Tools and are available on the installation compact disc in the \Support\Tools folder. For more
information about Windows Support Tools, click Tools in Help and Support Center, and then click Windows
Support Tools.

To install the DNS Server service

The instructions for this step are only required if the DNS Server service was not installed on the DC you are
restoring from backup. You do not have to perform this procedure if the server you are restoring from backup
was running as a DNS server.

1. After restoring and restarting the DC described in Appendix II, install DNS on the server.
For more information about installing and administering the DNS Server service, see Help
and Support Center.
2. Click Start, point to All Programs, point to Administrative Tools, and then click DNS.
3. Create DNS zones for the same DNS domain names that were hosted on the DNS servers
prior to the critical malfunction.
4. Configure the DNS data to the state that existed before the critical malfunction. For example:

Configure DNS zones to be stored in Active Directory.

Configure the DNS zone authoritative for DC locator (Locator) resource records to allow
secure dynamic update.

5. Ensure that the parent DNS zone contains delegation resource records (NS and glue A) for
the child zone hosted on this DNS server.
6. After configuring DNS, at the command prompt, type:
net stop netlogon
7. Then type:
net start netlogon
Net Logon will register the DC locator (Locator) resource records in DNS for this DC.

If installing the DNS Server service on a server in the child domain, this DC will not be able to register its
records immediately, because it is currently isolated and its primary DNS server is the forest root DNS
server.

15

To disable a Global Catalog

1. Click Start, click Control Panel, double-click Administrative Tools, and then double-click
Active Directory Users and Computers.
2. In the console tree, double-click the DC where you want to enable or disable the global
catalog.
3. Right-click NTDS Settings, and then click Properties.
4. Clear the Global Catalog check box.

In Windows 2000, the GC will remove objects at the rate of 2000 objects/hr. Refer to kb article Q297935 in
order to increase the rate by which it removes the partial replicas. You should continue with the next step
while this process is underway.

To raise the current RID pool

1. Using LDP.exe (also called the Active Directory Administration Tool), connect and bind to this
DC.
2. Lookup the following account:
cn=RID Manager$,cn=System,dc=<domain name>
It has an attribute RidAvailablePool. This attribute has two values: a high value and a low
value. The low value will tell you the current RID pool. To retrieve this value, use the Large
Integer Converter in the Utilities menu.
3. Use the Modify option in the Browse menu to raise this value by 100,000.

For more information, see article Q305475, Description of RID Attributes in Active Directory in the Microsoft
Knowledge Base.

To seize an Operation Master role

1. At a command prompt, type:
ntdsutil

16

2. At the ntdsutil prompt, type:

roles
3. At the FSMO maintenance prompt, type:
connections
4. At the server connections prompt, type:
connect to server ServerFQDN
Where ServerFQDN is the fully qualified domain name of this DC, for example: connect to
server nycdc01.example.com. If the ServerFQDN does not succeed, use the Netbios name
of the machine.
5. At the server connections prompt, type:
quit
6. At the fsmo maintenance prompt, type:
seize OperationsMaster
Where OperationsMaster is the type of operations masters you want to seize, for example:
seize schema master

If this machine was not a RID master prior to failure and you attempt to seize the RID master role, it will try
to synchronize with a replication partner before accepting this role. However, since this step is performed
when the machine is isolated, it will not succeed in synchronizing with a partner. Hence you shall receive a
dialog box asking you whether you would like to continue with the seizure despite this machine not being
able to synchronize with a partner. Click Yes.

To clean metadata of removed DCs

Cleaning metadata results in the removal of the NTDS-settings object of a DC. The Ntdsutil command-line
tool is used to clean metadata.

1. At a command prompt, type:

ntdsutil
2. At the ntdsutil prompt, type:
metadata cleanup
3. To connect to an existing DC on which you want to remove the Ntds-settings object of the
failed DC, at the metadata cleanup command, type:

17

connections
4. At the connection prompt, type:
connect to server ServerFQDN
Where ServerFQDN is the fully qualified domain name of this DC, for example: connect to
server nycdc01.example.com. If the ServerFQDN does not succeed, use the Netbios name
of the machine.
5. At the connection prompt, type:
quit
6. At the metadata prompt, type:
select operation target
7. At the select operation target prompt, type:
list domains
8. A numbered list of domains will be displayed, type:
select domain Number
Where Number is the number corresponding to the domain in which this DC is located (which
is also the domain where the failed DCs are located).
9. At the select operation target prompt, type:
list sites
A numbered list of sites will be displayed
10. Type:
select site Number
Where Number refers to the number of the site in which the failed DCs are present.
11. At the select operation target prompt, type:
list servers in site
12.
A numbered list all servers in that site will be displayed.
13. Type:
select server Number

18

Where Number refers to the DC to be removed.

14. Type:
quit
The metadata cleanup menu is displayed.
15. Type:
remove selected server
You should receive confirmation that the DC was removed successfully. If you receive an
error indicating that the object could not be found, the object may have already been removed
from Active Directory.
Repeat steps 9-15 to remove metadata for all other DCs in each site for the domain in which
this DC (i.e. the DC which is being restored from backup) is a member.
To delete server and computer objects of removed DCs
To remove the failed server object
1. In Active Directory Sites and Services, select the appropriate site.
2. Delete the server object associated with the failed DC.
To remove the failed computer account
1. Using ADSIedit support tool, connect to this DC.
2. Open the domain naming context.
3. Select the organizational unit for the DC.
4. Delete the computer object associated with the failed DC.

If the DC computer accounts have been moved out of the DC organizational unit, you will need to know the
container in which they reside.

To reset machine account password of the DC

1. At the command prompt, type:
netdom help resetpwd
This will provide you with the exact syntax for using the netdom tool to reset the machine
account password of this DC.

19

For example:
Netdom resetpwd /server:<domain controller name>
/userD:administrator /password:*
Where <domain controller name> DC is the local DC that you are recovering.
Note: As mentioned in the recovery steps, you should run this command twice.
To reset krbtgt password
1. Click Start, click Control Panel, double-click Administrative Tools, and then double-click
Active Directory Users and Computers.
2. In the console tree, click Users.
3. In the right pane, right-click the krbtgt user account.
4. Select Reset Password and enter a new password.
Note: As mentioned in the recovery steps, you should perform this operation twice.
Reset trust passwords on one side of the trust
Important Note: To perform the following step(s), use the Netdom.exe tool that accompanies this paper. Do
not use the Netdom.exe tool that is available with the Windows 2000 support tools.

At the command prompt, type:

Netdom experthelp trust
This will provide you with the exact syntax for using the netdom tool to reset trust password on
one side of the trust.
For example:
If there are 2 domains in the forest, parent and child and you are running this command
on the restored DC in the parent domain:
Netdom experthelp trust <parent domain name> /domain:<child
domain name> /resetOneSide /passwordT:example /userO:administrator
/passwordO:*
When you run this command in the child domain,
Netdom experthelp trust <child domain name> /domain:<parent
domain name> /resetOneSide /passwordT:example /userO:administrator
/passwordO:*
Note:
passwordT should be the same value on both sides of the trust.

20

This command should be only run once (unlike the netdom resetpwd cmd), because it
automatically resets the password twice.
To enable the DC in the root domain to be a Global Catalog
1. Click Start, click Control Panel, double-click Administrative Tools, and then double-click
Active Directory Users and Computers.
2. In the console tree, double-click the DC where you want to enable or disable the global
catalog.
3. Right-click NTDS Settings, and then click Properties.
4. Check the Global Catalog check box.
The following points are provided to assist you to speed up the process of making the root
domain DC a Global Catalog server. The premise is that the DC in the root domain needs to
replicate the domain partition from each of the restored DCs in the non-root domains.
Ideally you would like to have the DC in the root domain be a replication partner of the restored
DCs in the non-root domains. If that is the case, you should confirm that the KCC has created the
corresponding repsFrom object for the source DC and partition in the root domain DC. You could
confirm that by running the repadmin /showreps /v command.
If there is no repsFrom object created, you should create one for the configuration partition, so
that the root domain DC can determine which DCs in the non-root domain have been deleted.
You can do this with the following command:
Repadmin /add ConfigurationNamingContext DestinationDomainController
SourceDomainControllerCNAME (i.e. sourceDCGuid._msdcs.<root domain>)
If the repsFrom object is present, you should attempt to sync the root DC with the DC in the nonroot domain using:
Repadmin /sync DomainNamingContext DestinationDomainController
SourceDomainControllerGUID
Where destinationDomainController is the DC in the root domain and the source DC is the
restored DC in the non-root domain.

The root domain DNS server should have the CNAME records for the source DC. Ensure that the parent
DNS zone contains delegation resource records (NS and glue A) for the correct DCs (those DCs that have
been restored from backup) in the child zone.
Make sure the DC in the root domain is contacting the correct KDC in the non-root domain. In order to test
this, at the command prompt, type:
run nltest /dsgetdc:<non-root domain name> /KDC

21

Related Links
Active Directory Disaster Recovery
(http://www.microsoft.com/technet/prodtechnol/ad/windows2000/support/adrecov.asp)
Windows 2000 Technical Resources
(http://www.microsoft.com/windows2000/techinfo/default.asp)

22