Preserving mailboxes when employees leave

The question of how to handle the mailboxes of what are charmingly-called “leavers” was raised by Andy Knight of Essential in a blog post that focuses mostly on PST files. The problem of how to retain information when people leave is an interesting issue that has been with us since the earliest days of email. However, the escalating and ongoing requirements of preserving data for legal discovery and the use of online archives and other repositories such as SharePoint has made the problem more complex.

Long ago, dealing with someone who left the company for one reason or another (including those who unfortunately died when employed) was simple. HR normally called the email administrator up to say that “x’s out the door” and their mailbox was promptly deleted. End of issue and time for another coffee.

A slightly more complex solution to the problem was to disable the mailbox for a period, usually of the order of 30 days, to allow co-workers or the person’s manager to access the mailbox and retrieve whatever information was felt to be of interest. After the period elapsed, the mailbox was removed.

But then the legal community cottoned on to the fact that email contains many interesting and useful facts that can be used to prosecute law suits and the demands for access to mailbox contents began to grow. The first instance where email proved to be the missing piece of a jigsaw that most can remember was the “Iran Contra” affair when Oliver North deleted a message on an IBM PROFS system in 1986 only for the message to be recovered from a backup tape.

Retrieving email in those days wasn’t much fun. It involved a lot of boring work to restore email servers from backup tapes. Typically you’d set up an email server with a configuration that matched the target server and then restore tapes, day by day, to allow lawyers to pour over mailboxes to look for smoking guns and other evidence. Vast quantities of forests were consumed by line printers as messages were printed off to be presented in court – if it wasn’t on paper, a judge wouldn’t read it.

Things are a lot easier today because email servers incorporate features to preserve messages. Of course, having the features is one thing, using them is quite another – a fact illustrated in the famous Apple vs. Samsung patent lawsuit where Samsung alleged that Apple didn’t do a good job of retaining messages sent by Steve Jobs and Jonathan Ive, at least not in such a way that the messages were discoverable to be provided to Samsung. Of course, Samsung’s own email system (rejoicing in the splendid name “mySingle”) didn’t do such a great job of message retention either as it forced users to save messages manually before they were automatically removed from the servers on a biweekly basis. This goes to prove that relying on instructions given to users to preserve evidence isn’t a great strategy.

Exchange 2010 (and 2013) offer an array of methods to preserve mailboxes, and once preserved their contents are available to multi-mailbox discovery searches and so should be capable of serving as a source of evidence. I don’t like the methods outlined by Andy (putting anything in a PST is a no-no from my perspective). As I describe in "Exchange 2010 Discovery Searches: What about users who leave?", my preference is to put the mailboxes of those who leave into a state where they cannot be used and keep the mailboxes online until HR and Legal agree that it is safe to remove the mailboxes. Microsoft obviously agree with this approach because they have introduced the notion of "inactive mailboxes" for their Office 365 service, essentially a way of allowing organizations that use Office 365 to keep mailboxes around without being charged for their use. The feature is only available for the E3, E4, A3, A4, G, and P2 plans.

You cannot mark a mailbox as being "inactive" in Exchange 2010 or using an on-premises Exchange 2013 deployment. It would not surprise me if the feature surfaces in a future update for Exchange 2013 because it is natural to reuse good ideas. In the meantime, we still have to retain mailboxes.

Disk storage is relatively cheap (and getting cheaper) these days and the additional cost of keeping some mailboxes for a couple of months or even a year pales into insignificance when compared to the frightening costs that can quickly mount up in lawsuits, even if you work for a company that experiences relatively high employee turnover (the usual figure is between 8% and 10% annually, unless you work in a call center in which case turnovers of 80%-plus are not unknown)

Of course, you don’t want new mail arriving into mailboxes that are no longer being used. Two reasonable approaches immediately suggest themselves as good solutions. First, create a distribution group (let’s say “Disabled Mailboxes”) and add all the disabled mailboxes to the group. Put a MailTip on the group to advise local users that they shouldn’t attempt to email the group. Block incoming messages to mailboxes in the group with a transport rule. Something like the following would be a good start (always test code copied from the Internet to make sure that it works, meets your needs, and doesn’t do bad things):

New-TransportRule "Block Email to Disabled Mailboxes" -SentToMemberOf "Disabled Mailboxes" -RejectMessageEnhancedStatusCode "5.7.929" -RejectMessageReasonText "Regretfully the user that you attempted to contact is no longer with Contoso Corporation" -Enabled $True

A customized DSN status code is used here. You can use the New-SystemMessage cmdlet to create customized text to go along with the status code.

Another approach is to clamp down on the mailbox’s ability to receive messages by setting its properties with the Set-Mailbox cmdlet. For instance:

Set-Mailbox -Identity "Tony Redmond" -AcceptMessageOnlyFrom Administrator -RequireSenderAutenticationEnabled $True -MaxReceiveSize 1KB

This command limits the set of users who can send messages to the mailbox to “Administrator”, who will only be able to send 1KB messages if they should try. The RequireSenderAuthenticationEnabled switch isn’t strictly necessary but it provides another level of block by ensuring that only authenticated users (those who have accounts in your forest or are federated with your forest) can send messages to the mailbox.

This only scratches the surface of the many and varied ways that administrators deal with unused mailboxes on an Exchange server. I’m sure that you have your own favorite approach, agreed with and signed off by HR and Legal, just so that your hands are clean!

Follow Tony @12Knocksinna