Vous êtes sur la page 1sur 55

Planning for Active Directory Forest Recovery

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

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..................................................................................................................................... 7 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.......................................................................................................................... 17 Restore the first writable domain controller for the forest root domain...................................18 Restore the first writable domain controller in each of the remaining domains.......................23 Add the global catalog to a domain controller in the forest root domain.................................26 Recover additional domain controllers in the forest by installing AD DS................................26 Postrecovery steps.................................................................................................................... 27 Appendix A: Forest Recovery Procedures....................................................................................28 Backing up the System State data............................................................................................. 29 Windows Server 2003: Backing up the System State data....................................................29 Windows Server 2008: Backing up the System State data....................................................29 Performing a nonauthoritative restore of Active Directory Domain Services..............................30 Windows Server 2003: Performing a nonauthoritative restore...............................................30 Windows Server 2008: Performing a nonauthoritative restore...............................................31 Configuring the DNS Server service.......................................................................................... 32 Windows Server 2003: Install and configure the DNS Server service....................................32 Windows Server 2008: Install and configure the DNS Server service....................................33 Removing the global catalog..................................................................................................... 34 Raising the value of available RID pools...................................................................................35 Seizing an operations master role............................................................................................. 36

Cleaning metadata of removed writable domain controllers......................................................37 Windows Server 2003: Clean metadata of removed writable domain controllers by using Ntdsutil.exe......................................................................................................................... 38 Windows Server 2008: Deleting a domain controller using Active Directory Users and Computers.......................................................................................................................... 40 Removing the failed server object.............................................................................................. 41 Removing the failed computer object......................................................................................... 41 Resetting the computer account password of the domain controller..........................................42 Resetting the krbtgt password................................................................................................... 42 Resetting a trust password on one side of the trust...................................................................43 Adding the global catalog.......................................................................................................... 43 Appendix B: Frequently Asked Questions.....................................................................................45 What can I do to speed up recovery?........................................................................................ 45 Can I automate the forest recovery process?............................................................................47 Can I restore more than one domain controller from backup in each domain?..........................48 Can I restore a global catalog server at an earlier stage?.........................................................51 Should I install AD DS by using the regular dcpromo routine or IFM?.......................................52 Additional Resources.................................................................................................................... 53

Note

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. 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 October 2006 May 2009 Revision Original publication on Technet 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 Windows Server 2008, including the following:

In Deciding When to Perform Forest Recovery and Recovering Your Active


5

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 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
6

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. Recovering Your Active Directory Forest was corrected to indicate metadata clean up should be performed for all writable domain controllers that are not restored from backup.

Feb 2011

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: 7

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 Directoryintegrated Domain Name System (DNS). Specifically, there should be an Active Directoryintegrated 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 Directoryintegrated 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 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 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: 9

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 intentionallyor an administrator accidentallyruns a script that spreads data corruption across the forest. An attacker intentionallyor an administrator accidentallyextends 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 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.

10

Important

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. 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. 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).

11

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. 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. 12

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.

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 13

Note forest. In addition, the forest root domain holds the DNS root server for the forests DNS namespace. Consequently, the Active Directoryintegrated 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. Use the Active Directory Domain Services Installation Wizard There are two methods to install AD DS, both of which can be automated: 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). 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 14

Note

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 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. 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.

15

Domain controller name

Operating system installed

Operations master roles

Writable or readonly

Backup available

Global catalog

DNS server

DC_1

Windows Server 2008

Schema master, primary domain controller (PDC) emulator master None Infrastructure master Domain naming master, RID master None None None

Writable

Yes

Yes

No

DC_2 DC_3 DC_4

Windows Server 2003 Windows Server 2008 Windows Server 2003 R2

Writable Writable Writable

Yes No Yes

Yes No No

Yes No Yes

DC_5 RODC_1 RODC_2

Windows Server 2003 Windows Server 2008 Windows Server 2008

Writable Readonly Readonly

No Yes No

Yes Yes Yes

No Yes Yes

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. 16

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 stepssuch as resetting the computer account, krbtgt account, and trust passwords, in addition to metadata cleanuphave 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 RODCespecially, no Schema or Configuration container changesthey 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 Remote manageability 17

Caution 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 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. 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 18

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-00000000-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). 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. 19

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. The isolated network can be a virtual network adapter or a Loopback adapter. 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 catalogeither inadvertently or because that was the solitary backup that you trustedwe 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). 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 20

Note 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. 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. 8. Clean up metadata of all other writable domain controllers in the forest root domain that you are not restoring from backup (all domain controllers in the domain 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. 21

Note

Note

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. 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. 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. 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 22

Important 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 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. 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-00000000-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 23

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. The isolated network can be a virtual network adapter or a Loopback adapter. 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). 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 24

Note 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. 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 not restoring from backup (all domain controllers in the domain 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. 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 25

Note 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. 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: 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

26

Important 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. 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. 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 27

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. 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 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 28

These steps explain how to performing an authoritative restore of SYSVOL at the same time.

To back up the System State data on a domain controller that runs Windows Server 2003 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 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. 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).

29

Note

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 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. 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). 30

To perform an a nonauthoritative authoritative restore restore of SYSVOL of a domain on a controller domain controller that runs that runs Windows Server 2008 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. 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. 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\Para meters\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). Include the -authsysvol switch in your recovery command, as shown in the following example: 31

To install and configure the DNS Server service for Windows Server 2003 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. 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. 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 32

To install and configure the DNS Server service for Windows Server 2008 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 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. 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. 33

To remove the global catalog 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). 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. 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 34

To raise the value of available RID pools 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.

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. 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. 35

To seize an operations master role 9. Select Replace as the operation, and then click Enter. 10. Click Run to run the operation.

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. 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.

36

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 Infrastructure master PDC emulator master RID master

Schema Admins Domain Admins Domain Admins Domain Admins

Seize schema master Seize infrastructure master Seize pdc 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. nNote 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

37

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 -orremove 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 The DNS name of the domain controller to which you want to connect and from which you want to remove server metadata

ServerName2

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 38

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

39

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

Server SiteNumber

The DNS name of a domain controller that you want to connect to. The number associated with the site of the server that you want to clean up that appears in the list. The number associated with the domain of the server that you want to clean up that appears in the list. The number associated with the server that you want to clean up that appears in the list.

DomainNumber

ServerNumber

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. 1. Click Start, click Administrative Tools, and then click Active Directory Users and 40

To remove the failed server object Computers.

To remove the failed computer object

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. 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. 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. 5. Right-click the computer object associated with the failed domain controller, and then click Delete.

41

To reset the computer account password of the domain controller

Important To reset the krbtgt password

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. 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. 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. 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. 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.

42

Important

To reset a trust password on one side of the trust

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. 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. 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 forestparent and childand 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> /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.

43

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:
repadmin /add cn=configuration,DC=contoso,DC=com DC01 937ef930-7356-43c8-88dc8baaaa781cf6._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.

44

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. 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. 45

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). 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.

46

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 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.

47

Note

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 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: 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. 48

Note 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 dataand 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: 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: 49

Important

Note

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. 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. 1. For the first domain controller that you restore from backup in the domain, complete the following steps: 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 dataand 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.

50

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.

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.

51

Note 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: 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. 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.

52

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 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) 53

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: 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 2003based domain controllers (http://go.microsoft.com/fwlink/? LinkId=74557) 54

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) Enterprise Management with the Group Policy Management Console (http://go.microsoft.com/fwlink/?LinkId=70808)

55

Vous aimerez peut-être aussi