Deploying Active Directory for Branch Office Environments

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Chapter 10 - Disaster Recovery for Branch Office Environments

Operating System

Deployment and Operations Guide

Abstract

Regular backups of the Active Directory™ directory service are essential for the successful operation of a Microsoft® Windows® 2000 environment. This will help to ensure that Windows 2000 domain controllers can be restored and brought back online in a quick, responsive manner in the event of failure. This chapter outlines the steps necessary to back up and restore Active Directory. After completing these steps, Active Directory on your given domain controller should be functioning correctly. This chapter also discusses the process of staging and shipping replacement domain controllers from a staging site.

On This Page

Introduction
Active Directory Backup and Restore
Active Directory Disaster Recovery
Restoring Active Directory
Repairing Active Directory
Using Windows 2000 Terminal Services to Remotely Back up and Restore Active Directory
Staging Replacement Domain Controllers for Remote Locations
Summary

Introduction

The following chapter discusses some of the procedures you should use to be prepared in the event of the failure of a domain controller, whether at the branch or at a hub or staging site.

Resource Requirements

To be ready to restore your network in the event of a disaster, you will need the following personnel, procedures, and equipment.

What You Will Need

You will need the following:

• A disaster plan

• Trained personnel who have delegated areas of responsibility according to a disaster plan

• A procedures manual for staff to follow in the event of a disaster

• Server-by-server notebooks which document the software and hardware on that server, the latest backups, the personnel responsible in event of an emergency, and the second-level support for those cases

What You Should Know

You should know how your organization plans to recover in the event of a disaster, whether it is a single server disaster, a network disaster such as a virus or physical network failure, or a natural disaster. You should be familiar with the personnel available for disaster recovery, both at the branches and at the hub and staging site. You should understand not only the planned strategy for disaster recovery, but also the variable performance of the recovery steps, so that your plan can take them into account.

Active Directory Backup and Restore

You can back up and restore the Active Directory™ directory service by using the tools included with Microsoft® Windows® 2000 Server. These tools include the Backup tool, which allows backups and restores of Active Directory and other data and services. The command-line tool, Ntdsutil, can be used as part of the Active Directory restore process to authoritatively restore deleted objects to the Active Directory.

Overview of Active Directory Backup

The essential things to know about backing up Active Directory include which tools to use, which data to include, who has permission to complete the process, and what is the best way to do it. Regular backups of Active Directory will help to ensure that a domain controller can be restored in the quickest time possible. Although the Windows 2000 Backup tool provides several methods for backing up data, the only type of backup supported by Active Directory is normal backup.

Note: Active Directory does not support incremental backup in this release. Normal (full) backup is the only type of backup type supported for Active Directory.

A normal backup can create a backup of the entire system while the domain controller is online. A normal backup marks each file as having been backed up, which clears the Archive attribute of the file. A normal backup also truncates the log files of database applications. Restoring a system from a normal backup requires a single restore from the backup media (by comparison, restoring a system from an incremental backup requires the latest normal backup followed by each incremental backup in the order they were made).

The Windows 2000 Backup tool is the default backup tool included with Windows 2000 and can be used to back up Active Directory. When the Windows 2000 Backup tool is used to back up Active Directory you must choose to back up System State. This will automatically back up all of the distributed services and components on which Active Directory is dependant.

On a Windows 2000 domain controller, the System State is comprised of the following elements:

• Active Directory

• The local registry

• The system startup files

• The Component Object Model+ (COM+) class registration database

• SYSVOL

• Performance counter configuration

• Certificate Services database (if installed)

• Domain Name System (DNS) (if installed)

• Cluster Service (if installed)

Permissions and User Rights

With Windows 2000, the permissions and user rights required to perform a backup of Active Directory can be separated from those required to perform a restore. To back up Active Directory (and thus the System State data), you must be a member of one of the following groups:

• The backup operators group

• The local administrators group

• A group with the backup right

The backup operators and local administrators groups are built-in groups that already have the necessary permissions and user rights necessary to perform a backup of Active Directory.

Best Practices for a Good Backup

To ensure a successful restore from backup, it is important to know what defines a good backup. For Active Directory, this consists of two major components:

• Contents

• Age

Important: For full disaster recovery, back up all of the drives and the System State data. To do this, run the Backup tool, and then in the Backup Wizard, on the What to Back Up screen, choose Back up everything on my computer.

Contents

A good backup will include at least the System State and the contents of the system drive. Backing up the system drive will ensure that all necessary files and folders are in place before initiating a successful restoration.

On domain controllers that experience large volumes of Active Directory requests, performance can be optimized by separating the Active Directory database and log files onto different spindles. If you have configured your domain controllers in this manner, you will have Active Directory components spread across multiple spindles, for example, D:\Windows\NTDS for your logs and E:\Windows\NTDS for Active Directory. A backup of the System State, however, will automatically back up these components from their different locations. In this scenario, a backup of the System State and system drive can still be considered a good backup.

Age

It is not possible to restore a backup image into a replicated enterprise that is older than the tombstone lifetime value for the enterprise. When an Active Directory object is deleted, it is not fully and immediately removed from Active Directory. Instead the majority of the attributes are stripped out and the object is moved to the deleted items container. This remaining object is called a tombstone. This tombstone object is replicated to all domain controllers in that respective domain so that they can learn of the object deletion. In this manner, the original object is no longer available to anyone searching Active Directory for it, but it is tombstoned.

The tombstone lifetime value represents the number of days that the deleted object (or tombstone) must be retained before it can be permanently removed from the directory. This value can be set by using the Active Directory Service Interfaces (ADSI) edit at the directory service path below:

Cn=Directory Services, cn=WindowsNT, cn=Services, cn=Configuration, dc=<<Domain_Name>>,dc=<<Domain_prefix>>

The default tombstone lifetime value is 60 days. Active Directory will not allow data to be restored to the directory from a backup image that is older than the tombstone lifetime. If this were to happen, the restored object would have an Update Sequence Number (USN) too old to trigger Active Directory replication. In this scenario, the object would never be replicated out to other domain controllers, and the restored domain controller would never replicate in to the necessary information to delete the object. Active Directory on the local server would thus become inconsistent.

Note: It is essential that at least one backup is taken from every domain controller at least once during the period of the tombstone lifetime, which defaults to 60 days.

Note the following facts when using the Backup tool to back up System State data and other files:

• You must be an Administrator, Backup Operator, or someone with the backup right to back up the System State data.

• System State data does not contain Active Directory unless the server on which you are backing up System State is a domain controller.

• You can back up System State data by itself, or you can back up System State data with other files as part of your regular backup procedures.

• You can back up System State data to a disk, tape, or a network sharewhile the domain controller is online.

• If you are backing up to tape, you might have to use Removable Storage to add a tape to the backup media pool. Otherwise the tape will not be available for the Backup tool to use.

• You must perform a backup on every domain controller in the enterprise to entirely back up Active Directory. (Active Directory cannot be backed up on a remote computer.)

• The Windows 2000 Backup tool does not encrypt the unencrypted backup contents during the backup process.

• For restore purposes, a backup of Active Directory can only be restored to the domain controller from which it was taken.

Backup of Domain Controllers in Branch Office Environments

Backup of Active Directory on all domain controllers is necessary to ensure a quick recovery in the event of Active Directory failure or a domain controller hardware failure. All domain controllers should be backed up at least once during the tombstone lifetime period. There are generally two ways to do this:

• Back up domain controllers in remote branch office locations over the wide area network (WAN) to a central location.

• Local backup of branch office domain controllers.

When backing up remote domain controllers to a central location over the WAN, be careful about the amount of time and bandwidth that may be required to do this. The size of Active Directory on the branch office domain controllers will also affect backup time. This option is not a good choice if the WAN link has very limited available bandwidth or if Active Directory is very large.

Note: The Windows 2000 Backup tool does not support remote backup and restore of Active Directory. A third-party backup solution is required to achieve this functionality.

The second option uses backup of domain controllers locally in the branch office locations. This requires an appropriate hardware backup device locally. This option can be automated to back up domain controllers at regular intervals by using the Windows 2000 Backup tool. Alternatively, if Terminal Services is enabled on the remote branch office domain controller, this process can be performed over the WAN by using the Windows 2000 Terminal Services client.

For more information about the use of Terminal Services in the Windows 2000 Active Directory backup and restore process, see the Using Windows 2000 Terminal Services to Remotely Back Up and Restore Active Directory section later in this document.

For more information about resolving problems encountered during backup and about using Event Viewer, see the "Active Directory Diagnostics, Troubleshooting, and Recovery" chapter in the Distributed Systems Guide book of the Microsoft Windows 2000 Server Resource Kit.

Active Directory Disaster Recovery

Disaster recovery measures tend to be required with Active Directory due to one of two reasons:

• Database corruption

• Data corruption

Database Corruption

For the purposes of this document, assume that database corruption occurs due to one of the following reasons:

• The disk has become corrupted.

• The domain controller has suffered a hardware failure and needs to be replaced.

Data Corruption

For the purposes of this document, assume that data corruption occurs due to one of the following reasons:

• Corruption of Active Directory data, which has replicated to other domain controllers.

• Deletion of Active Directory objects in error, which have been replicated to other domain controllers in the domain/forest. These objects now need to be reinstated in Active Directory.

Restoring Active Directory

There are two ways to restore Active Directory. You can reinstall Windows 2000 and then repopulate Active Directory through the normal replication process, or you can restore Active Directory from a backup. The first method restores Active Directory to the current state with respect to its current replica partners. The second method restores Active Directory to a previously known state (whatever it was when it was last backed up).

Restoring Active Directory Through Reinstallation and Replication

You can restore a domain controller by reinstalling Windows 2000 Server on the damaged system, making the server a domain controller, and then allowing the correct information to be replicated to it automatically during the installation of Active Directory. Installing Active Directory over a WAN may result in high consumption of the available WAN bandwidth. It may also take a long time if Active Directory is large. To deal with this, it is recommended that you install the new domain controller centrally and then transport it to the remote location.

This option may not be a good choice in branch office environments. It essentially installs a new domain controller at the remote location to replace the failed replica. This will require the new domain controller to replicate in Active Directory as part of the domain controller promotion process, which may take a long time.

Staging and Shipping Domain Controllers

When conducting Active Directory deployments, many organizations install domain controllers at a central location and transport them to the remote location after the installation is complete. For more information about this option, see Chapter 5, "Planning the Staging Site for Branch Office Environments" in the Active Directory Branch Office Planning Guide.

Restoring Active Directory from Backup Media

You can also restore Active Directory on a domain controller by restoring the System State data from backup media. This restores Active Directory and the System State components on which Active Directory depends.

When you restore Active Directory from backup media, note the following:

• If the domain controller computer has been replaced because of malfunction, or if the network adapters have been replaced, you might need to reconfigure the network settings manually.

• If the domain controller has a substantial hardware problem and must be rebuilt, make sure the number and size of disk volumes is the same as or larger than the previous system. If you must rebuild a system by starting with an empty hard disk, first install Windows 2000 Server (on the same disk as before) re-create the partitions and volumes as they were on the damaged system, and then restore Active Directory. This implies that you have documentation on the server configuration, which allows you to re-create it.

System Key (Syskey) and the Active Directory Restore Process

Domain controllers contain security-sensitive information, such as copies of users' secret keys, which are used for domain authentication. It is recommended that domain controllers be kept in locations that are physically secure with limited access. Physical access can allow an intruder to obtain copies of encrypted password data, which can be used for an offline password attack. To protect against this, Microsoft provides Syskey, a tool that encrypts all secret keys with a 128-bit random key. This key can be stored locally in the registry on a domain controller or can be stored on a floppy disk. For maximum security, it is recommended that you store Syskey on a floppy disk.

Restoring Active Directory to Dissimilar Hardware

It is possible to restore Active Directory to a computer other than the original computer, provided that both computers have the same number of or more disk drives. The Hardware Abstraction Layer and the Boot.ini file must also be identical. Also, if the replacement domain controller has a different video adapter or multiple network adapters, uninstall them before you restore data. When you restart the computer; Plug and Play functionality makes the appropriate updates.

There are two general methods for restoring Active Directory from backup media:

• Non-authoritative restore

• Authoritative restore

Non-Authoritative Restore

Non-authoritative restore is the default method when performing a restore of Active Directory. It will be used in the majority of restore situations, such as domain controller hard disk failure, and is the most likely option to be used in branch environments. In this scenario, the Windows 2000 operating system is reinstalled complete with Service Packs. The Windows 2000 Backup tool is then used to restore Active Directory to the domain controller from the backup media.

This will restore Active Directory on the domain controller to a state consistent with the time that the backup was taken. The domain controller will then receive any directory service changes that have occurred since the time of the backup through the normal Active Directory replication process.

Because the restore process does not restore any previously deleted data to Active Directory, it is described as non-authoritative.

Non-Authoritative Restore Using the Windows 2000 Backup Tool

There are a number of different scenarios in which a restore of Active Directory may be necessary. In some cases, the domain controller might have failed due to an operating system failure or hardware failure. In other cases, Active Directory on that domain controller may fail, stop responding, or become corrupt. The Active Directory restore procedures are slightly different for these scenarios and are detailed below:

In this scenario, the entire computer needs to be rebuilt complete with operating system and Active Directory.

To restore Active Directory to a failed domain controller:

1. At a healthy domain controller in the same domain, click Start, Programs, Administrative Tools, and then click Active Directory Sites and Services.

2. In Active Directory Sites and Services, navigate to the site in which the failed domain controller was a member.

3. Delete any references to the failed domain controller.

4. Install the appropriate version of the Windows 2000 operating system, complete with any necessary Service Packs, on the computer that will replace the failed server.

5. During the installation of Windows 2000 Server, specify the name of the failed domain controller as the computer name when prompted.

6. After installation, make sure the backup media containing Active Directory is available. Alternatively, copy the backup file (.bkf) over the network locally to the computer.

7. On the Start menu, click Run, and then type Ntbackup

8. On the Welcome page, click Restore Wizard.

9. Click Next, and then select the backup set from which you want to restore. Select SystemState, and then click Next.

10. Click Finish.

Restore Active Directory to a Domain Controller in Which Active Directory Has Failed

In this scenario, the Windows 2000 Server has not failed. Instead, Active Directory may not be functioning properly on the domain controller. This may due to a corruption of Active Directory, a corrupt registry, or a failure of a service that Active Directory inherently depends on. This situation does not require a reinstallation of the Windows 2000 operating system. Instead, it requires a restore of the System State from a previous backup of the domain controller in question. This will ensure that Active Directory is returned to a stable functioning state.

Active Directory cannot be restored to a computer on which Active Directory is running. To complete the process, the computer must be placed into directory services restore mode. In directory services restore mode, the Windows 2000 operating system is running, but Active Directory is offline.

To restore Active Directory to a domain controller in which Active Directory has failed:

1. Restart the domain controller.

2. On the operating system selection menu, select the operating system that you want to start, and then press F8.

3. On the selection menu, select Directory Services Restore Mode, and then press ENTER.

   Note: When you restart the computer in directory services restore mode, you must log on to the local computer as the local Administrator. To do this, you must use an account name and password that is stored in the local accounts database, known as the Security Accounts Manager (SAM) database. This is the administrator user account and password provided during the Active Directory Installation Wizard. You cannot use the name and password of the Active Directory administrator because Active Directory is offline and account verification cannot occur.

4. Log on with a user account that is a local administrator account on that server.

5. After you are logged on, on the Start menu, click Run, and then type Ntbackup

6. On the Welcome page, click Restore Wizard.

7. Click Next, select the backup set from which you want to restore, select SystemState, and then click Next.

8. Click Finish.

After the restore process has completed, restart the domain controller normally. Active Directory should now be functioning normally. After restarted, the domain controller should re-insert itself into the Active Directory replication topology and receive any new updates.

Caution: When you restore the System State data, the location of the system root must be the same as the location when you backed up the System State data.

Because the Backup tool restores the database and registry settings, when it restores Active Directory, the Internet Protocol (IP) configuration is also restored. In addition, DNS, the Certificate Services database files, and File Replication service (FRS) are also restored. Completing restore has the following results:

• The FRS is reset so that it is in a state ready for replication from an FRS replication partner.

• Active Directory is verified for restore.

The server then restarts in normal operational mode and performs the following actions:

• Checks Active Directory files for consistency and re-indexes them.

• Replicates FRS data with an FRS replication partner.

• Restores the Certificate Services database.

Implications and Considerations of a Non-Authoritative Restore

The process mentioned above is primarily for non-authoritative restoration of only Active Directory. However, certain Active Directory objects (for example, organizational units, domains, and sites) may have group policies associated with them, and these group policies are stored in the SYSVOL directory.

The SYSVOL folder and its contents are replicated to all domain controllers for a given domain. Unlike Active Directory, SYSVOL uses the File Replication Service (FRS) to replicate SYSVOL and its contents between domain controllers. FRS replicates whole files, even if only a small amount of data in a file has changed.

After a domain controller is restored from backup, the current SYSVOL will be considered out of date. As a result, the entire SYSVOL will be replicated from another domain controller upon reboot after the restore. This could potentially be very large in a Windows 2000 domain in which extensive use is made of Group Policy or where there are a large number of logon scripts. In the remote branch office scenario, be aware that SYSVOL replication may take a long period of time depending on the amount of the information to be replicated and the amount of available bandwidth on the WAN. As a result, it is recommended that this practice be performed outside the normal working-day hours or when use of the branch-hub link is low.

Authoritative Restore

The primary purpose of an authoritative restore is to "put back" or reinstate objects that have been deleted from Active Directory. When objects have been deleted, either intentionally or accidentally, a non-authoritative restore must be completed before the authoritative restore steps can take place. The Windows 2000 Backup tool is used to perform the non-authoritative restore. Ntdsutil.exe is then used to perform the authoritative restore and reinstate the deleted object or objects.

It is not possible to use the non-authoritative restore process to reinstate deleted objects from an older backup image because the backup media that is used for the restore would contain an image of Active Directory that was created before the object was deleted. When the domain controller restarts after the restore, it receives replication updates, which contain the directory service changes, including the deletion of the object, that have occurred since the backup, from its replication partners. This is because the version number of the deletion action on the object is higher than the version number of the object on the backup media.

The authoritative restore process works as follows: after the non-authoritative restore has been done, but before the domain controller is restarted, the authoritative restore procedure is used to reinstate the required objects. This action marks the objects as authoritative and reinstates them in Active Directory. It does this by altering the object metadata so that it will win any replication collision that may occur by increasing the version number by 100,000. The authoritative restore action is done by using the command line tool Ntdsutil.

Important: Only the domain and configuration partitions can be marked as authoritative. The schema cannot be authoritatively restored because it might endanger data integrity. For example, if the schema was modified and then objects of the new or modified class schema object were created, subsequent authoritative restore might replace the new or modified classes, thereby causing serious data consistency problems.

The authoritative restore feature of the Ntdsutil tool is meant to be used sparingly because it restores the directory to an earlier state and any updates that were made to the restored objects after that point are lost. You can use it to selectively modify subtrees, organizational units, and even an entire forest on a domain-by-domain basis, but do so only if you have identified a specific problem and are certain an authoritative restore will fix it.

Authoritative Restore of FRS

FRS is affected by an authoritative or non-authoritative restore. The Ntdsutil command-line tool, however, is not used to authoritatively restore FRS. To restore FRS authoritatively, restore the FRS files to an alternate location, restart the domain controller, publish the SYSVOL share, and then copy the restored files from their alternate location to their original location. You must publish the SYSVOL share before you copy the files or the restore does not succeed and will cease to function properly

Authoritative Restore Using Ntdsutil

To authoritatively restore Active Directory:

1. Perform a non-authoritative restore of Active Directory, and then restart the computer. During the phase of startup in which the operating system is normally selected, press F8 to display advanced startup options. On the Windows 2000 Advanced Options menu, select Directory Services Restore Mode. This ensures that the domain controller is offline and is not connected to the network.

2. At the command prompt, type ntdsutil and then press ENTER. Type authoritative restore and then press ENTER.

   To authoritatively restore the entire directory, type Restore database and then press ENTER.

   • To authoritatively restore a portion, or subtree, of the directory, such as a grouping of organizational units, type Restore subtree <subtreedistinguished name> and then press ENTER.

     For example, to restore the Marketing organizational unit in the branches.corp.hay-buv.com domain, the commands are as follows:

     ntdsutil

     authoritative restore

     Restore Subtree OU=Marketing,DC=Branches,DC=Corp,DC=hay-buv,DC=COM

   • To authoritatively restore the entire directory and override the version increase, type Restore database verinc <version increase>, and then press ENTER.

   • To authoritatively restore a subtree of the directory and override the version increase, type Restore subtree <subtree distinguished name> verinc <version increase>, and then press ENTER.

     Note: During authoritative restore, Ntdsutil opens the Ntds.dit file, increases version numbers, counts the records that need updating, verifies the number of records updated, and reports completion. If you do not specify an increased version number, Ntdsutil automatically increases the version number(s) by 100,000.

3. Type quit and then press ENTER to exit the Ntdsutil tool.

4. Restart the domain controller in normal mode and connect the restored domain controller to the network.

When the restored domain controller is online and connected to the network, normal replication makes the restored domain controller up to date with any changes from the additional domain controllers for the portions of Active Directory that were not overridden by the authoritative restore. Replication also propagates the authoritatively restored objects to other domain controllers in the domain or forest. The once-deleted objects that were restored from backup and were marked as authoritative are replicated from the restored domain controller to the additional domain controllers. Because the objects that are restored have the same object globally unique identifier (objectGUID) and object security identifier (objectSID), security remains intact and object dependencies are maintained.

SYSVOL Implications and Considerations of an Authoritative Restore

There are several things to be aware of when performing an authoritative restore of Active Directory. These are discussed in the following section.

The same replication considerations apply during the authoritative restore of SYSVOL as for during a non-authoritative restore. The major difference is that in the case of an authoritative restore, the SYSVOL is replicated eventually to every domain controller in the domain because it is marked as authoritative.

When performing an authoritative restore of Active Directory, it will also be necessary to restore the Group Policy objects associated with the Active Directory objects that you have restored. This procedure will vary depending on whether you perform an authoritative restore of Active Directory or specific objects in the database. These two procedures are outlined below.

Authoritative Restoration of Active Directory and SYSVOL

When you authoritatively restore Active Directory, you must ensure that the proper elements are authoritatively restored. You do this by copying the SYSVOL directory from an alternate location and then overwriting the existing SYSVOL directory. This is necessary to ensure the integrity of the Group Policies stored on the computer.

To restore Active Directory:

1. Back up the System State data by using the Backup tool.

2. Restart the computer in directory service restore mode.

3. Restore the System State data to its original location and to an alternate location.

4. By using Ntdsutil, mark Active Directory as authoritative.

5. Restart the computer in normal mode.

6. After the SYSVOL share is published, copy the SYSVOL directory from the alternate location to overwrite the existing one. You can verify that the copy is complete by checking the contents of the SYSVOL\domain directory; when completed, it contains a Scripts and Policies folder.

Authoritative Restoration of Specific Active Directory Objects and Corresponding Objects from SYSVOL

When you authoritatively restore a portion of Active Directory (including Group Policy objects), you must also perform an additional procedure (described below) involving the SYSVOL directory. To ensure the proper elements are authoritatively restored, use the following procedure:

1. Back up the System State data by using the Backup tool.

2. Restart the computer in directory service restore mode.

3. Restore the System State data to its original location and to an alternate location.

4. By using Ntdsutil, separately mark specific Active Directory objects as authoritative.

5. Restart the computer in normal mode.

6. After the SYSVOL share is published, copy only Policy folders (identified by the globally unique identifier [GUID]) corresponding to the restored Group Policy objects from the alternate location over the existing ones.

Important: When authoritatively restoring either Active Directory or selected objects, it is important that when you copy the SYSVOL and policy data from the alternate location, it is done after the SYSVOL share is published.

If the domain in question has many domain controllers, it can take several minutes before the SYSVOL share is published because the restored domain controller needs to synchronize with its replication partners.

If all computers in the domain are authoritatively restored and restarted at the same time, they each are waiting (indefinitely) to synchronize with each other. In this case, restore one of the domain controllers first so that its SYSVOL share can be published. Then, restore the other computers non-authoritatively.

Impact on Authoritative Restore of Trust Relationships and Network Connections

The domain partition stores information about parent and child trust relationships in Windows 2000 domains in addition to Kerberos v5 and NTLM protocol trust relationships with other Microsoft Windows NT™ 4.0 or Windows 2000 domains. Because trust relationship and computer account passwords are renegotiated at a specified interval, if you authoritatively restore an entire domain directory partition, computer passwords and trust relationship passwords are restored to the values at the time of the backup. If the password values are different from the current values, trust relationships and computer accounts might be invalidated. In the case of trust relationships, this may cause communication with domain controllers from other domains to fail. If an older computer account password is restored, it could cause communications between that workstation or server and the domain controller to fail. If the objects that you are authoritatively restoring affect trust relationships or computer account passwords, you must reset the passwords. Therefore, be very selective when choosing objects to authoritatively restore; restore only those portions of the domain directory partition that are absolutely necessary.

Note: By default, passwords are reset every seven days on accounts, except for computer accounts, in which the default is 30 days. The previous password is also maintained. Therefore, performing authoritative restore with a backup that is older than 14 days can affect the trust relationships.

There are often some trusts, user, and computer accounts that require resetting. To reset Windows 2000 trust relationship passwords, use the Active Directory Domains and Trusts snap-in. For more information about specific procedures for resetting passwords, see Microsoft Windows 2000 Server Help. To reset computer account passwords, use the Active Directory Users and Computers snap-in. You can also use the Netdom command-line tool to reset trust relationship and computer account passwords. For more information about using the Netdom tool, see Microsoft Windows 2000 Resource Kit Tools Help, which is included on the Microsoft Windows 2000 Resource Kit companion compact disc.

Recovery of Operations Masters

If a domain controller that maintains an operations master (Flexible Single Master Operations [FSMO]) role becomes unavailable, the only way that the service offered by the FSMO can be restored is to do one of the following:

• Restore the existing domain controller, which holds the FSMO role by using the methods described in this chapter.

• Transfer the FSMO role to another domain controller. When the original FSMO holder is unavailable, the transfer is called seizing.

These roles can be seized by using the relevant Microsoft Management Console (MMC) snap-in tool or by using the command line utility Ntdsutil.

For more information about FSMO roles, see the "Managing Flexible Single Master Operations" chapter in the Distributed Systems Guide of the Microsoft Windows 2000 Server Resource Kit.

Recovery of Global Catalog Servers

Some domain controllers may also be Global Catalog servers. As discussed earlier in the chapter, there are two possible ways to restore a domain controller:

• Restore from a previous backup.

• Restore the domain controller by using reinstallation and replication.

If the domain controller has been restored from a previous backup, it will already be a Global Catalog server and no extra configuration is necessary.

If the domain controller has been reinstalled and is essentially a new domain controller, it will need to be reconfigured to be a Global Catalog server. For the steps to reset the server as a Global Catalog, see Help.

Repairing Active Directory

Active Directory stores its data in an Extensible Storage Engine (ESE) database, Ntds.dit. ESE is a transacted database system that uses log files to guarantee database updates and to rollback updates in the event of recovery.

Windows 2000 provides a management tool for Active Directory called ESENTUTL.EXE. This tool is stored in the %SystemRoot%\System32 folder. When used with the /repair switch, the tool performs a low-level repair of the database. This option should be used only as a last resort in the event of Active Directory failure because it can cause data loss.

Using Windows 2000 Terminal Services to Remotely Back up and Restore Active Directory

Windows 2000 includes Terminal Services as an installable component of the Windows 2000 Server platform. Terminal Services in Windows 2000 Server can function in two modes, one of which is remote administration mode. In remote administration mode, Terminal Services can be used to remotely administer any Windows 2000 Server. To connect to a Windows 2000 Server running Terminal Services, a Terminal Services client must be installed on the client computer.

There are currently two Terminal Services clients available to choose from: Terminal Services Client and Terminal Services Advanced Client (TSAC, available with Service Pack 1 and later, or as a download). The Terminal Services Client allows a connection to a Windows 2000 Terminal Services server from a Microsoft Windows CE/Microsoft Pocket PC device or any Windows desktop. The Terminal Services Advanced Client is a Microsoft ActiveX control, which can run inside an Internet browser and function as a Terminal Services Web client.

Windows 2000 Terminal Services can be put to good use to remotely automate Active Directory backup and restore operations in the remote branch office scenario. The options and configurations for each of these operations are listed below.

Active Directory Remote Backup Operation

For Active Directory backup, the process is straightforward process. The steps are as follows:

1. Click Start, Programs, Terminal Services Client, and then click Client Connection Manager. This will open the Terminal Services Client, Client Connection Manager tool.

2. Use the Terminal Services Client, Client Connection Manager tool to create a connection object to the domain controller in question.

3. In Client Connection Manager, double-click the connection object. When the logon screen appears, log on to the domain controller.

4. Perform the Active Directory backup operation as required.

For more information about this, see the Active Directory Backup and Restore section earlier in this chapter.

Active Directory Remote Restore Operation

For a remote restore operation of Active Directory, again the process is reasonably straightforward. However, in addition to the process outlined above, some extra steps must be performed to make the Windows 2000 Server boot into directory services restore mode so that it connects over a Terminal Services connection and performs the Active Directory restore. The steps for this are as follows:

1. Click Start, Programs, Terminal Services Client, and then click Client Connection Manager. This will open the Terminal Services Client, Client Connection Manager tool.

2. Use the Terminal Services Client, Client Connection Manager tool to create a connection object to the domain controller in question.

3. In Client Connection Manager, double-click the connection object. When the logon screen appears, log on to the domain controller.

4. In the command prompt, remove the R, S, and H attributes from the Boot.ini file. This can be done by typing the following:

   attrib -r -s -h C:\boot.ini

5. Use Notepad to open the c:\boot.ini file.

6. In Boot.ini, you will see a list of ARC paths that reflect the various Windows installations on that computer. Go to the end of the ARC path for the domain controller concerned, and then add the following switch:

   /safeboot:dsrepair

7. This will cause the Windows 2000 Server to boot into directory services restore mode upon reboot. During the reboot, it is recommended that you use the ping t <<server_name>> command from the client computer. This will show you when the Terminal Server has rebooted.

8. Use the Connection Object in Terminal Services Client, Client Connection Manager tool to reconnect to the domain controller. The domain controller should now be in directory services restore mode. After you are connected, log on by using the local Administrator account.

9. Perform the Active Directory restore operation as required. For more information about this, see the Active Directory Backup and Restore section earlier in this chapter.

It is important to note that physical visits may still be required to the site and domain controller in question if the operating system has failed. Terminal Services could still be used by administrators to assist remotely with the restore process after the Windows 2000 Sever operating system is installed.

For more information about the Boot.ini file and the Windows 2000 Server boot process in general, see the Starting Windows 2000 Server" in the Troubleshooting section of the Server Operations Guide of the Microsoft Windows 2000 Server Resource Kit.

Staging Replacement Domain Controllers for Remote Locations

Many companies that deploy Active Directory face a dilemma when deploying Active Directory to large numbers of remote locations. There are two options available to avoid this dilemma:

• Install the domain controller at the remote branch office location, and then replicate in Active Directory over the WAN.

• Stage a domain controller by installing the domain controller at a central location, and then transport it to the remote location.

If your organization is staging domain controllers at a central location, one recovery option is to stage a new domain controller and ship it to the branch office that has the failed domain controller. There are several advantages to using this method:

• It alleviates the need to perform remote troubleshooting or to send someone to the branch office.

• If the domain controller must be rebuilt, it does not require that a large amount of replication traffic be sent over the slow link to the branch office.

• The failed domain controller can be shipped back to the central office for examination to see if the cause of the failure can be determined.

Summary

This chapter has provided you with methods for performing disaster recovery in your Active Directory environment.

More information

For more information about disaster recovery, see the Microsoft Windows NT Product Group High Availability Operations Guide: Implementing Systems for Reliability and Availability, in addition to the Microsoft Windows 2000 Resource Kit.