Exchange Server DR planning: Realizing the importance of backup up Active Directory - Part 2

If you would like to read the part 1 of this article series, click here [1]

Introduction

Un-deleting Objects in AD isn't new anymore, however the ramifications of user deletions and un-deletions aren’t always well documented or understood. This is the second Article in the Exchange Server DR planning - Realizing the importance of backing up Active Directory series.

In this article, I explore what is and more importantly what is not recovered when un-deleting a Mailbox Enabled Exchange User and how this method features as part of your Exchange and Active Directory Disaster Recovery Strategy.

Background Reading?

http://support.microsoft.com/?kbid=840001 is a good place to start. It’s not a comfortable place, since it’s quite involved and rather technical when you’ve just done an “ooops” deletion, however it does cover the bases quite nicely.

One of the tools mentioned is AdRestore by Mark Russinovich and we’ll be using it to demonstrate what we’re doing in this article. You can find it at http://www.microsoft.com/technet/sysinternals/Networking/AdRestore.mspx

The method used here is called Tombstone Reanimation.

What is an object deletion?

As obvious as that sounds, let’s have a look at two Microsoft Documents called How the Data Store Works And How the Active Directory Replication Model Works Found at

http://technet2.microsoft.com/WindowsServer/en/library/54094485-71f6-4be8-8ebf-faa45bc5db4c1033.mspx?mfr=true
and
http://technet2.microsoft.com/WindowsServer/en/Library/1465d773-b763-45ec-b971-c23cdc27400e1033.mspx?mfr=true

Here Are the Extracts which are important to us:

How the Data Store Works

Storage and Removal of Object Deletions: When data is deleted from Active Directory, the data cannot simply disappear from the directory because the deletion must be replicated. Therefore, instead of deleting an object physically from the database, the directory service removes most of the attributes and then tags the object as a tombstone by setting the isDeleted attribute value to TRUE, which means that the object has been logically deleted from the directory but not yet completely removed. Tombstones are replicated to communicate object deletions. The isDeleted attribute value alerts replication partners that the object has been deleted. Objects that are identified as tombstones are moved to the hidden Deleted Objects container of their respective directory partition. Tombstones remain in the directory for a default period of 60 days, which is referred to as the tombstone lifetime.

How the Active Directory Replication Model Works

Originating Delete

A Delete request is essentially a special Modify request that does the following series of operations:

1. Sets the isDeleted attribute to TRUE, which marks the object as a tombstone (an object that has been deleted but not fully removed from the directory).

2. Changes the relative distinguished name of the object to a value that cannot be set by an LDAP application (a value that is impossible).

3. Strips all attributes that are not needed by Active Directory. A few important attributes (including objectGUID, objectSid, distinguishedName, nTSecurityDescriptor, and uSNChanged) are preserved on the tombstone.

Note:

• Because these attributes are preserved, tombstones can be restored (reanimated) by applications that use the LDAP API for undeleting an object.
• On domain controllers running Windows Server 2003 with SP1, the sIDHistory attribute is also retained on tombstone objects.

4. Moves the tombstone to the Deleted Objects container, which is a hidden container within those directory partitions that allow deletions.

On domain controllers running Windows Server 2003, you can restore tombstones in the Deleted Objects container to an active state. This means that when you delete an object you change the isDeleted attributed to true and STRIP off most of the useful attributes, INCLUDING attributes which define this object as an Exchange mailbox.

Let’s have a look at what this looks like in practice. Were going to delete a mailbox enabled user and then undelete the user and observe the effects.To start off, I’ve created a mailbox enabled user with group membership and a manager which adds a linked attribute to another object, see below:

 

Mail attributes for the mailbox enabled user are shown clearly as well.GAL visibility is shown along with the mailbox visible in the store with mail.





Next we’ll delete the user and then restore the user via AdRestore.





Running AdRestore –R lists deleted objects with a prompt to restore each one. Since I’ve only deleted one user, I’ll choose that user to restore.
The user returns, however in a not so usable state. The object by default comes back with it’s SID, it’s GUID and a few other attributes.



Linked attributes, such as group membership, manager, etc are lost, as are all the mail attributes that make this object useful in Exchange.



It needs to be enabled, a password set and the mail attributes stripped before the mailbox will re-attach via Exchange System Manager, since a few of the mail attributes are restored, but only enough to cause irritation and not provide any kind of usefulness, since the reconnect will fail, due to some of the attributes being restored.





Trying to re-connect the mailbox without clearing ALL the existing mail attributes will bring up a result like this.



Is this it? Are these all the attributes that CAN be brought back? No. Virtually any attribute can be brought back by allowing it to be part of the deleted objects tombstone, however this does involve a schema change PER attribute that you would like to be restored. How Active Directory Searches Work details this and the other values of the SearchFlags attribute, however you should be rather careful changing these values without a full understanding of what each value does and what your FORREST WIDE implications will be.

How Active Directory Searches Work can be found here: http://technet2.microsoft.com/WindowsServer/f/?en/library/8196d68e-776a-4bbc-99a6-d8c19f36ded41033.mspx

Summary

Un-deletion or reanimation of a user object, particularly of a Mailbox enabled user Object is not very helpful. The object should rather be restored as per article http://support.microsoft.com/?kbid=840001 or via 3’rd party utilities - Quest Software and Netpro both offer utilities in this space, as do a number of backup vendors. What this means, is that this method, while available, should not really feature in your disaster recovery plans, unless your backup has failed, or is unavailable. Most attributes are lost via this method, usefulness is only really found if the SID or GUID needs to be brought back without any other short term recourse.

Related Links

How to restore deleted user accounts and their group memberships in Active Directory [2]

AdRestore v1.1 [3]

How the Data Store Works [4]

How the Active Directory Replication Model Works [5]

How Active Directory Searches Work [6]