What you should do to secure mailboxes when employees die

Last week, I discussed the steps that companies can take to secure an Exchange mailbox after an employee is terminated or otherwise leaves the company. I also looked at the steps to accomplish the same goal for Office 365 in this article. Well, life is not easy at times, which brings me to the fact that I use Windows Phone (but for how long more, I ask myself?). One of the unique features of Windows Phone is the “People Hub” app, which presents an integrated view of Facebook, Twitter, and LinkedIn feeds. The “live” tile for the app displays an ever-changing rota of pictures taken from the different feeds. It’s amusing rather than useful and emphasizes the active nature of Windows Phone tiles rather than the static nature of the icons used by competitors.

My ambivalent attitude to the tile was somewhat shaken the other day when a photo of a recently-deceased cousin appeared. The photo came from his LinkedIn profile, which hadn’t been updated to reflect his demise. The same issue might have happened with any of the other social networking services and is simply a reflection of the uber-connected world in which we now live (this article provides a good overview of how these services are coping with the challenges).

All of this got to thinking about how organizations deal with mailboxes belonging to the recently departed. In terms of consumer email systems, Gmail has a well-defined policy to allow relatives to gain access to someone’s account after their death. With Outlook.com, it seems like you have to email the “Microsoft Live Custodian of Records” (per this process). You might think that these processes are burdensome, especially in the trauma of a recent death, but it is important that service providers protect the privacy of all concerned.

Which brings me to the question of how companies deal with the Exchange mailboxes (both on-premises and in the cloud) of deceased employees. Because almost every employee now has a company-provided mailbox, this is a situation that will happen so it’s important that administrators have clear and unambiguous direction as to how to proceed. It’s not one of the more pleasant parts of implementation projects but the growing importance of compliance makes securing and the proper disposal of these mailboxes a task that must be faced.

I do not have a magic formula to solve the problem. Each company is different and I am sure that better solutions exist. In any case, here is the general approach that I take:

First, it is imperative that the death is documented. This is a HR function and HR should include informing IT of the need to secure a mailbox once HR knows that an employee has died. A correctly validated and signed-off notice should go from HR to IT to request the process to begin.

From a technical perspective, the steps are pretty similar in all companies and share many of the characteristics discussed in my articles from last week:

ForEach ($Group in Get-DistributionGroup) { ForEach ( $Members in Get-DistributionGroupMember  -Identity  $Group.Alias| Where-Object { $_.PrimarySmtpAddress -eq "[email protected]"}) { $Group.DisplayName}}

All of the above can be adapted for use with Office 365 enterprise plans, which also include the option to use a feature called inactive mailboxes. Inactive mailboxes are designed to allow information to be retained without incurring the cost of an Office 365 subscriber license. The feature leverages the way that Exchange 2013 in-place holds work by placing mailboxes on-hold before deleting them. The act of deletion relinquishes the subscriber license for the mailbox but because Exchange knows that the mailbox is subject to a hold, the mailbox content is not removed. Instead, Exchange retains the content for as long as the hold is in place. The hold might be for a set period. On the other hand, it might be indefinite. And while the data exists, it can always be recovered if needed for compliance purposes or to provide to the employee’s family.

Recovery isn’t a simple matter of logging on with Outlook or Outlook Web App because the deleted status of the mailbox renders it invisible for user clients. Instead, you have to conduct an eDiscovery search (via EAC or EMS) to scan the hidden contents and export the mailbox to a discovery search mailbox. The next step is to move the content from the discovery search mailbox to a PST. With Office 365, you also have the chance to use a compliance search to do the same thing (compliance searches are like eDiscovery searches except that they don't include the ability to hold but can include SharePoint and OneDrive for Business sites too).

Speaking of SharePoint, it's critical to cover all the other applications that someone has used in any plan to preserve data after death.

I know this topic is distasteful to some readers. However, we live and work inside a world where much of our knowledge exists electronically and can only be accessed through electronic means. With that in mind, it’s better to be prepared than to build a policy on the fly.

Follow Tony @12Knocksinna