How to deal with departed user data in Microsoft Office 365Alex Fields
Going from one organization to the next, I am always amazed at how different people implement their own take on new user setups or decommissioning departed users. Some have no real organized methodology and it’s a hassle every time, while others have a well-developed practice or script around each process.
It is hard to argue there is one “best way” to handle everything (although there are certainly wrong ways to do it). And, depending on what all is in the environment, there may be more or less “to it”–e.g. sometimes there are other applications, security badges, telecom systems and so on to consider. But, today, we’re just going to talk about Microsoft / Office 365 and using Data Governance / Retention Policies in advance of spinning those services down for terminated user accounts.
The crux of the considerations related to departed users in Microsoft / Office 365 really just boils down to licensing for most organizations: you don’t necessarily want to leave departed users hanging around forever. Those cloud licenses cost real money after all, and you will likely want to recover the license sooner than later, in order to reassign it to a replacement person. But don’t you also want the data?
I’ll start with the bad news: when you power down a user account and remove the license, it is going to delete the corresponding data for that user after a short period of time. So if you need to get into a deleted mailbox that is more than 30 days old… Sorry. It doesn’t exist anymore. And more bad news: some Office 365 data probably just isn’t coming back at any time, if you needed to retrieve it later on. For instance, I am not aware of a way to preserve or retrieve stuff like personal Flows that the user may have configured. But the data repositories that most folks will care about are:
- Exchange Online mailboxes
- OneDrive accounts
We can handle both with native tools (that is, without relying on a third party). But before you get started, licensing considerations will come into play: your life will be SO MUCH EASIER if you have access to the Data Governance features, e.g. Retention policies. Office 365 E3 or E5 and Microsoft 365 plans (including Business) will all have the “right stuff.”
If you don’t have access to Data Governance/retention in your subscription, it’s an uglier manual process to get this data backed up or transferred before you decom the account.
Setup retention first
When you delete a user account, or even remove the license from the associated user account, the data locations will be marked for deletion also, but those data locations will be “recoverable” for up to 30 days (by default). Interestingly, for OneDrive it is possible to adjust this default up to ten years–and this is even without the data governance features! More info on OneDrive retention and restoring deleted OneDrive accounts:
For Exchange, you might choose to place a departed user’s mailbox on litigation hold, which will keep the data indefinitely, even after it is deleted. Taking these steps would make it recoverable long after that 30 day mark.
However, I generally recommend that you have retention policies in place that are organization-wide, and which apply to all Exchange, OneDrive and SharePoint data locations. For instance, a policy that will preserve company data for say three years from the date last modified. Your own requirements may be different.
But it is also possible to retain data using a policy that is scoped to an individual. In either case, you would need to configure your retention before removing any licenses from the user account (since removing a license will initiate a decom of the corresponding data locations also).
One reason retention policies are so powerful is the fact that you do not have to take steps to manually export data “just in case” every single time–the data will remain intact if you need it (but very often you do not). Also, you can create policies that apply very broadly across all services and data locations in the 365 platform.
Turning down mailboxes: Shared mailbox vs. Inactive mailbox
In many instances I have seen organizations converting user mailboxes for departed employees into shared mailboxes, and granting access to a replacement person, or to a supervisor. While it is possible to do this, I don’t care for the arrangement.
Oftentimes (and folks may not realize it) there will be privacy issues with the shared mailbox methodology. It is pretty common for people to have private communications in their inboxes, and some of that wouldn’t be appropriate to expose to a replacement person, or even to a supervisor.
I am not only talking about personal emails to friends/family, but also internal company related emails. Think about HR situations; imagine reading about private bereavement, health issues, or a formal HR complaint that was filed against a supervisor or other co-worker. Consider also that chat history from Skype/Teams lives within a mailbox… No bueno. That’s my opinion anyway, but I’m big on privacy.
Enter inactive mailboxes. In my book, this is the preferred methodology for handling departed users. If you have either a litigation hold enabled on the mailbox, or, as I mentioned above, a retention policy, then you can simply remove the license and the mailbox will then go into a “soft deleted” state, and remain there for the duration of the retention period (and indefinitely if you enabled litigation hold).
Now the content is safe, and you can get at it if you need to, but the mailbox doesn’t have to remain in play as a shared mailbox or be visible in the global address list. See your list of inactive mailboxes at https://protection.office.com, go to Data governance > Retention, and choose the ellipses:
Or see them via PowerShell:
Get-Mailbox -SoftDeletedMailbox | Select-Object Name,ExchangeGuid
Recovery must be done via PowerShell, however. Microsoft has published these articles for your reference:
- Recover the inactive mailbox (e.g. if the departed user returns to the organization) or
- Restore the inactive mailbox to alternate / merge it with another mailbox.
Doing the shared mailbox thing well
If you are going to convert the mailboxes to shared mailboxes for a period of time before deleting them, and you are okay with the privacy concerns I mentioned, then at least do it the right way. This means:
- Convert the mailbox to shared before removing the license (or the mailbox will just disappear)
- Consider an out-of-office plus forwarder on this mailbox instead of actually granting full access to the replacement person
- Only assign permissions to those who need it
- Disable the account for sign-in (just because it is converted to shared, doesn’t mean the account is automatically inactivated)
- Revisit and remove the shared mailbox after the “overlap” period has passed (the replacement person doesn’t need access to this mailbox indefinitely)
You may need to retrieve, if not an entire mailbox or OneDrive account, just one specific email or document, or maybe a handful of them. You can also leverage eDiscovery or Content searches in this case.
No lie, these aren’t the easiest things to navigate, but once you’ve done it a couple of times, it’s not so bad. Just awkward. I think what we’d really like to see is more of a traditional backup and restore tool (there are third party products out there for this). But this would give you access to search for items that were inside of a deleted mailbox (provided the mailbox was first placed on litigation hold or brought under scope of a retention policy).
Aside from the retention considerations (which should be in place globally), if you are creating your process for deactivating a user account, make sure you account for all of the following:
- Wipe the departed user’s device of all corporate data (look at MDM or MAM accordingly)
- Change account password and then disable the account for sign-on as soon as possible (you can grant access to data locations without having the account active for sign-in)
- Decide how you will deal with supervisor or replacement access to data (or, as I suggest just skip ahead to remove the license and allow the retention policies to work their magic) :
- Who gets access to email, and to documents?
- Just new items (forwarder) or entire history (shared mailbox)?
- Remove licenses from the account (license can be added back to the account to more easily restore data locations in the short term)
- Delete the account (on your preferred timeline)
What a fantastic article. Thank you for this!
Thank you for this!
Is it normal for users to see the retention policy within their email?
Yes, it would be nice to be able to hide it, no? Many use lit hold as an alternative, per mailbox.
Well done! Thanks for sharing as the MS docs are not as clear.
What happens from a retention policy standpoint when a mailbox is converted to shared and the license is removed? We have a default retention policy that deletes mail after 2 years, but we also have users added to an exception list in this policy so their mail is never deleted. So when an “included’ user is converted to shared, is the mail still deleted after 2 years? Likewise, if a user in the exception (keep forever) list is converted to shared, is the mail still kept indefinitely?
Yes, the shared mailboxes are still covered by the retention policy. As well, no data would be destroyed in a shared mailbox if there is no policy set against it or if nobody is going in and deleting stuff. You can put retention policies that preserve or delete or both, and shared mailboxes can be included or excluded as desired.
If I convert a user to a shared mailbox is the OneDrive information still kept as well? Also is the OneDrive information accessible if so? If NOT I am ok with syncing the data and copying it off to an external drive before converting but wanted verify because I could then skip that step. Thanks!! Good Post!!
One of the benefits of having a subscription that includes stuff like Retention policies is that you don’t have to worry about converting to shared mailboxes just to keep data. When you have a user who leaves, it’s fine. You can remove the license and the data will be preserved (they call it an “inactive mailbox”)–these do not need to be licensed since the person no longer exists in the org. It is just one of the benefits of having the subscription that allows you to apply retention policies. The only reason you might make the mailbox shared is if you want their supervisor to have access to the data after they leave. But if you’re just preserving it for compliance or archival purposes, it’s not necessary to make it into a shared mailbox. Similarly, you can preserve their OneDrive data with retention policy. It won’t go away if it is under preservation, even when you remove license.
I’m implementing retention policy for our termed users and had question. If i want to keep a users mail, for 7 years and then have it all automatically delete at that point. Can I assign the retention policy for 7 years but leave the delete option unchecked? After 7 years does that inactive mailbox fall off the policy and purge? Say a user has been at the company for 10 years. I don’t want the first 3 years of emails to immediately delete if I put 7 year policy with the delete option. Is there another way that this result can be achieved?
You can use either Litigation Hold or Retention policy to preserve the inactive mailbox. As you say, at the end of the expiration (say 7 years) the mailbox will be removed. No need to implement delete policy (the mailbox would not exist except for the preservation, if you have removed the underlying license and account).
Will retention policies still retain data if you delete the user account? e.g. the user account is synced from AD to AAD and as part of the leaver process the AD user object is deleted, thus actioning the removal of the object from AAD at sync.
Retention policies do not apply to the user objects but rather the data. Even if a user account is removed the data will remain. So for example if there is a mailbox under preservation, when the account is deleted, the mailbox remains but gets marked as “inactive.” Then if you restore the user account or create a new one, you can also restore the mailbox via PowerShell to the user object.
Hi Alex, great article. I also used your hybrid exchange article to set up our hybrid vm after migration.
Suppose we have a termed user, but a request by the manager is made to have access to any incoming emails for a short period of time. In that case, I will add the termed account to the retention policy. Let the policy take. Then I convert the termed mailbox to a shared mailbox, and remove the license. Set up the forward or access. Then after the period of time has elapsed the account is deleted.
Will this method still convert the mailbox to an inactive mailbox?
If it is still under retention, yes. Shared mailboxes also will be retained same as user mailboxes.
GREAT article, thank you! Question about the scope: I was thinking for phase 1 to target to an AAD Group of termed users. The MS article on Retention states the following, which would break my idea if I understand it correctly. (with desired outcome to preserve inactive mailboxes) Do you typically leave all recipients for the termed users scenario?
“When you apply the retention settings to All recipients, any inactive mailboxes are included. However, if you change this default and configure specific inclusions or exclusions, inactive mailboxes aren’t supported and retention settings won’t be applied or excluded for those mailboxes.”
Generally you would want to protect all mailboxes with a default, org-wide retention policy, yes. That way, when a user becomes terminated, their mailbox becomes inactivated without you having to do anything special. You can use additional policies if specific mailboxes should have different retention/deletion periods, but there is normally at least a broad preservation policy (e.g. 2, 3, 5 years, or whatever they want).
If you set an org-wide retention policy to retain exchange data for 7 years then delete, does that mean that all exchange data will be deleted after 7 years, even data that’s in an active mailbox’s inbox, or does this apply only to the exchange data that’s in the recycle bin?
Retention policies govern all data, not just deleted data.
I use a powershell script to move a users OneDrive to our support account as part of the offboarding process. Then share this to whom ever needs access
I love this article. Have read it several times. Well done!
Do any of you amazing person have a fully working PowerShell script to help on employee offboarding process? If any of you do, could kindly share the code with me?
My humble PowerShell script code does about 98% of what I need when offboarding a user, I’d love to learn from you guys.
We have online archiving enabled for several users. If a user has online archiving enabled and that user leaves the company, will the online archive be retained based on the retention policy as well when the user is deleted?