Managing Compliance in Microsoft Exchange Server 2010

The very valuable dumpster

Two dumpsters operate in Exchange. The transport dumpster functions on hub transport servers and acts as a repository for in-transit messages that might have to be replayed after a server outage, so although it functions on an ongoing basis, an administrator shouldn’t have to rely on the transport dumpster too often. The Store dumpster is much more useful on a day-to-day basis because it works for every mailbox and saves administrators from the need to restore mailbox databases to recover items that users have deleted in error. Of course, not every user can justify the expense of going through a full database recovery—and even the most important users probably can’t justify the expense for every item that they delete in error—but mailbox restores for item recovery were quite a common practice before the dumpster first appeared in Exchange 2000. The elimination of these restore operations is of huge value to administrators, and that’s why the dumpster is one of the high-value, low-cost features in Exchange.

Dumpster basics

Before we consider the changes that have occurred in Exchange 2010, we should review some dumpster basics. By default, the dumpster holds an item for a retention period after a user deletes it from a folder. The default retention period is 7 days in Exchange 2003 and 14 days in Exchange 2007 and Exchange 2010. Items in the dumpster are “soft deleted” in that users have deleted them from their original folder and emptied the Deleted Items folder. The items still remain in the database. In previous versions of Exchange, soft deleted items are kept in the Deleted Items folder but are hidden from the user’s view. In Exchange 2010, when users empty their Deleted Items folder, Exchange moves the items into a new subfolder under Recoverable Items called Deletions. The items in this folder are what Outlook and Outlook Web App show when a user selects the Recover Deleted Items option. Non-MAPI clients that use protocols such as Post Office Protocol 3 (POP3) and Internet Message Access Protocol 4 (IMAP4) do not include the user interface or the basic support in the protocols to enable recovery from the dumpster, and that’s why you don’t find the feature in these clients.

When you select the Recover Deleted Items option, Outlook displays a list of all of the items in the dumpster. For example, Figure 15-22 shows a list of deleted items from my mailbox as displayed through Outlook Web App. (Outlook Web App is a little more functional than Outlook because it allows you greater flexibility about where to recover items, including the ability to create a new folder for the purpose.) The list includes items deleted from all folders, including those that have transited through the Deleted Items folder and those placed directly into the dumpster by being hard deleted with the Shift+Delete key combination.

Figure 15-22 Recovering deleted items from the dumpster.

Recoverable items expire when the dumpster’s retention period passes, at which time the items will be hard deleted or permanently removed from the database. Items can also be hard deleted immediately as the PermanentlyDeleted action required by a retention tag. In this case, the MFA is responsible for removing the items stamped with the tag from the database and these items are deleted the next time that the MFA runs after the item’s retention period expires. Deleted items that are still recoverable don’t count against the user’s normal mailbox quota, so an extended retention period won’t make any difference to users, except that they can recover items at any time up until the retention period passes.

By default, Outlook 2003 only supports recovery of items that were originally removed from the Deleted Items folder, whereas Outlook 2007 allows recovery of items from any folder, including those that have been hard deleted. You can force Outlook 2003 to support recovery of deleted items from any folder by inserting a new DWORD value set to 1 in the following location:

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Client\Options\DumpsterAlwaysOn

Dumpster 2.0 arrives

From a user perspective, the experience of working with the Exchange 2010 dumpster is similar to previous versions. Behind the scenes, the introduction of new features to meet legal and regulatory requirements has had a massive influence on the dumpster. If users are under litigation hold, it’s obvious that they shouldn’t be able to affect the content in the dumpster, as deleted items could form part of the legal record. This requirement prompted Microsoft to look at how the dumpster works and led to the design of an enhanced dumpster (“dumpster 2.0”) for Exchange 2010. Among the major changes are the following:

• Items in the dumpster are included when you move a mailbox from one database to another rather than being purged as in previous versions of Exchange. This prevents the loss of any item that should be retained as a consequence of normal rebalancing of server load.

• Items in the dumpster are indexed so that they can be discovered by searches.

• The Store maintains a quota for the dumpster.

• Versions are maintained of changes made to items in the mailbox.

• Users cannot purge data by using the Recover Deleted Items option to view the contents of the dumpster, selecting one or more items, and then deleting them (with the “X” option shown previously in Figure 15-22).

• The dumpster is maintained on a per-mailbox rather than a per-folder basis.

The Exchange 2007 version of the dumpster is based on a hidden view maintained on a per-folder basis. As items are deleted, the Store sets a MAPI flag (ptagDeletedOnFlag) and starts the retention time countdown. The deleted items stay in the folder but are hidden from clients. They cannot be indexed or searched because Outlook and other clients don’t see these items. This mechanism works, but it can’t accommodate the requirements for indexing to allow discovery searches. The new dumpster is implemented as a hidden folder called Recoverable Items located in the non-IPM subtree of user mailboxes. No client interface ever exposes this subtree, so the folder remains invisible to users. The Recoverable Items folder contains three subfolders called Deletions, Versions, and Purges used to hold items at different points in their journey toward eventual removal from the Store. Using folders instead of views enables indexing and searching and also makes sure that dumpster data are moved along with the rest of the mailbox.

The Deletions folder replaces the MAPI flag and hidden view. When a user deletes an item as normal (soft delete) by emptying the Deleted Items folder, the Store moves the item into the Recoverable Items\Deletions folder. The Recover Deleted Items option accesses this folder, even when accessed by older Outlook clients, as the RPC Client Access Layer interprets client requests that were previously satisfied using the hidden view through items retrieved from the Deletions folder. If the user has a personal archive, a separate set of dumpster folders is maintained in the archive to handle the deletions that occur for archived items.

The Dumpster does not preserve the folder context for deleted items. In other words, you don’t see the folder from which an item was deleted when you view the contents of the dumpster. This isn’t usually an issue unless you have a very large number of items in the dumpster and therefore have to peruse a long list to find the right item to recover or a user deletes a complete large folder by accident and is faced with the need to find and recover all of the items from the deleted folder from among the mass of other items in the dumpster.

Some observers have commented that this situation happens often enough to keep them busy restoring deleted folders from backup copies, in turn meaning that the thought of ever going to a “no backup” regime for Exchange is impossible until the dumpster captures folder information, too. For now, the default sort order used in the dumpster is the date and time when an item is hard deleted (removed from the Deleted Items folder). Sometimes it is easier to find items if you click the appropriate column heading to sort by message subject or author. Microsoft is considering how best to improve matters in future versions of Exchange, perhaps by supporting the preservation of the folder structure for deleted items, which potentially would allow you to find items based on the folder from which they were originally soft deleted.

If you enable auditing for a mailbox (see the section “Auditing mailbox access” later in this chapter), Exchange stores the audit data in the Audit subfolder of the Recoverable Items folder in the dumpster. Audit entries age out after 90 days by default, so this folder can contain many items if a high degree of audit settings is enabled on the mailbox.

Single item recovery

From a user perspective, everything discussed so far works as in previous versions. The foundation is different but the effect remains the same. The Versions and Purges subfolders, which are never exposed to clients, provide additional functionality by allowing Exchange to preserve data even if a user attempts to change or purge deleted items. Microsoft calls this feature Single Item Recovery.

As we know, deleted items are now held in the Recoverable Items\Deletions folder and remain there until the deleted items retention period elapses, at which time the MFA permanently removes them from the database. Mailboxes that are placed on litigation hold do not respect the deleted items retention period, and items will remain in the folder until the litigation hold is released. Note that calendar items are always retained for 120 days, the logic being that the calendars of those under investigation are usually highly interesting to the teams working on legal discovery.

It is possible that a user might seek to change or remove items while they are in the Deletions folder. For example, if users receive a message containing some incriminating information, they can delete it with Shift+Delete to force the item into the Deletions folder. They can then use the Recover Deleted Items option to view the items in the Deletions folder, select the offending item, and delete it. In previous versions of Exchange, the item would be immediately removed from the database and a database restore would be required to retrieve it thereafter. Administrators will probably not be aware that the item was deleted, the database recovery will probably never be performed, and the item is lost for good.

However, for Exchange 2010 mailboxes that are enabled for single item recovery, the Store moves the item into the Recoverable Item\Purges folder. Users are unaware of this fact because the Purges folder is invisible to any client, and they probably don’t know that their mailbox is enabled for single item recovery. As far as the users are concerned, the evidence has been buried, but the Purges folder is indexed so a discovery search performed by an administrator will locate the item in the Purges folder as long as it is within the deleted items retention period. The items identified by a search are extracted and placed into the selected discovery mailbox in a folder named after the user and the date and time of the search. The administrator or other authorized user with access to the discovery search mailbox can then export the discovered items to provide the evidence to the legal team.

The Versions folder comes into play if users attempt to alter an item. Let’s assume that a user is worried about a document attached to a message in the Inbox. She opens the message, removes the attachment, and saves the change. To the user’s eyes, the item no longer has an attachment, but in reality the Store has saved a copy of the original message complete with the attachment in the Versions folder. Technically speaking, any action that changes an item generates a new version through a copy-on-write operation. Changes to subjects, message bodies, attachments, sender and recipient details, and date information are all examples of actions that generate a new version. Table 15-4 lists the actions that cause Exchange to retain a new version of an item in the Versions subfolder.

Table 15-4. Actions that cause item versions to be generated

Draft items are the only exception to dumpster processing. A draft item is one that has the “unsent” bit set in the MAPI message flags. If this bit is set, the dumpster does not capture updates in the versions folder. There are two reasons for this: First, a draft item typically goes through multiple revisions that might be captured by a client’s auto-save process before it is eventually sent. Second, a draft item is not really interesting for discovery until it is sent and becomes a full-fledged communication to another person. After all, it’s not a problem if a user thinks about doing something wrong, such as making an illegal recommendation to someone else to engage in insider trading, and captures the thought in a draft message. The thought only becomes a problem and consequently of interest for discovery purposes if the user sends the message to another person.

Knowing what’s in the dumpster

A user can view the items in the dumpster at any time by using the Recover Deleted Items option in Outlook or Outlook Web App. Administrators can’t access items in the dumpster unless they open a user’s mailbox, but they can get a sense of how much data are held there and what type of data they are by using the Get-MailboxFolderStatistics cmdlet and pointing it at the dumpster with the –FolderScope parameter. For example:

Get-MailboxFolderStatistics -Identity TR -FolderScopeRecoverableItems |
Select Identity, ItemsInFolder, FolderSize, FolderType

Identity            ItemsInFolder       FolderSize                   FolderType
---------           -----------         ----------                   ----------
tr\Recover          6                  15.1 KB (15,466 bytes)        RecoverableItemsRoot
tr\Deletions        75                 6.905 MB (7,240,761 bytes)    RecoverableItemsDeletions
tr\Purges           9                  40.59 KB (41,562 bytes)       RecoverableItemsPurges
tr\Versions         3                  269.7 KB (276,174 bytes)      RecoverableItemsVersions

You can see references to the different types of items captured by the dumpster. As we know from the description in the previous section:

• The Root folder holds stripped versions of calendar items.

• The Deletions folder stores any soft deleted items.

• The Purges folder stores any hard deleted items.

• The Versions folder stores any previous versions of deleted items that have been edited.

Calendar items are held in the dumpster for 120 days. “Stripped” versions of calendar items have no attachments. Exchange creates these copies from calendar items that are purged or updated in the dumpster to use as logs to track these changes. The stripped items are stored in the Root folder of the dumpster. Full copies of items that are changed or purged are also stored in the Versions or Purges folders, respectively.

Managing dumpster parameters

Single item recovery is not enabled for any mailbox by default. You can enable a mailbox as follows:

Set-Mailbox -Identity 'John Smith' -SingleItemRecoveryEnabled $True

In a scenario where executives or other users who need to use single item recovery are gathered into a single database, you can enable all the mailboxes by piping a list of mailboxes into the Set-Mailbox cmdlet. In this example, we also set the period for the Store to maintain the deleted items to 28 days (the default is 14).

Get-Mailbox -Database 'DB1' | Set-Mailbox -SingleItemRecoveryEnabled $True
-RetainDeletedItemsFor 28

Exchange doesn’t provide a method to configure every mailbox in an organization for single item recovery through a global setting. It’s easy (but slow in large organizations) to find all mailboxes with the Get-Mailbox cmdlet and set single item recovery for each, but you then face the task of ensuring that any new mailboxes are enabled for single item recovery thereafter, meaning that you have to run jobs to locate mailboxes that haven’t been enabled regularly. This is an annoyance that Microsoft is aware of and one that they are considering addressing in a future release.

Moving on from single item recovery, you can set a default deleted items retention period for a database with the Set-MailboxDatabase cmdlet:

Set-MailboxDatabase -Identity 'DB1' -DeletedItemRetention 15

Like many other settings, these are held in Active Directory and cached by the Store for faster access. The exact time when a mailbox is enabled for single item recovery depends on how quickly Active Directory replicates the new setting around the organization and when the Store cache is refreshed after replication.

Items in these folders do not count against the mailbox quota. You can set separate quotas for the dumpster folders on a per-mailbox or per-database level. For example:

Set-Mailbox -Identity 'John Smith' -RecoverableItemsWarningQuota 1GB
-RecoverableItemsQuota 1.5GB

In this case, we set a warning point at 1 GB and an absolute quota at 1.5 GB for the dumpster folders in the specified mailbox. The default values used if these parameters are not explicitly set are 20 GB and 30 GB, which seems excessive unless a mailbox is placed under litigation hold and needs to maintain a large amount of deleted items for a significant period. Increasing the retention quota does not affect the mailbox quota, but it does have an impact on the calculation of database size as the Store keeps the deleted items in the same database.

When the total size of the folders reaches the warning point, the Store issues warnings in the event log. Litigation hold disables expiry of items from the dumpster, so they will be held until the litigation hold is released. More important, Store background maintenance will begin to delete the oldest items in the Deletions folder to free up space and to accommodate newly deleted items. If the absolute quota is reached, the Store flags the error and will not preserve newly deleted items until some quota is released.

Table 15-5 summarizes the different data retention states that an Exchange 2010 mailbox can be in from the default position where the mailbox essentially operates much like Exchange 2003 or Exchange 2007—through the enabling of single item recovery—which provokes the use of the Purges and Versions folders, to a point where litigation hold freezes the mailbox and prevents any data from being removed until the hold is released.

Table 15-5. The different data retention states for Exchange 2010 mailboxes

Initial measurement of the effect of single item recovery on mailbox sizes indicates a growth of 3 to 5 percent for a 14-day retention period. It’s not usual to enable every mailbox in a database for single item recovery unless you have dedicated databases for VIPs or other users affected by legal proceedings, so the overall effect on a mailbox database is usually less.