Reanimating Active Directory Tombstone Objects

While it may not be your favorite topic to think about, accidental data loss is a fact of life and, as an IT professional, you have to be prepared for all sorts of recovery scenarios. In the April 2007 issue of TechNet Magazine, I discussed the importance of having a plan in

place for recovering Active Directory® users and groups. In that article, available attechnetmagazine.com/issues/2007/04/ADRecovery, I covered the mechanics of object linking, replication, deletion, and authoritative restores. Unfortunately, the authoritative restore function requires that you start a domain controller (DC) in Directory Service Restore Mode (DSRM). Doing this renders the DC unavailable for the duration of the restore operation.

There is another approach you should be aware of. Tombstone reanimation (which has nothing to do with zombies) provides the only way to recover deleted objects without taking a DC offline, and it's the only way to recover a deleted object's identity information, such as its objectGUID and objectSid attributes. It neatly solves the problem of recreating a deleted user or group and having to fix up all the old access control list (ACL) references, which contain the objectSid of the deleted object. Just keep in mind that tombstone reanimation does have its own limitations, which I will discuss, so you'll still want to keep authoritative restores in your box of tricks.

Tombstone reanimation was introduced in Windows Server® 2003 Active Directory to simplify certain data recovery scenarios. This feature takes advantage of the fact that Active Directory keeps deleted objects in the database for a period of time before physically removing them. In this article I'll give you a detailed description of how Active Directory deletes and reanimates objects, and I'll show how you can recover deleted objects using standard Microsoft tools.

What Is a Tombstone?

When Active Directory deletes an object from the directory, it does not physically remove the object from the database. Instead, Active Directory marks the object as deleted by setting the object's isDeleted attribute to TRUE, stripping most of the attributes from the object, renaming the object, and then moving the object to a special container in the object's naming context (NC) named CN=Deleted Objects. The object, now called a tombstone, is invisible to normal directory operations. It does not show up in any Microsoft® Management Console (MMC) snap-ins, and most Lightweight Directory Access Protocol (LDAP) utilities are blissfully unaware of the tombstone's existence. The tombstone is, for all intents and purposes, gone. The data, however, is still there—it's just invisible. So why does Active Directory keep tombstones, otherwise deleted objects, in the database?

While invisible to other processes, a tombstone is visible to the Active Directory replication process. In order to make sure the deletion is performed on all the DCs that host the object being deleted, Active Directory replicates the tombstone to the other DCs. Thus the tombstone is used to replicate the deletion throughout the Active Directory environment.

The Lifetime of a Tombstone

Active Directory typically deletes an object from the directory in response to an LDAP delete protocol operation or a Security Accounts Manager (SAM) delete operation. This operation is called the originating delete and is distinct from the delete operations performed by the Active Directory replication process. Note that this discussion does not concern dynamic objects, which have a different delete mechanism and are directly deleted by Active Directory when their time to live (TTL) expires.

When Active Directory receives the delete operation, it first runs through a checklist to make sure the object is allowed to be deleted. This process is surprisingly involved as it makes sure the following criteria are all true:

• The isDeleted attribute of the object is not already set to TRUE. (You can't delete an already deleted object!)
• The "private object" resource-specific security descriptor control flag is not set in the object's security descriptor. (This appears to be an undocumented "feature." The private object flag is bit 1 of the Sbz1 byte of the security descriptor structure.)
• The "disallow delete" bit (0x80000000) is not set in the systemFlags attribute of the object.
• The isCriticalSystemObject attribute of the object is not set to TRUE.
• The object's security descriptor grants the appropriate access rights to the user to delete the object. (More specifically, the user is allowed to delete the object itself and is allowed to delete a child from the parent object.)
• The object is not a cross-reference object (objectClass = crossRef) for an existing naming context.
• The object does not have any subordinate objects. (If the LDAP delete operation includes the LDAP "tree delete" control object id, Active Directory will automatically delete subordinate objects as well, unless they have the isCriticalSystemObject attribute set to TRUE. This prevents critical system objects from being deleted inadvertently as part of a tree deletion operation. You can of course delete these objects individually.)
• The object is not a critical internal object (for instance, it isn't the nTDSDSA object for the DC or placeholder objects for ancestors of the NC heads).

In addition to these criteria being true, Active Directory must also be in an appropriate state to process the delete operation. For example, if Active Directory is in the process of renaming a domain, it will not delete a domain trust account or a crossRef object.

If it is determined that the object can in fact be deleted, Active Directory proceeds to turn the object into a tombstone. Active Directory first strips unnecessary attributes from the object, leaving those specified in Figure 1 and those defined in the schema to be retained in the tombstone. (See the section "Recovering Object Attributes" for more information on this.) It then changes the relative distinguished name (RDN) of the object to CN=<old RDN>\0ADEL:<objectGUID>, where \0A indicates the ASCII linefeed character and <objectGUID> is the objectGUID expressed as a string. The lastKnownParent attribute is then set to the distinguished name (DN) of the parent container of the object and the isDeleted attribute is set to TRUE. Active Directory then removes all forward and backward link attributes from the object. Finally, if the systemFlag attribute of the object does not have the "disallow move on delete" bit set, Active Directory moves the object to the CN=Deleted Objects container for the NC. (See the "systemFlags Attribute and Object Behavior" sidebar for more information on this topic.)

  Figure 1 Attributes saved in a tombstone

Hard-Coded to Be Saved

attributeID

attributeSyntax

dnReferenceUpdate

dNSHostName

flatName

governsID

groupType

instanceType

lDAPDisplayName

legacyExchangeDN

mS-DS-CreatorSID

mSMQOwnerID

nCName

objectClass

objectGUID

objectSid

oMSyntax

proxiedObejctName

replPropertyMetaData

sAMAccountName

securityIdentifier

sIDHistory

subClassOf

systemFlags

trustPartner

trustDirection

trustType

trustAttributes

userAccountControl

uSNChanged

uSNCreated

whenCreated

Saved Due to searchFlags Setting

msDS-AdditionalSam­AccountName

msDS-Auxiliary-Classes

msDS-Entry-Time-To-Die

msDS-IntId

msSFU30NisDomain

nTSecurityDescriptor

uid

You should note that the CN=Deleted Objects folder is flat and has no object hierarchy. You might think this would cause name conflicts if you deleted two different objects with the same CN. This isn't the case, though. Since the objectGUID is incorporated into each tombstone's RDN, each tombstone's RDN is unique within the CN=Deleted Objects container.

Obviously, objects don't remain in the CN=Deleted Objects container forever. The default tombstone lifetime is 60 days for forests initially built using Windows® 2000 and Windows Server 2003, and 180 days for forests that were initially built with Windows Server 2003 SP1. You can change the tombstone lifetime by setting the tombstoneLifetime attribute of the CN=Directory Service,CN=Windows NT, CN=Services,CN=Configuration, DC=<root domain> object.

Every 12 hours, each domain controller starts a garbage collection process. (This can be changed by setting a new value for the garbageCollPeriod attribute of the CN=Directory Service,CN=Windows NT, CN=Services,CN=Configuration,DC=<root domain> object.) This garbage collection scans all of the tombstones on the DC and physically deletes any that are older than the tombstone lifetime.

Using LDP to Find Tombstones

LDP is a Windows Explorer-like utility for working with Active Directory. LDP was originally designed by the Active Directory development team to test its LDAP code while Active Directory was under development. Now part of the Windows Server 2003 Support tools, LDP has evolved into a robust tool for working with Active Directory.

Even though tombstones are invisible to normal directory operations, you can find tombstone objects in Active Directory using LDAP search operations and special LDAP extensions called controls. Controls are a mechanism, defined in the LDAP standard, used to extend the LDAP protocol to provide additional functionality beyond what is defined in the LDAP standard while remaining compatible with other LDAP-compliant software. Active Directory supports 22 controls, including the Return Deleted Objects control. When used to extend an LDAP search operation, this control retrieves deleted objects that would otherwise be invisible.

To demonstrate how this works, I log into the foo.local domain with Enterprise Administrator credentials and then use the Active Directory Users and Computers (ADUC) MMC snap-in to create a user object (CN=John Smith,CN=Users,DC=foo, DC=local), as shown in Figure 2. I then delete the user object, again using ADUC.

Figure 2 Using ADUC to create a user (Click the image for a larger view)

Now I can run the LDP program and use it to display the tombstone for the deleted user. The first step is to connect LDP to a specific DC and authenticate using the appropriate credentials. To connect to the DC, I simply select the Connect option from the Connection menu. Since I am running LDP on the DC, I just press OK to connect to the local DC. If you are running LDP remotely, you must specify the name of the DC you want to connect to. After I successfully connect, LDP displays the attributes of rootDSE—this contains attributes describing the state and configuration of the DC itself (seeFigure 3).

Figure 3 LDP connected to a DC (Click the image for a larger view)

Now, to authenticate to the DC using domain or enterprise administrator credentials, I select Bind from the Connection menu. Because I'm already logged in as an Enterprise Administrator for the forest (Domain Administrators and Enterprise Administrators by default have the rights to list and reanimate objects in the CN=Deleted Objects container), I simply leave the Username and Password in the Bind dialog empty and press OK. Otherwise, I could enter the appropriate credentials into the Bind dialog.

Next I want to list the contents of the CN=Deleted Objects,DC=foo=DC,local con- tainer. You will normally never see the CN=Deleted Objects container because the container itself is marked as deleted. The only way you can search the CN=Deleted Objects container is to use the Return Deleted Objects LDAP control.

To use this control with LDP, go to the Browse menu and select Search. The search dialog shown inFigure 4 will appear. The Base Dn field lets you specify where in the directory tree to start searching. I enter the DN of the Deleted Objects container for the domain–in this example, the DN is CN=Deleted Objects,DC=foo,DC=local.

Figure 4 LDP Search dialog 

In the Filter field, I specify the search criteria LDP will use. The default value is (objectClass=*), which instructs the search to return all objects that have a value for the objectClass attribute. Because even deleted objects in Active Directory have a value for objectClass, the default filter will return every object within the search scope. In this example, I change the filter to (objectClass=user), limiting the search to user objects. This will make it easier to find the deleted John Smith user among the possibly thousands of tombstones in the CN=Deleted Objects container.

You may find that there are more objects in the CN=Deleted Objects container than Active Directory will return in a single search operation. To address this problem, you would typically use a paged LDAP search, which returns the results a group at a time. However, LDP does not let you specify both a paged and extended search. So you'll have to refine your LDAP filter to locate the object you want.

The Scope radio buttons let you specify how much of the directory tree to search. A base search will only return the object specified by the Base Dn field. A one-level search will return objects that are immediately subordinate to the Base Dn object. And a subtree search will return all objects subordinate to the Base Dn object. Because the CN=Deleted Objects folder is flat, I use a one-level search to retrieve all tombstones.

So far, I have merely outlined a conventional LDAP search. If I were to run it now, LDP would display an error indicating that CN=Deleted Objects,DC=foo,DC=com does not exist since it's marked deleted. I still have to include the Return Deleted Objects LDAP control with the search operation. To do so, I click the Options button on the Search dialog and select Extended for the Search Call Type, as shown in Figure 5. This option allows me to specify controls for the search operation. Here, I also change the Attributes list to *. This causes LDP to display all of the normal attributes for each object it retrieves, instead of LDP's default set of attributes.

Figure 5 LDP Search Options dialog 

Now I press the Controls button to display the Controls dialog. LDP's Controls dialog is a little awkward, so when you do this, be sure you carefully follow these steps for adding the Return Deleted Objects control.

Open the Load Predefined dropdown list, select Return deleted objects, and press the Check in button. This adds the object identifier (OID) for the Return Deleted Objects control (1.2.840.113556.1.4.417) to the Active Controls list, as shown in Figure 6. LDP then adds the control to all subsequent extended search operations. Press OK to save the control settings and press OK again to close the Search Options dialog.

Figure 6 Adding the Return Deleted Objects control 

The Controls dialog has some peculiar behavior. Specifically, even though an OID appears in the Active Controls list, this doesn't necessarily mean that the control is actually in effect. Sometimes you have to check out a control and then check it back in to ensure that the control will be used in the next LDAP operation.

Now I'm ready to run my search. I press the OK button on the LDP Search dialog and LDP retrieves all the user objects from the CN=Deleted Objects container for the domain. Figure 7 shows my results.

Figure 7 Results from the CN=Deleted Objects container (Click the image for a larger view)

Examining the LDP Results

My search returned two tombstone objects. First, you can see the DN of the first tombstone: CN=John Smith\0ADEL:41800281-6bc4-42c3-a99b-b283022b3af8,CN=Deleted Objects,DC=foo,DC=local. The objectGUID of the deleted object is represented as a string (41800281-6bc4-42c3-a99b-b283022b3af8). Beneath the DN is a list of attributes showing the values for objectClass, cn, distinguishedName, and so on. You can see that the value of the isDeleted attribute is TRUE, meaning the object has in fact been deleted. You'll also see that the objectSid has been preserved in the tombstone—this is important for recovering user and group tombstones, as I'll discuss later. The lastKnownParent attribute, which represents the DN of the object that contained the deleted object before it became a tombstone, is also extremely important when recovering tombstones.

In my sample, LDP displayed two tombstone objects, both of which were user objects named CN=John Smith that originally came from the CN=Users,dc=foo,dc=local container. How can two separate objects with the same RDN come from the same container? The explanation is pretty simple. Before running LDP to search for tombstones, I created the CN=John Smith user object in the CN=Users,DC=foo,DC=local container and deleted it. Then I created another user object with all the same attributes and deleted that one as well. Because I had already deleted the first CN=John Smith user object, it was perfectly reasonable to create the second one, even though it had the same name. But these are separate, unique objects, distinguished by their objectGUIDs. Because Active Directory incorporates the objectGUID into the tombstone's DN, they appear as separate objects in the CN=Deleted Objects container.

How a Tombstone Is Reanimated

Active Directory provides a mechanism for restoring a tombstone back into a normal object. This is effectively an undelete function for deleted objects. The function is a specially formed LDAP modify operation that must include two specific attribute modifications: it must remove the isDeleted attribute (not just set it to FALSE) and it must move the object to another container by changing the object's distinguishedName. The new distinguishedName typically (but not necessarily) uses the lastKnownParent attribute as the container and keeps the same RDN minus the \0ADEL:<objectGUID> component that Active Directory added when it created the tombstone.

Before reanimating the tombstone, Active Directory checks to ensure certain necessary conditions are all true. The user must have the reanimate tombstone extended access right defined on the NC head of the NC containing the tombstone. The user cannot be reanimating his own object. The isDeleted attribute of the tombstone must be set to TRUE. And the owner Security Identifier (SID) of the object, as defined in the security descriptor, must have a SID from one of the domains in the forest or a trusted domain.

If the object in question is in the Configuration or Schema NCs, the FLAG_CONFIG_ALLOW_RENAME and FLAG_ CONFIG_ALLOW_MOVE bits must be set in the tombstone's systemFlags attribute. If the object is in the Configuration or Schema NCs and the FLAG_CONFIG_ALLOW_LIMITED_MOVE flag is set, the object is only able to be moved to a container that has the same grandparent—in other words, the object must retain its great-grandparent after the move. And if the object is in a domain NC or an application partition, then the FLAG_DOMAIN_DISALLOW_RENAME and FLAG_DOMAIN_DISALLOW_MOVE bits must not be set in the tombstone's systemFlags attribute.

The user must have the rights, as defined in the security descriptor, to modify the RDN (usually CN, but not always) and to add the object to the new parent container. And the new parent container must be a possible superior for the tombstone's objectClass, as defined by the schema.

Reanimating a schema object is never allowed. This, however, is not really an issue since you can't legitimately delete an object from the Schema NC.

If all of the checks are successful and the necessary requirements are met, Active Directory performs the following steps on the tombstone to reanimate the object:

• The isDeleted attribute is removed.
• If not otherwise prescribed in the modify operation, the objectCategory is set to the most specific objectClass indicated in the tombstone.
• The RDN is changed and the object is written to the new parent container.

After reanimation, the object has the same objectGUID and objectSid attributes it originally had. This means that external references to the object, for instance in ACLs, don't have to be reset as they do if you recreate a deleted object. The reanimated object looks and acts just as it did before it was deleted. There is one important difference, though: the restored object is missing any attributes that were not saved in the tombstone.

Using LDP to Reanimate Tombstones

systemFlags Attribute and Object Behavior

The systemFlags attribute is an optional attribute defined for the class top, which makes systemFlags an optional attribute for every Active Directory class. It is a 32-bit integer bit mask that controls the behavior of object moves and deletes. Here's a rundown of important flags.

FLAG_DISALLOW_DELETE (0x80000000)

If this flag is set, the system will not allow the object to be deleted or moved to another domain.

FLAG_CONFIG_ALLOW_RENAME (0x40000000)

Objects in the Configuration and Schema NCs cannot be renamed unless this flag is set in the systemFlags attribute.

FLAG_CONFIG_ALLOW_MOVE (0x20000000)

Objects in the Configuration and Schema NCs cannot be moved unless this flag is set in the systemFlags attribute.

FLAG_CONFIG_ALLOW_LIMITED_MOVE (0x10000000)

Objects in the Configuration and Schema NCs cannot be moved unless this flag is set in the systemFlags attribute. This flag imposes a further restriction on the target container of the move operation‑the target container must have the same grandparent as the current container.

FLAG_DOMAIN_DISALLOW_RENAME (0x08000000)

By default, objects in a domain NC or application NC can be renamed. However, if this flag is set in the systemFlags attribute of the object, the system will not allow the object to be renamed.

FLAG_DOMAIN_DISALLOW_MOVE (0x04000000)

By default, objects in a domain NC or application NC can be moved to another container. However, if this flag is set in the systemFlags attribute of the object, the system will not allow the object to be moved.

FLAG_DISALLOW_MOVE_ON_DELETE (0x02000000)

If this flag is set, the system will not move the object to the CN=Deleted Objects container of its naming context. It will simply set the isDeleted attribute, rename the object, and strip the attributes not designated in the schema to be saved. This means that not all deleted objects appear in the CN=Deleted Objects container for the naming context; some remain in the original parent container.

Now that I've shown you how the nuts and bolts of tombstone reanimation work, I want to demonstrate how I can use LDP to restore the CN=John Smith user I deleted. First I connect to a DC and authenticate. Now I can perform a modify operation using LDP. In the modify operation parameters, I can remove the isDeleted attribute and specify a new DN at the same time.

Because I am operating on a tombstone, I have to specify the Return Deleted Objects LDAP control. To set this control for the modify operation in LDP, select Controls from the options menu, select Return deleted objects from the Load Predefined dropdown list, press the Check in button, and press OK to save the control settings.

Now I select Modify from the Browse menu to open the Modify dialog and enter the DN of the tombstone object I want to restore. The easiest way to do this is to copy and paste the DN from the results of the search operation I performed earlier.

Next, I have to enter a list of attribute operations to perform. Reanimating a tombstone requires two attribute operations—delete the isDeleted attribute and replace the distinguishedName attribute with the desired DN of the reanimated tombstone. So I type isDeleted into the Attribute field and select the Delete radio button. When I press the Enter button, the attribute operation is added to the Entry List, as shown in Figure 8.

Figure 8 Specifying attribute operations to be performed 

Then I enter distinguishedName into the Attribute field, select the Replace radio button, and enter the new DN of the object in the Values field. In this case, I use the original distuiguishedName of the user, CN=John Smith,CN=Users,DC=foo,DC=local. When I press the Enter button, the modify operation is added to the Entry List.

Because I have to include the Return Deleted objects LDAP control with the modify operation, I have to use an extended LDAP modify. To do this, I check the Extended checkbox. Once everything is set, as shown in Figure 9, I press the Run button to make the changes. LDP displays the results in a large text window.

Figure 9 Change the distinguishedName 

When I go back to the Active Directory Users and Computers MMC snap-in and look in the CN=Users container, I'll find the once-deleted user object back where it came from. But the object will have some important differences from its original state, which I'll look at in a moment.

Using ADRESTORE to Reanimate Tombstones

Once you figure out how to use LDP, reanimating a tombstone is not terribly difficult. But it's not very convenient, either. Fortunately, the good folks at Sysinternals (a company that is now part of Microsoft) developed a command-line tool to simplify the reanimation process. This tool, called ADRESTORE, is available from the Microsoft Web site at microsoft.com/technet/ sysinternals/utilities/AdRestore.mspx. Installation is simple. Just copy the executable to an appropriate directory on your machine, for instance the C:\WINDOWS\SYSTEM32 directory.

ADRESTORE runs in two modes. If you run it with no parameters, it will list all the tombstones in the CN=Deleted Objects container of the default domain. You can add a search string to the command line to select the objects to display, for instance:

C:\> adrestore John

This will display all the tombstone objects in the CN=Deleted Objects container that contain the string "John" in their CN or OU attribute—it uses the LDAP search filters cn=*John* and ou=*John*. This isn't exactly the most flexible way to search tombstone objects, but it is workable for most situations. Figure 10 shows the output my search returned in ADRESTORE.

Figure 10 Attributes saved in a tombstone (Click the image for a larger view)

If you want to reanimate a tombstone, not just find it, then you need to specify the –r switch, along with an optional string, such as the following:

C:\> adrestore –r John

This command will prompt you to reanimate each matching tombstone object. ADRESTORE always reanimates the object into the container given by the tombstone's lastKnownParent attribute—there is no way to specify a different container.

ADRESTORE provides a convenient command-line interface for using the Active Directory reanimation functionality. Though not very flexible, it is quite a bit easier to use than LDP. Still, ADRESTORE doesn't avoid two significant problems with reanimating tombstones: recovering the attributes stripped from the object when it was first deleted, and recovering objects deleted from the Configuration NC.

Recovering Object Attributes

In terms of data recovery, tombstone reanimation has a great advantage over performing an authoritative restore: tombstone reanimation doesn't require the DC to be taken offline. And reanimating tombstones is much better than simply recreating a new version of a deleted object. If you recreate an object, it will always get new objectGUID and objectSid (if it's a security principal such as a user) attributes. As a result, any external references to the object, such as ACLs, will have to be updated to reflect the new object's identity. This can be a major headache.

Some attributes are stripped when an object is deleted, and these attributes aren't recovered with tombstone reanimation. But Active Directory saves some key attributes in the tombstone, the most important of which are identity-related attributes such as objectGUID and objectSid. It saves many other attributes by default as well (see Figure 1). Most of the attributes that are hardcoded to be saved aren't very interesting, particularly in a discussion about recovering deleted user objects. But you can specify additional attributes to be saved in the tombstone by setting bit 3 (0x00000008) of the searchFlags attribute of the corresponding attributeSchema object in the Active Directory schema. Some attributes already have this bit set in the schema in Windows Server 2003 R2 (these are also shown in Figure 1).

Installing certain applications may change bit 3 of the searchFlags of existing attributes or even add new attributes that have bit 3 set. Exchange Server, for example, configures several additional attributes to be saved in the tombstone.

Active Directory will not save forward-linked or backward-linked attributes in the tombstone, even if you specify to do so in the searchFlags attribute of the schema object. In particular, Active Directory doesn't save things such as the member attribute of a group or the memberOf attribute of a user. Thus tombstone reanimation doesn't provide a solution for recovering group memberships in Active Directory for this, see my "Disaster Recovery: Active Directory Users and Groups" article attechnetmagazine.com/issues/2007/04/ADRecovery. So you will still have to provide an alternate mechanism for recovering this information when reanimating tombstones.

If you want to use tombstone reanimation as part of your data recovery strategy, either you'll need to make sure that the important attributes are saved in the tombstone or you'll need to provide another way to save and recover important attributes, such as using LDIFDE or another backup and restore scheme. Other options include third-party Active Directory data recovery products that provide an automated mechanism for backing up and restoring attributes that aren't saved in and recovered from the tombstone.

Reanimating Objects from the Configuration Naming Context

One other substantial limitation that tombstone reanimation suffers is that, generally speaking, you cannot reanimate objects that were deleted from the Configuration NC. Those objects are subject to special rules with respect to moving and renaming, as defined by the object's systemFlags attribute. Unless otherwise specified by the systemFlags attribute, objects in the Configuration NC cannot be moved or renamed, which means their tombstones cannot be reanimated. Active Directory enforces certain values for the systemFlags attribute when it creates objects of specific classes, as defined inFigure 11. Note that Active Directory applies the bit-wise logical OR operation to these values in combination with any systemFlags value specified in the add operation. This way even if the application specifies a different value for the systemFlags attribute, the necessary bits will be properly set.

  Figure 11 Default systemFlags settings

Class	Default Setting
server	FLAG_DISALLOW_MOVE_ON_DELETE FLAG_CONFIG_ALLOW_RENAME FLAG_CONFIG_ALLOW_LIMITED_MOVE
site	FLAG_DISALLOW_MOVE_ON_DELETE
serversContainer	FLAG_DISALLOW_MOVE_ON_DELETE
nTDSDSA	FLAG_DISALLOW_MOVE_ON_DELETE
siteLink	FLAG_CONFIG_ALLOW_RENAME
siteLinkBridge	FLAG_CONFIG_ALLOW_RENAME
nTDSConnection	FLAG_CONFIG_ALLOW_RENAME

The only objects from the Configuration NC that you can reanimate under normal circumstances are server objects. Interestingly, when Active Directory deletes a server object, the tombstone is not moved to the CN=Deleted Objects container for the Configuration NC; the tombstone simply remains where the object is. This allows the Knowledge Consistency Checker (KCC), which is the process responsible for calculating the Active Directory replication topology, to automatically recover from certain scenarios where deleted server objects might inhibit proper replication. So if you find yourself trying to reanimate a server object, remember that you won't find it in the CN=Deleted Objects container.

Reanimation in Your Recovery Plan

Tombstone reanimation should be a key part of your data recovery toolkit. This mechanism is the only way to recover deleted objects without taking a DC offline and, equally important, it's the only way to recover a deleted object's identity information. This neatly solves the problem of recreating a deleted user or group and having to fix up all the old ACL references.

But tombstone reanimation is an incomplete solution. You have to provide your own mechanism for recovering the attributes that Active Directory doesn't retain in tombstone objects, and your ability to recover deleted objects from the Configuration NC is limited. Remember that if you do elect to reanimate a deleted user or group, you will still have to recover the group memberships and any other linked attributes of which you might be in need.

Exchange 2010 Interview Questions and Answers

 What is Storage Group?

Storage Group is a grouping of Mailbox and/or Public Folder Databases, which shares a single backup schedule and a single set of Transaction log files. Storage Groups are managed using their separate server process and the idea behind splitting databases up in Storage Groups is primarily to reduce the overhead that results from multiple sets of transaction log files.

What are the storage group and database size limitations in Exchange 2007, compared with Exchange 2003?

Exchange Server 2003 Standard edition supported 1 Storage Group and 2 Stores – one Mailbox and one Public Folder Store (when excluding the Recovery Storage Group of course). Exchange Server 2003 Enterprise Edition supported a total of 4 Storage Groups each containing a maximum of 5 store databases per Storage Groups (thus maximum 20 databases per server). The limit of a database size in Exchange Server 2003 Standard edition was 16 GB (although raised to 75 GB when Exchange 2003 Service Pack 2 was applied). There was no limit on a database size when talking about Exchange Server 2003 Enterprise edition (well actually there is a 16 Terabyte limit but this limit is caused by hardware).

Exchange Server 2007 comes in two flavours, a standard edition and an enterprise edition, just like previous versions of Exchange. The Mailbox Server when talking about the Exchange Server 2007 Standard edition supports a total of 5 Storage Groups and 5 databases. Unlike Exchange 2003 and previous versions of Exchange there’s no longer a database storage limit in the standard edition. The Mailbox server in the Exchange 2007 Enterprise edition supports up to 50 Storage groups and a maximum of 50 databases per server. Exchange 2007 allows you to create up to 5 databases in each Storage Group as is the case with Exchange 2003, but best practice is to create 1 database per Storage Group. So why should you have a one to one relationship between storage groups and databases? Well primarily because you’ll be up and running a lot faster considering disaster recovery scenarios, etc.

No Storage Groups In Exchange 2010… Exchange 2010 has only mailbox databases and they are organizational objects in EMC. Mailbox databases no longer connected to the server object they become *Peers*. Database management has also been moved from Server configuration node in exchange console EMC. The mailbox databases are placed in the Organization Configuration ->Mailbox location in the console rather than the server level in exchange 2007. The database names has to be unique through out the exchange organization as well. This means that we can’t have duplicate mailbox database names like in 2007 (in different storage groups, of course).

As there are no storage groups, this will also mean that the database will have its own logs as well…

One of the goals of ESE in Exchange 2010 is to reduce the cost of maintaining and managing a database. Database maintenance is comprised of several tasks that manage and keep the integrity of your mailbox database.

Database maintenance is divided into the following:

Store mailbox maintenance

ESE database maintenance

In Exchange 2007, ESE database maintenance was disk-intensive. In Exchange 2010, improvements have been made to increase performance. In Exchange 2010, on large or very heavy profile servers, the store mailbox maintenance task only lasts approximately 45 minutes, while ESE database maintenance usually took from six to eight hours per

night to complete on large Exchange 2007 databases (2 GB quotas). In Exchange 2010, improvements have been made to support both large mailboxes as well as to support JBOD storage and storage without the use of RAID.

Microsoft Exchange Server 2010 includes many improvements to the Exchange database architecture:

 Public folder reporting has been enhanced.

 Databases are no longer associated with storage groups. Storage groups have been removed.

 Investments in store schema and Extensible Storage Engine (ESE) optimizations have reduced IOPS by 70 percent.

Describe the differences in the permission model between Exchange 2003 and Exchange 2010.

Exchange 2003 Security and Permissions Model

To help simplify management of permissions, Exchange Server 2003 provided predefined security roles that were available in the Exchange 2003 Administrative Delegation Wizard. These roles were a collection of standardized permissions that could be applied at either the organization or the administrative group level.

In Exchange 2003, the following security roles were available through the Delegation Wizard in Exchange System Manager:

Exchange Full Administrator

Exchange Administrator

Exchange View Only Administrator

This model had the following limitations:

A lack of specificity. The Exchange Administrator group was too large, and some customers wanted to manage their security and permissions model at the individual server-level.

A perception that the Exchange Server 2003 security roles only differed in subtle ways.

There was no clear separation between administration of users and groups by the Windows (Active Directory) administrators and Exchange recipient administrators. For example, to perform Exchange recipient related tasks, you had to grant Exchange administrators high level permissions (Account Operator permissions on Windows domains).

Exchange 2007 Security and Permissions Model

To improve the management of your Exchange administrator roles, which were called "security groups" in Exchange 2003, the following new or improved features have been made to the Exchange security and permissions model:

New administrator roles that is similar to the built-in Windows Server security groups.

You can use the Exchange Management Console (formerly Exchange System Manager) and the Exchange Management Shell to view, add, and remove members from any administrator role.

What's New in Exchange Server 2007 SP1?

You can install Exchange 2007 SP1 on a computer that is running the Windows Server 2008 operating system

Improvement in Microsoft Outlook Web Access (OWA)

Recover Deleted Items

Local Distribution List

S/MIME feature

Public Folder

Rules

Monthly view

New themes

What's New in Exchange Server 2007 SP2?

You can deploy Exchange Server 2010 in your organization once all of the Client Access servers in your organization have been upgraded to Exchange Server 2007 Service Pack 2 (SP2).

Exchange 2007 Service Pack 2 includes a VSS plug-in for Windows Server Backup to support Exchange backups. Once SP2 is installed, you can use Windows Server Backup to back up and restore your Exchange 2007 SP2 databases.

New Exchange auditing events and audit log repository enable Exchange administrators to more easily audit the activities occurring on their Exchange servers.

What's New in Exchange Server 2007 SP3?

Windows Server 2008 R2 Support

Exchange Server 2007 SP3 supports all Exchange 2007 roles on the Windows Server 2008 R2 operating system.

Windows 7 Support

Exchange 2007 SP3 supports the installation of the Exchange 2007 management tools on a computer that is running Windows 7. Additionally, Exchange 2007 SP3 provides support for the installation of the Exchange 2007 Management Tools together with the Exchange Server 2010 Management Tools on the same Windows 7-based computer.

Improved Password Reset Functionality

Exchange 2007 SP3 introduces password reset functionality for Internet Information Services (IIS) 7.

Updated Search Functionality

Exchange 2007 SP3 includes updates to the Exchange Search (MS-Search) component.

Support for Right-to-Left Disclaimer Text

Exchange 2007 SP3 includes support for Right-to-Left text in e-mail message disclaimers in a right-to-left language, such as Arabic.

What are the major changes in the way Exchange 2010 stores work? Name some of the changes in comparison with Exchange 2003 and Exchange 2007.

The following is a list of core store functionality that's included or has been changed in Exchange 2010:

 Deprecated storage groups

 Mailbox databases no longer connected to the server object

 Improvements in Extensible Storage Engine (ESE) for high availability, performance, and database mobility

 Flattened Outlook store schema

 Enhanced reporting with public folders

In Exchange 2010, the store schema has been changed to remove the dependency of mailbox databases on the server object. In addition, the new schema has been improved to help reduce database I/O per second (IOPS) by refactoring the tables used to store information. Refactoring the tables allows higher logical contiguity and locality of reference. These changes reduce the store's reliance on the secondary indexes maintained by ESE. As a result, the store is no longer sensitive to performance issues related to the secondary indexes.

Store resilience and health has also been improved by adding several features related to detecting and correcting errors and providing alerts, such as the following:

 Mailbox quarantine on rogue mailboxes

 Transport cut-off to databases with less than 1 GB of space

 Thread time-out detection and reporting

Name the system prerequisites for installing Exchange 2007 in your existing Active Directory forest.

Windows Server 2003/R2 x64 SP2

Windows Server 2008 x64

Microsoft .NET Framework Version 3.0/Microsoft .NET Framework Version 2.0 (with update/SP1)

Microsoft Windows PowerShell

Microsoft Management Console (MMC) 3.0

Network News Transfer Protocol (NNTP) service must not be installed.

Simple Mail Transfer Protocol (SMTP) service must not be installed.

IIS (for OWA)

Name the system prerequisites for installing Exchange 2010?

1- General Prerequisites:

Make sure that the functional level of your forest is at least Windows Server 2003, and that the Schema Master is running Windows Server 2003 with Service Pack 2 or later.

The full installation option of Windows Server 2008 SP2-64bit or Windows Server 2008 R2-64bit must be used for all servers running Exchange 2010 server roles.

Both Windows Server 2008 SP2-64bit or Windows Server 2008 R2-64bit Standard & Enterprise are supported and we can use them to install Exchange 2010.

DNS must configure correctly in your Active Directory forest. All servers that run Exchange Server 2010 must be able to locate Active Directory domain controllers, global catalog servers, and other Exchange servers.

For all server roles other than the Edge Transport server role, you must first join the computer to the appropriate internal Active Directory forest and domain.

2- Operating System Components Prerequisites:

Microsoft .NET Framework 3.5 Service Pack 1 (SP1)

Windows Remote Management (WinRM) 2.0

Windows PowerShell V2

IIS 7

ASP.NET

In addition to the above, we need to install the following windows components (features):

RSAT-ADDS (requires a reboot)

Web-Server

Web-ISAPI-Ext

Web-Metabase

Web-Lgcy-Mgmt-Console

Web-Basic-Auth

Web-Digest-Auth

Web-Windows-Auth

Web-Dyn-Compression

Net-HTTP-Activation

RPC-over-HTTP-Proxy

3- Software Prerequisites:

For Hub Transport or Mailbox server role, Microsoft Filter Pack is required to be installed. You can download the Microsoft Filter Pack from the Microsoft website.

How would you easily install all the Windows Server 2008 R2 roles and features required for Exchange 2010?

Exchange Server 2010 Service Pack 1 allows us to install all Operating System prerequisites using just the Exchange Setup wizard. When we use the Exchange Server 2010 SP1 Setup wizard, there is a new option called Automatically install Windows Server roles and features required for Exchange Server. Just by clicking on that option will be installed all prerequisites automatically.

Installing Exchange Server 2010 Pre-Requisites on Windows Server 2008

First, install the following software components.

1. .NET Framework 3.5 Service Pack 1

2. .NET Framework 3.5 Family Update

3. Windows Remote Management and Windows PowerShell 2.0

4. 2007 Office System Converter: Microsoft Filter Pack (for Hub Transport and Mailbox Server roles only)

Run the following from an elevated command prompt.

C:\>sc config NetTcpPortSharing start= auto

Next we need to install the operating system components. The Exchange source files contain a series of ServerManagerCmd.exe answer files in XML format that can be used to install the operating system pre-requisites for each of the server roles.

Each file relates to a specific Exchange 2010 deployment scenario.

exchange-all.xml – all server roles

exchange-base.xml – only the requirements for Forest and Domain prep operations

exchange-cadb.xml – Central Admin Database role

exchange-cas.xml – Client Access Server role

exchange-eca.xml – Central Admin role

exchange-edge.xml – Edge Transport Server role

exchange-hub.xml – Hub Transport Server role

exchange-mbx.xml – Mailbox Server role

exchange-typical.xml – Typical Exchange server (Client Access, Hub Transport, and Mailbox Server roles)

exchange-um.xml – Unified Messaging role

Execute any of the answer files using ServerManagerCmd.exe and the -inputPath parameter (that can be shortened to -ip). Here I am installing the pre-requisites for a “Typical” Exchange 2010 server.

servermanagercmd -ip exchange-typical.xml –restart

-restart option used to restart server automatically

How would you check your Exchange configuration settings to see if they’re right?

Run Microsoft Exchange Best Practices Analyzer tool.

Looking to install Exchange 2007 on Windows Server 2008. What SP version do you need? And for R2?

Exchange Server 2007 SP1 required for installation on Windows Server 2008 and Exchange Server 2007 SP3 required for Windows Server 2008 R2.

What’s a Rollup Update? What’s the latest RU for Exchange 2007 – 2010?

An update rollup is a tested, cumulative set of hotfixes, security updates, critical updates, and updates that are packaged together for easy deployment. A rollup generally targets a specific area, such as security, or a component of a product.

At the time of this writing, Update Rollup 4 for Exchange Server 2007 Service Pack 2 and Update Rollup 10 for Exchange Server 2007 Service Pack 1 are available.

How can you easily integrate a RU in the Exchange 2007 – 2010 installation media?

The Exchange installation folder includes an Updates folder. When you perform a new Exchange installation, you can copy an update rollup to the Updates folder. In this scenario, the update rollup package is applied during the installation of Exchange. The Updates folder supports only new installation of Exchange server.

Name a few reasons for using 64-bit hardware and OS version for Exchange 2007 – 2010.

64-bit hardware provides the system architecture that is required to support the increased memory, storage, and enhanced security requirements in a more cost-effective manner. Trends indicate that demands on messaging systems will continue to grow and 64-bit servers provide the system architecture to meet these demands while reducing costs within organizations through server and disk storage consolidations. With a larger addressable space, the Exchange servers can utilize more memory thereby reducing the required input/output per user (IOPS), enabling the use of larger disks as well as low cost storage such as SATA2 drives.

Exchange 2007 came in both 32-bit and 64-bit versions. Name a couple of reasons for ever needing the 32-bit version.

You need exchange 2007 32bit to export mail box into PST file.

Wanting to manage Exchange 2007 – 2010 from a remote computer, name a few of your management options.

There are a few options for managing Exchange 2007 servers remotely. First off, you can install the Exchange 2007 management tools onto a separate machine from your Exchange server, as long as that machine is running either the 32-bit or 64-bit version of Windows Server 2003 Service Pack 1 (SP1) or later, Windows Server 2003 R2, or Windows XP SP2 or later. Note that installing any of the server roles (client access, mailbox, edge, and so on) on 32-bit hardware is not supported in production environments, but is supported for installing the management tools on a

32-bit machine. Also note that as of the initial release of Exchange Server 2007, the management tools are not supported on Windows Vista.

In some organizations, the IT department creates a single server to be the management server, installing all the necessary management tools for various products on this server. Then the administrators who need to use those tools access the management server via Terminal Server so they can perform remote administration. In other settings, users install the management tools on their own desktops.

From the console or shell you can perform operations on the servers in your organization. In the console, the servers are visible so you can perform operations on any of them remotely. In the shell, many of the tasks support a filtering flag like -server if you want to scope an operation to a single server. There are a few exceptions, however, for commands that must be run locally, such as the Get-NetworkConnectionInfo command.

What is the GAL?

The Global Address List (GAL) also known as Microsoft Exchange Global Address Book is a directory service within the Microsoft Exchange email system. The GAL contains information for all email users, distribution groups, and Exchange resources.

What is the OAB? When is it used?

An Offline Address Book is a container that stores a collection of Offline Address Lists. Outlook users can choose which offline address lists they want to download. Users who work offline connect to Exchange Server computers and download Offline Address Lists to obtain information about other users in their organization.

When an Administrator creates an Offline Address Book, the address list will be converted to a separate set of files and stored in an Exchange Public Folder. Offline Address Books typically contain at least one address list that represents the global address list (GAL). Users who are working offline with their Outlook clients can use this global address while they are on the road.

What is PowerShell and why do we care?

Windows PowerShell is a task-based command-line shell and scripting language designed especially for system administration. Built on the .NET Framework, Windows PowerShell helps IT professionals and power users control and automate the administration of the Windows operating system and applications that run on Windows. Built-in Windows PowerShell commands, called cmdlets, let you manage the computers in your enterprise from the command line.

The Exchange Management Shell, built on Windows PowerShell technology, provides a powerful command-line interface for Microsoft Exchange Server 2010 that enables automation of administrative tasks. With the Shell, you can manage every aspect of Exchange. You can enable new e-mail accounts, configure SMTP connectors, store database properties, store transport agents, and more. The Shell can perform every task that can be performed by the Exchange Management Console and the Exchange Web interface in addition to tasks that can't be performed in those interfaces. In fact, when a task is performed in the console and the Web interface, those interfaces use the Shell to perform the task.

Name major benefits of PowerShell v2 over V1

PowerShell Remoting : Using WS-Management, PowerShell 2.0 allows scripts and cmdlets to be invoked on a remote machine or a large set of remote machines.

Background Jobs : Also called a PSJob, it allows a command sequence (script) or pipeline to be invoked asynchronously. Jobs can be run on the local machine or on multiple remote machines. A PSJob cannot include interactive cmdlets.

Transactions : Enable cmdlet and provider developers to perform transactional operations. PowerShell 2.0 includes transaction cmdlets for starting, committing, and rolling back a PSTransaction as well as features to manage and direct the transaction to the participating cmdlet and provider operations. The PowerShell Registry provider supports transactions.

ScriptCmdlets: These are cmdlets written using the PowerShell scripting language. NOTE: The preferred name for script cmdlets is now Advanced Functions.

SteppablePipelines: This allows the user to control when the BeginProcessing(), ProcessRecord() and EndProcessing() functions of a cmdlet are called.

Modules : This allows script developers and administrators to organize and partition PowerShell scripts in self-contained, reusable units. Code from a module executes in its own self-contained context and does not affect the state outside of the module. Modules can define a restricted runspace environment by using a script. They have a persistent state as well as public and private members.

Data Language : A domain-specific subset of the PowerShell scripting language, that allows data definitions to be decoupled from the scripts and allow localized string resources to be imported into the script at runtime (Script Internationalization).

Script Debugging : It allows breakpoints to be set in a PowerShell script or function. Breakpoints can be set on lines, line & columns, commands and read or write access of variables. It includes a set of cmdlets to control the breakpoints via script.

Eventing: This feature allows listening, forwarding, and acting on management and system events. Eventing allows PowerShell hosts to be notified about state changes to their managed entities. It also enables PowerShell scripts to subscribe to ObjectEvents, PSEvents, and WmiEvents and process them synchronously and asynchronously.

Windows PowerShell Integrated Scripting Environment (ISE) : PowerShell 2.0 includes a GUI-based PowerShell host (formerly known as Graphical Windows PowerShell) that provides integrated debugger, syntax highlighting, tab completion and up to 8 PowerShell Unicode-enabled consoles (Runspaces) in a tabbed UI, as well as the ability to run only the selected parts in a script.

Network File Transfer : Native support for prioritized, throttled, and asynchronous transfer of files between machines using the Background Intelligent Transfer Service (BITS).

New Cmdlets : Including Out-GridView, which displays tabular data in the WPF GridView object.

New Operators : -Split, -Join, and Splatting (@) operators.

Exception Handling with Try-Catch-Finally : Unlike other .NET languages, this allows multiple exception types for a single catch block.

Nestable Here-Strings : PowerShell Here-Strings have been improved and can now nest.

Block Comments : PowerShell 2.0 supports block comments using <# and #> as delimiters.

New APIs : The new APIs range from handing more control over the PowerShell parser and runtime to the host, to creating and managing collection of Runspaces (RunspacePools) as well as the ability to create Restricted Runspaces which only allow a configured subset of PowerShell to be invoked. The new APIs also support participation in a Windows PowerShell managed transaction.

In the installation folder root you see setup.com and setup.exe. Which would you use and when?

Setup.com is used for all preparation work; basically it calls different backend procedures. Setup.com is also used in disaster recovery to reinstall all ex2k7 roles. Setup.exe is used for GIU installation.

What are the Exchange 2007/2010 server roles?

Exchange 2007 introduces a new concept to Exchange organizations, the concept of server roles. Similar to how a Windows server can host one or more roles. Server roles allow an administrator to split the functions of an Exchange

server and place each role, or a combination of roles, on different servers in the organization. With current Exchange servers you can make a server a Front-End server, or a Back-End server and that is about it. Exchange 2007 introduces five roles to the Exchange organization.

Edge Transport - The last hop of outgoing mail and first hop of incoming mail, acting as a "smart host" and usually deployed in a perimeter network, Edge Transport provides mail quarantine and SMTP service to enhance security. One advantage of this role is that is does not require Active Directory access, so it can function with limited access to the corporate network for increased security.

Hub Transport - The Hub Transport role handles mails by routing them to next hop: another Hub Transport server, Edge server or mailbox server. Unlike Exchange 2003 Bridgehead that needs Exchange admin defined routing groups, Exchange 2007 Hub Transport role uses AD site info to determine the mail flow. The Hub Transport and Edge Transport servers are very similar and in fact, one can forgo the Edge Transport server and configure the Hub Transport to accept mail from, and send mail to, the Internet.

Client Access - The Client Access server role provides the other mailbox server protocol access apart from MAPI. Similar to Exchange 2003 FrontEnd server, it enables user to use an Internet browser (OWA), 3rd party mail client (POP3/IMAP4) and mobile device (ActiveSync) to access their mailbox.

Mailbox - The Mailbox server role is responsible for hosting mailbox and public folder data. This role also provides MAPI access for Outlook clients. Note that there is also a variation of this role called Clustered Mailbox role, for use with high-availability MSCS clustering of mailbox data. When Clustered Mailbox role is selected, other server roles cannot be combined on the same physical server.

Unified Messaging - This role enables end users to access their mailbox, address book, and calendar using telephone and voice. IP-PBX or VoIP gateway needs to be installed and configured to facilitate much of the functionality of this server role.

What are the benefits of using roles, vs. the way Exchange 2000/2003 worked?

Server role is a logical concept used to organize Exchange 2007 services and features across one or more servers. While Exchange 2003 provided primitive server roles called BackEnd server and FrontEnd server, Exchange 2007 has more granular divisions.

Dividing Exchange features among several server roles has advantages:

More flexible deployment topology: For a small or medium company that has only hundreds of mailboxes and all users are centralized, customer can install all required roles on one physical server. For a large enterprise where tens of thousands of mailboxes span multiple physical locations, customer can choose to deploy each role on a separate server or even multiple servers per role to provide better performance and fault tolerance.

Better hardware utilization and scalability: Because each role only installs binaries and runs services for a specific feature set. Unlike older versions of Exchange, configuring a server that has only one or two roles will reduce Memory, CPU and disk space requirements for this server. In addition, roles are scalable so admin can load balance work of one role to multiple servers.

Easy to maintain: Upgrading, applying hotfix, or other server changes that could cause server outage can be isolated to one server role. This reduces maintenance down time and end user impact. Admin can also install or uninstall roles on a server as needed.

What are the Exchange 2003 equivalents of the various Exchange 2007-2010 roles?

Exchange 2007 Exchange 2003

Edge Transport

Hub Transport Bridgehead server

Client Access Front-End server

Mailbox Back End server

Unified Messaging

The main differences between Exchange 2007 and Exchange 2010. Feature	Exchange 2007	Exchange 2010
Database	Jet EDB database	Jet EDB database
Storage Groups	Yes	None, only data stores
Public Folders	Automatically created	Manual creation
Web Services	ExOLEDB, CDOEX, WebDAV, EWS	Exchange Web Services (EWS)
Desktop Clients	Outlook 2003, Outlook 2007, Outlook 2010	Outlook 2007, Outlook 2010
DR Technologies	SCC, CCR, SCR	Database Availability Group (DAG)
Outlook clients connect to	Mailbox Server	Client Access Server