Applies To: Windows Server 2008 R2
Accidental deletion of Active Directory objects is a common occurrence for users of Active Directory Domain Services (AD DS) and Active Directory Lightweight Directory Services (AD LDS).
In Windows Server 2008 Active Directory domains, you could recover accidentally deleted objects from backups of AD DS that were taken by Windows Server Backup. You could use the ntdsutil authoritative restore command to mark objects as authoritative to ensure that the restored data was replicated throughout the domain. For more information about backup and authoritative restore of deleted Active Directory objects in AD DS, see the AD DS Backup and Recovery Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkID=125451).
The drawback to the authoritative restore solution was that it had to be performed in Directory Services Restore Mode (DSRM). During DSRM, the domain controller being restored had to remain offline. Therefore, it was not able to service client requests. (When you restored objects in AD LDS, you were required to stop your AD LDS instance. However, when you restored objects in AD LDS, you did not have to boot into DSRM.)
Another shortcoming of authoritatively restoring Active Directory objects from AD DS backups was that any changes to the objects that occurred between the backup time and the restore time could not be recovered. Consider the following scenario: An administrator assigns a new group membership to a user account and then accidentally deletes this user account. The administrator then tries to authoritatively restore this user account from the AD DS backup that was taken three days ago. The user object is indeed recovered, but its most recent group membership information is not restored. The user account remains in the state that it was in at the time that the AD DS backup was performed three days ago.
In Windows Server 2003 Active Directory and Windows Server 2008 AD DS, you could recover deleted Active Directory objects through tombstone reanimation. Introduced in Windows Server 2003, tombstone reanimation took advantage of the fact that Active Directory kept the deleted objects in the database for a period of time before physically removing them. In Windows Server 2003 and Windows Server 2008, a deleted Active Directory object was not physically removed from the database immediately. Instead, the object’s distinguished name (also known as DN) was mangled, most of the object’s non-link-valued attributes were cleared, all of the object’s link-valued attributes were physically removed, and the object was moved to a special container in the object's naming context (also known as NC), named Deleted Objects. The object, now called a tombstone, became invisible to normal directory operations. Tombstones could be reanimated anytime within the tombstone lifetime period and become live Active Directory objects again.
The default tombstone lifetime was 180 days in Windows Server 2003 with Service Pack 1 (SP1), Windows Server 2003 with Service Pack 2 (SP2), and Windows Server 2008. You could use tombstone reanimation to recover deleted objects without taking your domain controller or your AD LDS instance offline. However, the reanimated objects’ link-valued attributes (for example, group memberships of user accounts) that were physically removed and the non-link-valued attributes that were cleared were not recovered. Therefore, administrators could not rely on tombstone reanimation as the ultimate solution for accidental deletion of objects. For more information about tombstone reanimation, see Reanimating Active Directory Tombstone Objects (http://go.microsoft.com/fwlink/?LinkID=125452).
The following illustration shows an Active Directory object’s life cycle in the Windows Server 2003 and Windows Server 2008 environments, which support tombstone reanimation. It also shows the life cycle of Active Directory objects in a Windows Server 2008 R2 environment with Active Directory Recycled Bin disabled, which is the default behavior when your environment’s forest functional level is first set to Windows Server 2008 R2.
The drawback to the authoritative restore solution was that it had to be performed in Directory Services Restore Mode (DSRM). During DSRM, the domain controller being restored had to remain offline. Therefore, it was not able to service client requests. (When you restored objects in AD LDS, you were required to stop your AD LDS instance. However, when you restored objects in AD LDS, you did not have to boot into DSRM.)
Another shortcoming of authoritatively restoring Active Directory objects from AD DS backups was that any changes to the objects that occurred between the backup time and the restore time could not be recovered. Consider the following scenario: An administrator assigns a new group membership to a user account and then accidentally deletes this user account. The administrator then tries to authoritatively restore this user account from the AD DS backup that was taken three days ago. The user object is indeed recovered, but its most recent group membership information is not restored. The user account remains in the state that it was in at the time that the AD DS backup was performed three days ago.
In Windows Server 2003 Active Directory and Windows Server 2008 AD DS, you could recover deleted Active Directory objects through tombstone reanimation. Introduced in Windows Server 2003, tombstone reanimation took advantage of the fact that Active Directory kept the deleted objects in the database for a period of time before physically removing them. In Windows Server 2003 and Windows Server 2008, a deleted Active Directory object was not physically removed from the database immediately. Instead, the object’s distinguished name (also known as DN) was mangled, most of the object’s non-link-valued attributes were cleared, all of the object’s link-valued attributes were physically removed, and the object was moved to a special container in the object's naming context (also known as NC), named Deleted Objects. The object, now called a tombstone, became invisible to normal directory operations. Tombstones could be reanimated anytime within the tombstone lifetime period and become live Active Directory objects again.
The default tombstone lifetime was 180 days in Windows Server 2003 with Service Pack 1 (SP1), Windows Server 2003 with Service Pack 2 (SP2), and Windows Server 2008. You could use tombstone reanimation to recover deleted objects without taking your domain controller or your AD LDS instance offline. However, the reanimated objects’ link-valued attributes (for example, group memberships of user accounts) that were physically removed and the non-link-valued attributes that were cleared were not recovered. Therefore, administrators could not rely on tombstone reanimation as the ultimate solution for accidental deletion of objects. For more information about tombstone reanimation, see Reanimating Active Directory Tombstone Objects (http://go.microsoft.com/fwlink/?LinkID=125452).
The following illustration shows an Active Directory object’s life cycle in the Windows Server 2003 and Windows Server 2008 environments, which support tombstone reanimation. It also shows the life cycle of Active Directory objects in a Windows Server 2008 R2 environment with Active Directory Recycled Bin disabled, which is the default behavior when your environment’s forest functional level is first set to Windows Server 2008 R2.
Windows Server 2008 R2 Active Directory Recycle Bin helps minimize directory service downtime by enhancing your ability to preserve and restore accidentally deleted Active Directory objects without restoring Active Directory data from backups, restarting AD DS, or rebooting domain controllers. When you enable Active Directory Recycle Bin, all link-valued and non-link-valued attributes of the deleted Active Directory objects are preserved and the objects are restored in their entirety to the same consistent logical state that they were in immediately before deletion. For example, restored user accounts automatically regain all group memberships and corresponding access rights that they had immediately before deletion, within and across domains.
The following illustration shows a new Active Directory object’s life cycle in Windows Server 2008 R2 when Active Directory Recycle Bin is enabled.
The following illustration shows a new Active Directory object’s life cycle in Windows Server 2008 R2 when Active Directory Recycle Bin is enabled.
After you enable Active Directory Recycle Bin, when an Active Directory object is deleted the system preserves all the object’s link-valued and non-link-valued attributes and the object becomes “logically deleted,” which is a new state in Windows Server 2008 R2. A deleted object is moved to the Deleted Objects container, with its distinguished name mangled. A deleted object remains in the Deleted Objects container in a logically deleted state throughout the duration of the deleted object lifetime.
Within the deleted object lifetime, you can recover a deleted object by using the procedures in Step 2: Restore a Deleted Active Directory Object and make it a live Active Directory object again. Within the deleted object lifetime, you can also recover a deleted object through an authoritative restore from a backup of AD DS.
Within the deleted object lifetime, you can recover a deleted object by using the procedures in Step 2: Restore a Deleted Active Directory Object and make it a live Active Directory object again. Within the deleted object lifetime, you can also recover a deleted object through an authoritative restore from a backup of AD DS.
After the deleted object lifetime expires, the logically deleted object is turned into a recycled object and most of its attributes are stripped away. A “recycled object,” which is a new state in Windows Server 2008 R2, remains in the Deleted Objects container until its recycled object lifetime expires. After the recycled object lifetime expires, the garbage-collection process physically deletes the recycled Active Directory object from the database.
By default, a recycled object in Windows Server 2008 R2 preserves the same set of attributes as a tombstone object in Windows Server 2003 and Windows Server 2008. To change the set of attributes that are preserved on a Windows Server 2008 R2 recycled object (that is, to make sure that a particular attribute of an object is preserved when this object becomes recycled), set the value of the searchFlags attribute in the schema to 0x00000008. This process is similar to the process for preserving attributes on Windows Server 2003 and Windows Server 2008 tombstone objects. For more information, see Search-Flags Attribute (http://go.microsoft.com/fwlink/?LinkID=125453).
 Important |
|---|
| A recycled object cannot be recovered with the procedures in Step 2: Restore a Deleted Active Directory Object or with the steps in Reanimating Active Directory Tombstone Objects (http://go.microsoft.com/fwlink/?LinkID=125452). This is a new behavior in Windows Server 2008 R2. Do not attempt to recover a recycled object through an authoritative restore from a backup of AD DS. Instead, we recommend that you recover deleted objects with Active Directory Recycle Bin during the deleted object lifetime. |
| Important |
|---|
| When Active Directory Recycle Bin is enabled, all objects that were deleted before Active Directory Recycle Bin was enabled (that is, all tombstone objects) become recycled objects. These objects are no longer visible in the Deleted Objects container, and they cannot be recovered with Active Directory Recycle Bin. The only way to restore these objects is through an authoritative restore from a backup of AD DS that was taken of the environment before Active Directory Recycle Bin was enabled. |
The deleted object lifetime is determined by the value of the msDS-deletedObjectLifetime attribute. The recycled object lifetime is determined by the value of the legacy tombstoneLifetime attribute. By default, msDS-deletedObjectLifetime is set to null. When msDS-deletedObjectLifetime is set to null, the deleted object lifetime is set to the value of the recycled object lifetime. By default, the recycled object lifetime, which is stored in the tombstoneLifetime attribute, is also set to null. In Windows Server 2008 R2, when tombstoneLifetime is set to null, the recycled object lifetime defaults to 180 days.
You can modify the values of the msDS-deletedObjectLifetime and tombstoneLifetime attributes anytime. When msDS-deletedObjectLife is set to some value other than null, it no longer assumes the value of tombstoneLifetime. For more information about how to modify the deleted object lifetime and the recycled object lifetime, see Modifying the tombstone lifetime and deleted object lifetime section in Appendix A: Additional Active Directory Recycle Bin Tasks.
You can modify the values of the msDS-deletedObjectLifetime and tombstoneLifetime attributes anytime. When msDS-deletedObjectLife is set to some value other than null, it no longer assumes the value of tombstoneLifetime. For more information about how to modify the deleted object lifetime and the recycled object lifetime, see Modifying the tombstone lifetime and deleted object lifetime section in Appendix A: Additional Active Directory Recycle Bin Tasks.
To determine if you can use a particular backup of AD DS to successfully recover a previously deleted object through an authoritative restore, verify the value of the resultant backup lifetime in your Active Directory forest. The value of the resultant backup lifetime in an Active Directory forest specifies the number of days during which any backup that is taken of this forest is most effective when it is used to restore an Active Directory environment. (The restore tasks can include recovering accidentally deleted data or promoting domain controllers from media.)
The value of the resultant backup lifetime is the smaller value of the following two attributes: the msDS-deletedObjectLifetime attribute, which stores the deleted object lifetime, and the tombstoneLifetime attribute, which stores the recycled object lifetime. By default, msDS-deletedObjectLifetime is set to null. When msDS-deletedObjectLifetime is set to null, the deleted object lifetime is set to the value of the recycled object lifetime. By default, tombstoneLifetime is also set to null. When tombstoneLifetime is set to null, the recycled object lifetime defaults to 180 days. Therefore, by default, the value of the resultant backup lifetime in an Active Directory forest is set to 180 days.
If the value of the deleted object lifetime (in the msDS-deletedObjectLifetime attribute) is smaller than the value of the recycled object lifetime (in the tombstoneLifetime attribute), the authoritative restore of a deleted object from a backup will be successful only for the duration of the deleted object lifetime. Attempts to recover a recycled object using authoritative restore from a backup will fail because after the restored object replicates, it will be recycled again. This scenario is especially true if you recycle deleted objects manually, which makes the deleted object lifetime shorter than the recycled object lifetime.
The value of the resultant backup lifetime is the smaller value of the following two attributes: the msDS-deletedObjectLifetime attribute, which stores the deleted object lifetime, and the tombstoneLifetime attribute, which stores the recycled object lifetime. By default, msDS-deletedObjectLifetime is set to null. When msDS-deletedObjectLifetime is set to null, the deleted object lifetime is set to the value of the recycled object lifetime. By default, tombstoneLifetime is also set to null. When tombstoneLifetime is set to null, the recycled object lifetime defaults to 180 days. Therefore, by default, the value of the resultant backup lifetime in an Active Directory forest is set to 180 days.
| Important |
|---|
| We recommend that the resultant backup lifetime in your Active Directory environment be equal to or greater than 180 days to ensure that the backups that you can use to authoritatively restore an Active Directory environment are effective and usable for a long period of time. Although it is possible for you to modify the values of the deleted object lifetime (which is stored in the msDS-deletedObjectLifetime attribute) and the recycled object lifetime (which is stored in the tombstoneLifetime attribute), we do not recommend this because it can cause problems in your environment. |
You can use Active Directory Recycle Bin to restore all deleted objects that were previously stored in AD DS. However, if you use Active Directory Recycle Bin to restore deleted Group Policy objects (GPOs) or Exchange-related objects that were previously stored in AD DS, any application-specific data for these objects that was not stored in AD DS will not be restored.
You can use the Group Policy Management snap-in to back up and restore GPOs and then manually re-create links to the appropriate site, domain, or OU objects in AD DS. For more information, see Back Up, Restore, Import, and Copy Group Policy Objects (http://go.microsoft.com/fwlink/?LinkId=146609).
We do not recommend that you use Active Directory Recycle Bin to restore Exchange configuration objects that were accidentally deleted with Exchange administrative tools. Instead, the recommended approach is to re-create these objects by using the supported Exchange administrative tools. If you accidentally delete an Exchange configuration object without using Exchange administrative tools, try to restore this object with Active Directory Recycle Bin as quickly as possible. However, any configuration changes that occurred in the environment between this object’s deletion and its restoration will not be recovered, and they can result in Exchange configuration problems. For example, if you use Active Directory Recycle Bin to recover accidentally deleted Exchange recipients, such as contacts, users or distribution groups, be sure to reapply current Exchange policies or other configuration data to them. This data could have been modified since these objects were deleted.
You can use the Group Policy Management snap-in to back up and restore GPOs and then manually re-create links to the appropriate site, domain, or OU objects in AD DS. For more information, see Back Up, Restore, Import, and Copy Group Policy Objects (http://go.microsoft.com/fwlink/?LinkId=146609).
We do not recommend that you use Active Directory Recycle Bin to restore Exchange configuration objects that were accidentally deleted with Exchange administrative tools. Instead, the recommended approach is to re-create these objects by using the supported Exchange administrative tools. If you accidentally delete an Exchange configuration object without using Exchange administrative tools, try to restore this object with Active Directory Recycle Bin as quickly as possible. However, any configuration changes that occurred in the environment between this object’s deletion and its restoration will not be recovered, and they can result in Exchange configuration problems. For example, if you use Active Directory Recycle Bin to recover accidentally deleted Exchange recipients, such as contacts, users or distribution groups, be sure to reapply current Exchange policies or other configuration data to them. This data could have been modified since these objects were deleted.
No comments:
Post a Comment