Active Directory Emergency Recovery

Active Directory Emergency Recovery Similar to the system registry, which is often referred to as the "heart and soul" of any local computer running Windows NT, Windows 2000, Windows XP, or Windows Server 2003, Active Directory is the "heart and soul" of a corporate Windows-based network. This essential network component must be available to applications and users at all times. There are other similarities between the system registry and the AD, but this is the most important one. In contrast to the registry, which is a local configuration database, AD is a replicated database, and as such, it is vulnerable to the same problems that can damage any distributed database, including:  A corrupted or invalid database schema (defines the structure of the database — what type of data it contains and how that data is arranged)  Missing DNS records  Damaged or corrupted information  Human errors, including accidental errors of the system administrator Consequently, if you have implemented AD domains in your organization, it is imperative that you develop disaster-prevention and disaster-recovery procedures for your AD infrastructure. Physical AD Structure As previously mentioned in this chapter, the Active Directory information, which now replaces the SAM registry hive, is physically stored as an on-disk database. The actual database file is called Ntds.dit, and by default, it resides under %SystemRoot%\ntds folder. Note On Windows 2000 Server or Windows Server 2003, a pristine copy of the AD database is stored in the %SystemRoot%\system32\ntds.dit file. This copy is used when a member server is promoted to a domain controller using the DCPromo utility. In Chapter 1 , I introduced mechanisms implemented by Microsoft to ensure that changes to the system registry are consistently and successfully written and are not easily corrupted by system crashes or hard-disk problems. Since AD is a centralized registry storing all user- and computer-related information for an entire organization, it would be logical to expect that similar mechanisms are implemented for the Ntds.dit database. The Ntds.dit is a database file that uses Microsoft's Extensible Storage Engine (ESE) technology, also known as Jet. All changes to AD are transactional, which means that each discrete change is committed to the database individually. For example, if a system administrator resets the password for one AD user, the administrator would be making a single, discrete transaction. To ensure that all database transactions occur consistently, AD implements a circular log. When a change is made to the AD database, it is written first to the copy of AD running in memory on the domain controller on which the change was made. The change is also written to a change log file stored on disk. If you look in the directory where the Ntds.dit file is stored on a given domain controller (Fig. 11.1 ), you'll see several files in addition to the database file: Figure 11.1: The contents of the %SystemRoot%\ntds folder on a given domain controller  Three log files — Edb.log (the main log file for the AD database), Res1.log, and Res2.log. Each log file is roughly 10 MB. Res1.log and Res2.log files serve as reserves in case the disk partition that stores these log files runs out of disk space. If this happens, reserve log files ensure that there is enough space on the disk to write any uncommitted transactions to the database before shutting down the server.  Transaction checkpoint file — Edb.chk. This file keeps track of the last transaction successfully committed to the Ntds.dit file. If the domain controller crashes before all in-memory changes are committed to the Ntds.dit file, the checkpoint file would allow a quick and easy replay of any transactions in the log that hadn't been committed before the crash. Note The checkpoint file isn't required for AD to recover itself after a crash. But recovering without it takes much longer because the system must scan the entire transaction log to determine which changes were committed to the database file. When designing and implementing AD infrastructure, it is essential to take into account performance, fault tolerance and disaster recovery. While promoting a member server into a domain controller using the DCPromo utility, you're given the choice of where you want to store the Ntds.dit file (the AD database), the SYSVOL directory (a required shared directory that exists on domain controllers), and the AD log files. Note that there are lots of recommendations for choosing the right configuration for servers that you plan to promote to AD domain controllers. In general, the ideal configuration of a domain controller must have several physical disks. Most authors, including those of Microsoft's official documentation, recommend the following disk configuration for an AD domain controller:  One physical disk for the operating system files and page files  One physical disk for the Ntds.dit database file, which tends to grow significantly with time  One physical disk for AD log files At a minimum, try to ensure that the system page file and AD log files are on separate disk spindles; both typically see the largest disk activity when a domain controller is in production. Backing Up Active Directory Since all the files comprising AD (including Ntds.dit) are continually in use on Windows 2000 and Windows Server 2003 domain controllers, you can't simply copy the AD database to the backup media as you would with any standard user data file (Fig. 11.2 ). Note that in this respect, the AD database behaves similarly to the SAM registry hive. (This was shown in Chapter 9 .) Figure 11.2: During an attempt to copy the AD database of the running Windows 2000 or Windows Server 2003 domain controller, the system displays this error message As explained in Chapter 2 , the built-in Backup utility enables you to perform an online backup of Active Directory. A backup of AD is performed whenever you include System State data as part of a backup on a Windows 2000 or Windows Server 2003 domain controller. Note Although the built-in Backup utility supplied with Windows 2000 Server and Windows Server 2003 can perform an online backup of the Active Directory database, some organizations may prefer to use more robust third-party applications. If you want a third-party backup solution, chose a product compatible with your OS (Windows 2000 or Windows Server 2003). The product must be able to backup Active Directory or provide a separate addon component capable of performing this task. Note that legacy versions of backup products cannot understand the AD format and are unable to back it up. Several leading manufacturers in the field of Windows Servers backup and recovery already supply the products supporting Windows Server 2003. For example, VERITAS (http://www.veritas.com) has released the BackupExec 9.0 for Windows Servers, which includes support for Windows 2000 and Windows Server 2003. Restoring Active Directory Physically restoring the Active Directory database on the domain controller from a backup is a straightforward procedure. However, there are some important issues that need to be taken into account when performing any AD restore operation, including:  On networks with more than one domain controller, the AD database is automatically replicated and updated among domain controllers. Therefore, the AD database exists in several locations.  You can perform AD backup only in its entirety, using a full backup. It is impossible perform an incremental backup of AD. For example, if you decide to restore the AD database from the backup, you will need to make the following decisions:  Do you need to restore AD on a local domain controller only? If the problem is limited to the local domain controller, and if other domain controllers contain valid replicas of the AD database, you can perform a non-authoritative restore. After you regain functionality on the failed domain controller, it will receive updates from other domain controllers using AD replication to bring its data store up-to-date.  Have other domain controllers also failed, or do you think their AD replicas may contain invalid or undesirable data? In either situation, you'll need to perform authoritative restore. To do so, you must manually designate the copy of the AD database that you want to restore. The local domain controller will be authoritative, and the "master" copy of the AD database from this domain controller will be replicated to other domain controllers. Performing a Non-Authoritative Restore It makes sense to perform non-authoritative restore if only the local domain controller has failed; other domain controllers on your network should be up and running, and AD replicas on those domain controllers should be intact and valid. In this case, you will have two options:  Simply reinstall the OS (Windows 2000 Server or Windows Server 2003), join the newly installed server to a domain, and promote it to a domain controller. The normal AD replication process will then repopulate the domain controller with current directory information.  Start the failed domain controller in Directory Services Restore Mode, and then restore the AD database from the backup copy. To use the second approach: 1. Start the failed domain controller and press <F8> at the Boot Loader menu. 2. When the Windows Advanced Options Menu appears, select the Directory Services Restore Mode (Windows domain controllers only) option. 3. Once you select Directory Services Restore Mode, Windows will start in a safe mode and ask you to log on. Log on as a member of the Administrators group. Note The processes that take place when any Windows NT-based operating system (including Windows 2000, Windows XP, and Windows Server 2003) is starting up, as well as the Boot Loader menu and the Windows Advanced Options Menu, were covered in detail in Chapter 6 . 4. After successful logon, run your backup application and use the option to restore AD. For example, using the built-in Backup utility, you must select the backup media and then set the System State checkbox (Fig. 11.3 ). Figure 11.3: Restoring Active Directory as part of the System State data restore process Note If you restore System State data to restore AD and don't designate an alternate location for the restored data, you'll overwrite all System State data in the current installation with that from the backup. 5. Having set the required restore options, click the Start Restore button. Once the restore procedure is accomplished, Backup will display a dialog prompting you to restart the domain controller. Click Yes. Once the restored domain controller restarts, it should begin participating in AD replication and receiving directory updates from the other domain controllers. Performing an Authoritative Restore Authoritative restore is required when other domain controllers fail or if their replicas of the AD database contain corrupted or invalid data. In either case: 1. Manually designate the copy of the AD database that you restore. 2. Perform an authoritative restore of AD. This is similar to performing a non- authoritative restore except that it requires an extra step after the restore operation (using either the built-in Backup utility or a third-party tool) is complete. Therefore, proceed as though performing a non-authoritative restore, until the last step of this procedure — answer No, when prompted to restart the server. Note This step is critical; without it, the restore will be non-authoritative when the server restarts. Thus, if other domain controllers contain undesirable data, you will reinherit it from other AD replicas. 3. After performing the AD restoration, you will need to tag the restored copy of the AD database as an authoritative copy. To do so, open a Command Prompt window and issue the following command: ntdsutil. 4. At the ntdsutil: prompt, type authoritative restore and press <Enter>. This puts ntdsutil into Authoritative Restore mode. 5. At the authoritative restore: prompt, type restore database to set the entire database you just restored as authoritative. Alternately, you can tag as authoritative any subtree of the restored AD database (for example, an individual organizational unit). To do so, type in the LDAP (Lightweight Directory Access Protocol) string identifying the portion of AD being authoritatively restored, for example: restore subtree OU=managers, DC=Alist, DC=com 6. Answer Yes when prompted to confirm authoritative restore. 7. Select the Quit option, then press <Enter> twice to exit back to a command prompt. 8. Close the Command Prompt session, then restart the computer. When the system restarts, all other domain controllers in this domain will designate the AD database (or a portion of it) as the authoritative "master" copy and use it to reinitiate the contents of their own AD replicas. Note When you perform an authoritative restore of AD, you'll lose any object and schema configuration data created after the AD backup was created (or in the branch of AD being authoritatively restored). Resetting the Recovery Console Administrator Password on a Domain Controller When you promote your computer running Windows 2000 Server or Windows Server 2003 to a domain controller, you enter a Directory Service Restore Mode Administrator password, which is used by the Recovery Console. This password is required to login to Directory Services Restore Mode; without it, you will be unable to perform the AD restore procedures. This password is separate from the Administrator password stored in Active Directory. As previously noted in this chapter, the Directory Service Restore Mode Administrator password is stored in the local SAM registry hive (%SystemRoot%\System32\Config\SAM). To reset this password: 1. Shut down and restart the domain controller. 2. When the Boot Loader screen appears, press <F8> to open the Advanced Windows Options Menu. 3. Select the Directory Service Restore Mode option and log on as Administrator or as a member of the local Administrators group. (Notice that you already need the password.) 4. Use the Local User and Groups MMC snap-in or issue the following command from the command prompt: net user Administrator *. 5. Shut down and restart. Note As previously mentioned, if you have forgotten the password, you will not be able to login. Consequently, you will not be able to use the Directory Service Restore Mode to perform the AD restore operation or to reset the Directory Service Restore Mode Administrator password. However, if you remember (or guess) the original Administrator password used when Windows 2000 Server or Windows Server 2003 was installed, you can resolve this situation by following these steps: 1. Perform an alternate installation of Windows 2000/XP or Windows Server 2003 to a different drive. During installation, specify a new computer name. 2. Access the files of the Windows installation for which you need to reset the password, and replace the %SystemRoot%\System32\Config\SAM registry hive with the SAM registry hive created during the original installation (this will be the %SystemRoot% Repair\SAM file). If you don't remember the original Administrator password of your Windows 2000 Server or Windows Server 2003 installation, demote the domain controller and repromote it. . Active Directory Emergency Recovery Similar to the system registry, which is often referred. for Windows 2000 and Windows Server 2003. Restoring Active Directory Physically restoring the Active Directory database on the domain controller from a