The question of how to deal with mailboxes for departed users is one that often pops up, and it's a question without a simple answer. The process to follow will depend on many details including the company policies, the business requirements, the circumstances around the departure, even the functionalities of the different pieces of software that govern the user lifecycle. Revoking access, preserving important data, removing data to make sure you comply with the legal requirements, notifying colleagues and partners, all that and more needs to be considered.
In this article you will learn about the different factors that impact your decision for preserving Exchange Online mailbox data, and the different options that you can choose from. There is no single correct approach here, but I will give you some recommendations as to the questions you should be asking and which method fits which scenarios.
Factors to Consider
One of the first questions you should ask is whether you genuinely need to preserve the mailbox data. The answer to this question, as well as some details related to it, will most often govern the whole process. So do you really need the data?
If the departed user was an entry level employee or a summer intern, the answer will probably be no. Still, depending on the industry you’re working in or the country legislation, the need to keep the data might arise. For a mid-level employee or someone that has been with the company for long time, chances are you will find some value in preserving the data at least for some short duration of time purely for the sake of convenience. Employees often forget to share important information with their peers, for example the contact details for an external partner. Getting the opinion of their manager or peers as to whether the mailbox can be immediately purged is usually a good idea. This does not necessarily mean that said colleagues should be given access to the mailbox content, but that’s certainly an option.
Expert level personnel, team leaders and managers represent another group of employees that are likely to be the subject of data preservation requirements. Chances are there is a lot of sensitive information stored in their mailboxes, so while preservation is a no brainer, access to the data should only be allowed in controlled manner.
Immutability of the data is another factor you should be considering. Immutability means preserving data in an unchanged state, which is important if the data is being retained for legal requirements.
If the need to preserve mailbox data is identified, you should also check whether the user has archived data, either in the form of an Exchange Online archive, or stored in PST files. Keeping the Online archive has implications for licensing, which I will explain a bit later. PST files should be imported into the primary mailbox or archive mailbox so that you have a single, authoritative source of data, and so you can control the preservation of the data.
Whether the mailbox should continue receiving new email messages is another question you need to answer. Again, there are multiple correct answers here. In some cases, it might not be appropriate to keep messages flowing to the mailbox. In other cases, a critical business workflow might depend on continuing to receive emails to the mailbox. While the question might not be an easy one to answer, the solution is simple as there are multiple ways to stop or redirect the mail flow to another recipient. This can be achieved either by configuring email forwarding on the mailbox, configuring a mail flow rule (also referred to as a transport rule), or simply by removing the SMTP addresses from the mailbox and assigning them to another recipient.
The question of how to handle group membership and the recipient status overall should also be addressed. If you decide to keep the mailbox active for a while, it might be a good idea to hide it from the GAL and remove it from any groups (including distribution groups, security groups, and Office 365 Groups).
Similarly, the question of whether you should notify senders for the user departure should be addressed next. The lack of reply or the eventual non-delivery report (NDR) message doesn’t look too good from a business perspective, and can lead to potential problems with both internal and external contacts, especially if the user was involved in an important business process or an ongoing project. An out of office (OoF) message or an Inbox rule can be configured if the mailbox is still active with a short explanation for the departure and most importantly, contacts for the replacement person.
Again related to the above, you should decide how to handle delegate/impersonate permissions. Imagine someone sending message as the user after you have already notified people for the departure – it wouldn’t look too good. On the other hand, it might be vital that you keep the option to send as/send on behalf of the user, or simply grant those permissions to the person replacing the user or the one responsible for the mailbox cleanup task.
Whether you should keep the user account is another interesting question. Apart from the mailbox data, the user will most likely have additional resources worth checking and preserving, for example all the files stored in their OneDrive for Business. Even the actual user object and its associated permissions might be important, for example when a departed admin has been the only user with privileged access to particular application.
If directory synchronization has been implemented then you might be unable to remove the on-premises user object, as doing so will in turn remove the Office 365 object as well. Keeping the account active doesn’t necessarily require you to also keep any associated Office 365 licenses, but that’s another factor you need to take into consideration. As we move to discussing the different options for preserving mailbox data in the next section, you will notice that some of them have dependencies on specific types of Office 365 licenses.
Using Shared Mailboxes to Preserve Data
One of the most common methods to deal with departed users is to convert their mailbox to shared one. While this is certainly an option, and an easy one thanks to the “one-click convert feature” available in the EAC, there are certain disadvantages as well. The main argument for using this method is something along the lines of “shared mailboxes are free”. They are free indeed, but converting a user mailbox to shared mailbox still keeps the mailbox associated with the user object. While you might not need the Exchange license, by removing the license for the user you'll lose access to the user's data in other services, such as OneDrive for Business.
Simply having the mailbox items stored in a shared mailbox doesn’t guarantee data immutability however, so if you need to meet legal requirements the mailbox should have an In-Place Hold applied, which requires specific licenses (Exchange Online Plan 2, Office 365 Enterprise E3, and Office 365 Enterprise E5 at the time of this writing). Data retention might also be an issue – if you have requirements to purge all the data after say 7 years, manual actions might be required in the case of shared mailboxes.
Archives are also a challenge, license wise. If the user had an Exchange Online archive, keeping it will require that the mailbox remain assigned with at least an Exchange Online Plan 1 license, as detailed in the Exchange Online Limits article. If you're not willing to pay for a license, and instead want to use the “free” shared mailbox, then you'll need to look at options such as using an EWS-based script to move the messages from the archive mailbox to the primary mailbox, or achieve the same via PST export/import.
Another often overlooked issue is providing access to the shared mailbox. To quote the Exchange Online Limits article mentioned earlier:
“To access a shared mailbox, a user must have an Exchange Online license.”
Yes, there are ways to open a shared mailbox directly, but even though Microsoft is not enforcing the licensing requirements, you will still be breaking the agreement, which is not something you should look lightly upon. In turn, this means that access to the shared mailbox should be governed by delegate access, not by direct login. To mitigate the risk of data loss due to delegates deleting mailbox contents, you will need to apply read-only access instead of full mailbox access, which is slightly more complex to achieve.
As mentioned already, converting a user mailbox to shared one will keep the user object intact, along with any permissions and group membership. Any existing proxy addresses will also be kept and messages will continue to flow to the mailbox. This might or might not be the desired effect depending on your requirements, so it’s advised to review those upon conversion. Hiding the mailbox in the GAL and configuring an Inbox rule or OOO message to inform users is something else to consider, as discussed in the previous section. Granting additional permissions to facilitate the Send As/Send on behalf of functionality is also an easy task, so is making sure that any new messages are forwarded/redirected to additional recipients.
The user object remains linked to the shared mailbox, so deleting the user object from Active Directory or Azure AD is out of the question. You should also not remove the account from the scope of directory synchronization. While you can hide the shared mailbox from Exchange, other workloads don’t respect those settings and you will continue to see the user in SharePoint or OneDrive for Business for example.
Using Inactive Mailboxes to Preserve Data
The recommended method for preserving mailbox data is via the Inactive mailboxes functionality. The method works quite differently from the conversion to shared mailbox we discussed in the previous section. To make a mailbox inactive, you first need to apply an In-Place Hold, then you can delete the corresponding user object. Any licenses assigned to the user will be released at that stage, and any non-mailbox data such as OneDrive for Business will also be deleted.
The In-Place hold immutably preserves the mailbox data for the duration specified by the hold settings. This applies also to the Exchange Online archive mailbox, if one exists. In effect, inactive mailboxes make it easy to meet any compliance requirements related to data preservation and retention. If needed, you can make adjustments to the hold parameters later on, or even remove it, but only if the preservation lock feature is not configured. The best part of course is that you get all this for free, provided that you have the correct Office 365 licenses in the first place.
Since the user object is removed as part of the inactive mailbox process, you don’t have to worry about any remaining permissions or group membership, or the object being visible in the GAL. The corresponding on-premises user object, if any, can be excluded from the sync scope without any implications. Deleting the object means that people sending messages to any of its aliases will receive a non-delivery report (NDR). Any proxy addresses that were previously assigned to the mailbox can be reused with another recipient if the email address itself needs to remain active.
Inactive mailbox data can only be accessed by performing an eDiscovery search, which ensures that only designated people in the organization will have access to it. If some mailbox contents are needed they can be located using an eDiscovery search, and then copied to a Discovery mailbox where they can be accessed without impacting the immutability of the original content. Alternatively, you can merge the data from the inactive mailbox to another mailbox in the organization as part of the inactive mailbox restore process. Similar to the eDiscovery process, the contents of the original inactive mailbox will be preserved immutably, and you can repeat restore the process to other mailboxes as many times as needed.
Using PST Files to Preserve Data
Another method of preserving data is exporting it to PST files. There is hardly any argument for using this method, and you should really, really avoid it. PST files are unreliable, cannot be secured, cannot guarantee data immutability, cannot be managed centrally for the purpose of eDiscovery and so on. If you need further convincing, read the Complete Guide to Eradicating PST Files.
Other Methods to Consider
For the sake of completeness, we can mention some additional methods that might be worth considering. The first one is to simply leave the mailbox as it is and keep using it for as long its needed. This has the obvious downside of requiring you to keep the license assigned to the user, but as we discussed already, the same applies to some other scenarios. And if you are going to license a shared mailbox, you should best keep it as user mailbox instead. You can of course hide the mailbox from the GAL, restrict access and message delivery, ensure immutability and all the other details we discussed above.
For Hybrid environments another method is to off-board the mailbox to your on-premises Exchange server where it can be stored or archived to a third party system. This might be appropriate for cases where your compliance needs cannot be met by the toolset provided by Office 365.
In this article, we made a short overview of all the different factors that might impact your decision on how to handle mailbox data for departed users. After reviewing an extensive, but by no means exhaustive list of questions, we focused on examining two particular methods in details. The “convert to shared mailbox” method surely sounds like an easy and free solution, but it does have some gotchas. While it seems to be preferred by the majority of organizations, our personal recommendation is to use the Inactive mailboxes method instead, which aligns with Microsoft’s recommendation as well.
Of course, there’s no single solution that can fit all needs, so hopefully the detailed analysis we performed will help you better understand the issues associated with data preservation and help improve your processes.
Vasil Michev is an Office Servers and Services MVP, specializing in Office 365. He's currently employed as a Cloud Technical Consultant, and in his free time he can be found helping others in the Office 365 community.