Soft or Hard Deletes for Moved Mailboxes

One of the small but important changes that might have passed some by in Exchange 2010 SP1 was the change in the way that the Mailbox Replication Service (MRS) preserves source mailbox content after it successfully moves a mailbox.

In the original release of Exchange 2010, MRS deletes the source mailbox as soon as it deems that it has successfully moved a mailbox to a target database. Successful means that MRS moved the mailbox’s content, locked the mailbox, performed a final incremental synchronization to ensure that any changes that occurred since the move commenced have been captured, and then switched the user’s Active Directory attributes to point to the new mailbox location. If everything works smoothly (99.9995% of the time), then it is quite safe for MRS to remove the source mailbox from its database to release the pages occupied by the mailbox for reuse.

However, accidents do happen and Microsoft figured out that it is possible that a catastrophic problem could afflict the database that holds the newly moved mailbox soon after the move. In this scenario it’s possible that the mailbox might not have been backed up and so would not be recoverable.

Of course, you can protect against this kind of problem by using Database Availability Groups to replicate databases, in which case Exchange would simply recognize that a database problem had occurred and switch over to one of the database copies. But if only one copy of the database exists and that copy is now useless, you have a problem. The last backup doesn’t contain the newly moved mailbox and the source mailbox has been deleted. Cue annoyed user questions the intellectual credentials of the unfortunate administrator.

The solution implemented in all versions since Exchange 2010 SP1 (including Exchange Online in Office 365) is to “soft delete” the source mailbox. A soft delete means that the mailbox is marked to be deleted but the content is retained until the deleted mailbox retention period expires. This is a database-specific setting that by default is 30 days. In on-premises deployments, you can change the retention period with the Set-MailboxDatabase cmdlet. Once the retention period expires, the Mailbox Folder Assistant (MFA) will remove the content from the database (a hard delete) and recycle the database pages. However, until the retention period expires, the soft-deleted mailbox is regarded as a “disconnected” mailbox (one that has no link to an Active Directory account) that can be “reconnected” if required. So if the database holding the newly moved mailbox is hosed before the data is secured, you can recover the mailbox.

The change in behaviour makes absolute sense as there’s no point in throwing away data when the possibility exists that the data might just be required. Some observers have pointed to a potential downside in that the soft-deleted mailboxes occupy space in the source database for 30 days. I guess that this might be a problem if you really needed that deleted space to allow other mailboxes to grow within the database but I think it’s a spurious reason to advance that harks back to the days of expensive disk space when shrinking databases with ESEUTIL was deemed to be good practice. Kind of 1997 good practice really.

But I do offer help for those whose brows are furrowed at the thought of soft deleted mailboxes occupying valuable space. You can either reduce the deleted mailbox retention period to something less than 30 days or you can run the Remove-StoreMailbox cmdlet to permanently remove all of the data belonging to the mailbox from the database. Remove-StoreMailbox works extremely well but it’s a one-way operation that you shouldn’t execute unless you are absolutely sure that it’s safe to blow a mailbox away. Seeing that we are all skilled computer professionals, I guess there’s no risk here… or is there?

Follow Tony @12Knocksinna