Active Directory Backup and Restore
Active Directory Backup and Restore |
|
You can also restore Active Directory information on a domain controller by restoring the System State data from backup media. This restores Active Directory as well as the other System State components on which Active Directory depends. There are two general methods for restoring Active Directory from backup media: nonauthoritative and authoritative.
Nonauthoritative restore means that when a domain controller is restored from backup media, the restored data is updated through normal replication. Each restored directory partition is updated with that of its replication partners. One example of where you use nonauthoritative restore is a hard disk failure that requires replacement of the primary hard disk on a domain controller. In this case, you must format the new disk, recreate the partitions as they were before the crash, reinstall Windows 2000 Server on the primary partition, restore whatever data files you had on the computer, and then restore your distributed services, including the entire Active Directory. Because you use the Backup tool to restore the distributed services (including Active Directory), the restore operation is nonauthoritative. Therefore, any replicated data on the computer you restored, such as Active Directory data, is automatically updated through replication with your other domain controllers. The Backup tool allows you to nonauthoritatively restore Active Directory.
Authoritative restore means that after Active Directory is restored nonauthoritatively from a backup medium that the entire directory, a subtree, or individual objects can be designated to take precedence over any other instances of those objects on replicated domain controllers. So, through normal replication, the restored domain controller becomes authoritative in relation to its replication partners. Even if the authoritatively restored replica set is older than the current replicas, the older data is replicated to all of its replication partners. Authoritative restore is typically used to restore a system to a previously known state, for example before objects were erroneously deleted. The Ntdsutil command-line tool allows you to authoritatively restore the entire directory, a subtree, or individual objects provided they are leaf objects.
When you restore Active Directory from backup media, note the following:
By default, the Backup tool operates in nonauthoritative restore mode, which is to say, when you restore data by using the Backup tool and no other tool, you are restoring data nonauthoritatively. When the domain controller is brought online after a nonauthoritative restore, it detects that the restored data hasn't been updated since the backup was performed, and then it begins receiving and applying updates through normal replication with its replication partners. Therefore, any directory updates that occurred after the backup was created are applied after restore as part of the normal replication process. Replication reconstructs the replication metadata for the updates that originated on the restored domain controller between the time the server was last backed up and the time at which it is restored from backup. For more information about how metadata is reconstructed, see "Active Directory Replication" in this book.
You can restore a domain controller from backup media only while Active Directory is offline. You can take Active Directory offline by placing the domain controller in Directory Services Restore Mode.
To put a domain controller into Directory Services Restore Mode
Note
When you restart the computer in Directory Services Restore Mode, you must log on to the local computer as an Administrator. To do this you must use an account name and password that is stored in the local security account database known as the Security Accounts Manager (SAM). You cannot use the name and password of the Active Directory administrator. This is because Active Directory is offline, and account verification cannot occur. Rather, the SAM accounts database is used to control access to Active Directory on the local computer while Active Directory is offline.
After taking the domain controller offline, you can use the Restore Wizard in the Backup tool to restore the System State data, or you can use the graphical user interface to manually restore the System State data. The procedure for restoring System State data by using the wizard is described below. For information about restoring System State data manually using the GUI, see Windows 2000 Server Help.
To restore System State using the Restore Wizard
By default, the System State data is restored to the system root. Furthermore, by default, the System State data from the backup media replaces existing System State data on the domain controller. By setting advanced restore options you can change this default behavior for some of the System State components, but not for Active Directory. To change the default restore location, click Advanced on the last screen of the Restore Wizard and then choose where you want the System State data restored. If you choose an alternate location for restoring the System State data, only the system boot files, registry files, SYSVOL directory files, and Cluster service database information is restored to the alternate location. Active Directory, the COM+ class registration database, and the Certificates Services files are not restored.
Important
When you restore the System State data, the location of your system root must be the same as when you backed up the System State data.
You cannot restore into a replicated enterprise a backup image that is older than the tombstone lifetime setting for the enterprise. Tombstone lifetime is the number of days that a deleted object is maintained before the garbage collection process permanently removes it from Active Directory. The tombstoneLifeTime attribute is set on the object cn=Directory Services, cn=WindowsNT, cn=Services, cn=Configuration, dc=DomainName. The default value is 60 days, which can be adjusted. For more information about how to set the tombstone lifetime, see "Active Directory Data Storage" in this book. If your only backup is older than that, you need to reinstall the server from the Windows 2000 Server operating system CD. For more information about the tombstoneLifeTime attribute see, "Active Directory Data Storage" in this book.
If a domain controller was restored from a backup that was older than the tombstone lifetime, then the domain controller might contain deleted objects, and because the tombstones are deleted from the replica, the deletion event does not replicate into the restored domain controller. This is why Backup does not allow you to restore data from a backup that is older than the tombstone lifetime. The tombstone lifetime is the length of time that an object lives as a tombstone in the directory before being collected as garbage. The default is 60 days.
For more information about specific procedures for restoring from a backup by using the Backup tool, see Windows 2000 Server Help.
Note
If you backed up to an NTFS volume on a network share, it is recommended that you restore the data to a disk volume that is formatted for the version of NTFS used in Windows 2000, or you might lose data as well as some file and folder features. For example, permissions, Encrypting File System (EFS) settings, disk quota information, mounted drive information, and Remote Storage information are lost if you restore data backed up from such a disk volume to a disk volume that is formatted for FAT or for the version of NTFS used in Microsoft® Windows NT® version 4.0.
Because the Backup tool restores the database and registry settings, when it restores Active Directory, the Internet Protocol (IP) configuration is also restored. Additionally, the DNS, the certificate server database files, and File Replication service (FRS) are also restored. Completing restore has the following results:
The server then restarts into normal operational mode and performs the following actions:
Active Directory is interlaced with other distributed services, such as Certificate Services, FRS, Distributed file system (Dfs), system registry, and so on. Because of these dependencies that distributed services have on one another, restoring Active Directory is not an isolated operation. For example, Active Directory relies on Policies for associating policies with domains and organizational units. Unless all dependent services are restored in the same mode and from the same backup media, inconsistencies might result.
Note
If you are only backing up a file server that is not replicated throughout the forest, then these dependencies do not exist.
When you use the Backup tool to restore a Windows 2000 domain controller, it is considered nonauthoritative. This means that when the restored domain controller replicates with its replication partners in the enterprise, the restored directory partitions are updated through replication with another domain controller within the restored domain.
So, when a domain controller is restored from a backup medium, any directory updates that occurred after the backup are applied as part of the normal replication process. Replication reconstructs the replication metadata for the updates that originated on the restored domain controller between the time the server was last backed up and the time it gets restored. For more information about how metadata is reconstructed, see "Active Directory Replication" in this book.
When directory partitions are restored from a backup using the Backup tool, the domain controller might lose information about the directory updates it originated after it was backed up. For example, suppose you back up your domain controller on day 1. On day 2 you add some new objects or make modifications to Active Directory, but the new objects or modifications are not replicated to your other domain controllers because of a network problem. On day 3, a catastrophic event (unrelated to the modifications you made on day 2) forces you to restore the domain controller from your backup. In this case, the new objects or modifications that originated on the domain controller after the backup are lost because they were never replicated to your other domain controllers and, therefore, can't be applied to the restored domain controller.
If the domain controller begins originating new updates before it receives updates from its replication partners through replication, one of two things happens:
Problems can happen when the domain controller tries to determine where to restart in the update sequence number (USN) sequence. If it reuses an existing USN, serious replication problems can result. Both problems arise because the restored domain controller does not have global knowledge, it only has knowledge of itself and its current replication sources.
The solution is to generate a new database globally unique identifier (GUID) for the domain controller. This happens automatically with the restore operation. The restored domain controller assumes a new GUID and is aware of the USN for its own changes, with respect to its previous identity at the time of the last backup. The domain controller saves this state information so that replication partners do not subsequently send changes originated locally before the backup.
The restored domain controller receives the changes it originated after the backup (and before the restore) through normal replication, just as it would receive changes made by any other domain controller. Other domain controllers similarly receive changes made by the restored domain controller just as they would receive changes from a new replica.
For more information about replication, see "Active Directory Replication" in this book.
Verify the success of the restore process by checking that Active Directory, Certificate Services, and File Replication service are operational. Perform a basic check of Active Directory by browsing users, groups, and other objects that were present before the backup. You can perform an advanced verification of Active Directory by performing the following procedure:
Important
You can only perform this procedure immediately after you restore the domain controller and before you start the domain controller in normal mode and bring it online.
To perform advanced verification of Active Directory after a Backup tool restore
This entry is automatically generated by the Backup tool when restore is successful. It notifies Active Directory to perform a consistency check and to re-index database files when Active Directory is restarted. Then, the RestoreInProgress entry is automatically deleted when the process is finished. Do not add, delete, or change the value of RestoreInProgress.
Note
After the database is restored from backup media, it is not in a valid format. To cause Active Directory to make the database usable, the Backup tool adds RestoreInProgress to the NTDS registry subkey. Active Directory reads this entry during system initialization and then deletes the entry.
When the computer is restarted in normal mode, Active Directory automatically detects the recovery, performs an integrity check, and re-indexes the database. Browse the directory, and then make sure that all of the objects that were present in the directory prior to backup are restored.
Caution
Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.
It is possible to restore Active Directory to a computer other than the original computer, both computers must have the same number of disk drives. 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.
An authoritative restore means that after Active Directory is restored nonauthoritatively from a backup, the entire directory, a subtree, or individual objects can be designated to take precedence over any other instances of those objects in the forest. So, through normal replication, the restored domain controller becomes authoritative in relation to its replication partners. Even if the authoritatively restored replica set is older than the current replicas, the older data is replicated to all of its replication partners.
You perform authoritative restore after you perform nonauthoritative restore using the Backup tool. After restoring from backup with the Backup tool, you use the Ntdsutil tool to mark restored objects as authoritative so that they are propagated by the process of replication, thereby updating existing copies of those objects throughout the forest.
Important
Only the domain and configuration domain directory 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 classSchema object were created, subsequent authoritative restore might replace the new or modified classes causing serious data consistency problems.
Authoritative restore is often used in situations in which objects are inadvertently deleted from Active Directory, and the deletions are propagated to other domain controllers. To recover from such an event, you can make authoritative restore to Active Directory from a backup that was created before the objects were deleted. After the domain controller is restored, but before the domain controller is restarted, the previously deleted objects are designated as authoritative. When you bring the domain controller online, the authoritative objects are replicated to the other domain controllers through the normal replication process. The previously deleted objects are ignored during replication (that is, they are not replicated), because the authoritatively restored objects have a higher version number, which overrides the lower version numbers of previously deleted objects.
It is important to note that authoritative restore does not affect objects that were created after the backup from which you are restoring was created. When other domain controllers exist, and authoritative restore is made, any objects that were created in a directory partition after the backup remain in Active Directory. For example, if you back up the system on Monday, and then create a new user account called James Smith on Tuesday, which replicates to other domain controllers in the domain. On Wednesday, another user account, Amy Anderson, is accidentally deleted. To authoritatively restore Amy Anderson without re-entering information, you can restore the domain controller with the backup created on Monday. Then, using Ntdsutil, mark the Amy Anderson user account as authoritative. The result is that Amy Anderson is restored, without any effect on James Smith.
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 after that point are lost. You can use it to selectively modify individual objects, subtrees, organizational units, and even an entire forest, but do so only if you have identified a specific problem and you know restore can fix it.
Note
Certificate Services is not affected by authoritative and nonauthoritative restore because the data is not replicated across distributed systems. File Replication service (FRS) is affected by authoritative and nonauthoritative restore. However, the Ntdsutil command-line tool 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 policies are broken.
To perform authoritative restore of Active Directory, back up and restore the domain controller by using the Backup tool. (For more information about Backup, see "Backing Up Active Directory" earlier in this chapter.) Then after the restore operation finishes — but before reconnecting to the network — carry out the Ntdsutil commands for authoritative restore.
To authoritatively restore Active Directory
For example, to restore the Marketing OU in the Reskit.com domain, the commands are as follows:
ntdsutil
authoritative restore
Restore Subtree OU=Marketing,DC=Reskit,DC=COM
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 does so automatically.
When the restored domain controller is online and connected to the network, normal replication brings the restored domain controller up-to-date with any changes from the additional domain controllers that were not overridden by authoritative restore. Replication also propagates the authoritatively restored objects to other domain controllers in the forest. The deleted objects that 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 objectGUID and objectSID, security remains intact, and object dependencies are maintained.
For more information about using the Ntdsutil tool, see "Active Directory Diagnostics, Troubleshooting, and Recovery" in this book.
Note
The process mentioned above is primarily for authoritative restoration of only Active Directory. However, certain Active Directory objects (for example, OUs, domains and Site objects) may have group policies associated with them, and these group policies are stored in the SYSVOL directory. To authoritatively restore the Active Directory and SYSVOL, see "Authoritative Restoration of the Entire Active Directory Database" later in this chapter.
When you authoritatively restore the entire Active Directory database, you must ensure that the proper elements are authoritatively restored. You do this by copying the SYSVOL directory from the alternate location over the existing SYSVOL directory. This is necessary to ensure the integrity of the Group Policy of the computer. Use the following procedure to restore an entire Active Directory database.
To restore the entire Active Directory database
When you make authoritative restore of a portion of the Active Directory database (including Policy objects), you also must perform an additional procedure (described below) involving the SYSVOL directory. To ensure the proper elements are authoritatively restored, use the following process:
Important
When authoritatively restoring either the entire Active Directory database or selected objects, it is important that you copy the SYSVOL and policy data from the alternate location, that this be done after the SYSVOL share is published.
If the computer is in a replicated domain, it can take several minutes before the SYSVOL share is published, because it needs to synchronize with its replication partners.
If all computers in the domain are authoritatively restored and restarted at the same time, then 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 nonauthoritatively.
Authoritative restore operation restores the attributes of existing objects or restores deleted objects. It sets every attribute involved to its current value. However, the attribute values themselves don't change, but their metadata does. The metadata is changed to indicate when and where each attribute involved was given its current value. During replication, other domain controllers see this as an update, which overrides current values. Each domain controller might have a different notion of the "current value." For the authoritatively restored domain controller, the current value is as of the time of the backup. For other domain controllers, the current value is as it exists after all changes are made after the backup.
You can use the Repadmin command-line tool to verify that the authoritative restore was successful by checking the version number increase on the directory or subtree. Do this by carrying out the show metadata command followed by the exact distinguished name of the directory or subtree that you authoritatively restored. For more information about using the Repadmin tool, see "Active Directory Diagnostics, Troubleshooting, and Recovery" in this book.
Performing an authoritative restore updates the following metadata variables as described in Table 9.1.
Table 9.1 Updated Metadata Variables in Authoritative Restore
| Per Domain Controller | Result |
|---|---|
| Highest-Committed-USN attribute | Incremented by one for each object that was authoritatively restored because unique sequence numbers (USNs) are machine specific. That means they are compared only against other USNs that were issued by the current domain controller. |
| Per Object and Per Domain Controller | Result |
| USN-Changed attribute | Set to the current value of Highest-Committed-USN attribute. Two domain controllers typically have different USN-Changed attributes for the same object, even if they are synchronized. |
| Per Object | Result |
| When-Changed attribute | Set to the current time. |
| Per Attribute | Result |
| Originating-DC-GUID attribute | Set to the GUID of the current domain controller. |
| Originating-USN attribute | Set to the current value of Highest-Committed-USN attribute. |
| Version attribute | Set to a version number higher than the version number of any other copy of the object on any other domain controller. (See discussion later in this chapter.) |
| When-Changed attribute | Set to the current time. |
| Property-USN attribute | Set to the current value of Originating-USN attribute. |
| Is-Deleted attribute | A new metadata entry is made. |
Updates made by the authoritative restore appear as any other update, and replicate like other updates, with one exception. The exception with authoritative restore updates is that the version number is set high enough so that the updates made by authoritative restore are higher in version number than the normal updates.
Further, the version number increases by one hundred thousand for each day after the original backup update. (You supply the number of days.) You can override the version number.
Both parent and child trust relationships in Windows 2000 domains and Kerberos and NTLM trust relationships to other Windows NT 4.0 or Windows 2000 domains reside in the domain directory partition. 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 might negate communication with domain controllers from other domains. If an older computer account password is restored, it could negate communications between the member's workstation or server and the domain controller. If the objects that you are authoritatively restoring affect trust relationships or computer account passwords, you need to 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; except for computer accounts. The previous password is also maintained. Therefore, performing authoritative restore with a backup that is older than 14 days can affect the trust relationships.
The extent to which trust relationships are affected by authoritative restore depends upon the scope of the restore — the more of the domain hierarchy included in the restore, the greater that trust relationships are affected. To minimize the effort involved with resetting trusts and rejoining computers, you need to perform regular backups. Yet, there are always 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 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 Windows 2000 Resource Kit Tools Help, which is included on the Windows 2000 Resource Kit companion CD, or see "Active Directory Diagnostics, Troubleshooting, and Recovery" in this book.
For more information about parent/child trust relationships, see "Active Directory Logical Structure" in this book.