Table of Contents
Manage the Mailboxes of ex-Employees
Updated 19 September 2023
As reported in September, a listing of inactive mailboxes is now available in the modern Exchange Online admin center. This prompted some discussion about the management of inactive mailboxes, with some pointing to Microsoft’s recommendation to create an inactive mailbox retention policy to specifically manage inactive mailboxes. While retention policies are not a new feature as alleged by Microsoft, the page contains some good points to consider.
Shared mailboxes are also a valid method of retaining the mailboxes of ex-employees. I don’t discuss that alternative here.
Inactive Mailbox Retention Primer
Briefly, an inactive mailbox is a mailbox belonging to a deleted account. If you run the Get-ExoMailbox cmdlet to return the set of inactive mailboxes, you might see some with a value for the ExternalDirectoryObjectId property, the pointer which connects an Exchange Online mailbox to an Entra ID (Azure AD) account.
Get-ExoMailbox -InactiveMailboxOnly | Format-Table DisplayName, ExternalDirectoryObjectid DisplayName ExternalDirectoryObjectId ----------- ------------------------- Dongli Pan Dylan Webb Ed Banti Frank Clonan Imran Khan b8eef43d-6854-4d77-9e03-745cf2e11e11
The mailboxes with ExternalDirectoryObjectId values belong to user accounts deleted within the last 30 days. During this period, administrators can recover the accounts and reconnect the mailboxes. Once the 30 days lapse, Entra ID permanently removes the account and Exchange Online nullifies the connection between the two objects.
Multiple holds (litigation, in-place eDIscovery, or retention policy) can be present for an inactive mailbox. These holds must be placed while the mailbox is active. Even after their user accounts disappear, inactive mailboxes remain in place until the last hold lapses. At that point, the Managed Folder Assistant cleans up and removes the mailbox.
Administrators can still recover data from inactive mailboxes or restore an inactive mailbox to connect it to a brand-new account, but the link between the original account and mailbox is gone. In a nutshell, inactive mailboxes are a great way for organizations with Office 365/Microsoft 365 E3 and E5 licenses to keep information for ex-employees until the need for their mailboxes disappear. You don’t have to pay anything for inactive mailboxes, no matter how much storage their primary and archives (including auto-expanding archives) occupy.
The Advantage of a Retention Policy for Inactive Mailboxes

A retention policy for inactive mailboxes is often used to gradually clear out information from inactive mailboxes on the basis that old information loses its value to the organization over time. To achieve this goal, the retention policy will:
- Apply only to inactive mailboxes. You can identify the mailboxes individually or by using a distribution list. Up to 1,000 individual inactive mailboxes can be added to a single (static scope) retention policy. If you want to add more, you can create multiple policies. Retention policies using adaptive scopes don’t have the same limitations, and you can identify inactive mailboxes by searching for their mailbox state. Because this process happens automatically and on an ongoing basis, you don’t have to worry about adding new inactive mailboxes to the retention policy.
- Remove content after a set period. Usually, this period ranges from six months to two years. In certain regulatory or legal conditions, an organization might retain mailbox contents for longer periods (I’ve heard of situations where inactive mailboxes are kept for ten years).
If you use a distribution list to add mailboxes to a retention policy with a static scope, remember that this is a one-time operation. Microsoft 365 reads the mailboxes from the list membership and adds them as separate Exchange locations to the retention policy. Any further additions or removals from the distribution list are not synchronized with the locations in the retention policy. Also, Microsoft 365 adds the managers of the distribution list to the policy. All of the above means that using a distribution list to populate a retention policy is strictly a method to add multiple locations to a policy rather than a means of maintaining the set of Exchange locations used by the policy.
The Managed Folder Assistant (MFA) processes inactive mailboxes along with active mailboxes. For instance, if the retention policy mandates the removal of information older than a year old, MFA will scan the mailbox to find any items older than a year and remove these items each time it processes the mailbox. Note that MFA might have to apply several retention policies to an inactive mailbox. If this is the case, the longest retention period applies.
Microsoft says that the advantages of having a specific policy are:
- You can configure the retention policy to retain mailbox content only as long as necessary to meet your organization’s requirement for former employees.
- It’s a good way to identify inactive mailboxes because the retention policy will only be applied to inactive mailboxes.
The first point is correct. The second is technically correct but depends on administrators applying the policy to mailboxes before deleting their user accounts. You can’t apply a retention policy to a mailbox once it becomes inactive. Any attempt through the administrative GUIs or PowerShell fails because the inactive mailbox is not recognized as a valid target.
Microsoft also makes the point that if you use a specific retention policy for inactive mailboxes, you can update the retention settings in one place to apply the new values to all inactive mailboxes. I think this is fair.
Finding Inactive Mailboxes with a Specific Retention Policy
I have doubts about Microsoft’s assertion that having a specific retention policy for inactive mailboxes is a good way to identify inactive mailboxes. Running Get-ExoMailbox -InactiveMailboxOnly is the best way to find the set of inactive mailboxes. To find the set of mailboxes to which a retention policy applies, you would have to examine the InPlaceHolds property of each mailbox to see if it is stamped with the identifier of the retention policy. Something like this would work:
# Find the identifier for the retention policy $Policy = Get-RetentionCompliancePolicy -Identity "Retention Policy for Inactive mailboxes" | Select-Object -ExpandProperty ExchangeObjectId # Build search string $CheckGuid = "mbx" + $Policy.Guid.SubString(0,8) + "*" [array]$Mbx = Get-ExoMailbox -InactiveMailboxOnly -Properties InPlaceHolds If (!($Mbx)) {Write-Host "No inactive mailboxes found - exiting"; break} Write-Host ("Processing {0} inactive mailboxes..." -f $Mbx.Count) ForEach ($M in $Mbx) { $Holds = Get-ExoMailbox -Identity $M.UserPrincipalName -Properties InPlaceHolds -InactiveMailboxOnly | Select-Object -ExpandProperty InPlaceHolds If ($Holds -like $CheckGuid) { Write-Host ("The in-place hold for Inactive mailboxes applies to mailbox {0} ({1})" -f $M.DisplayName, $M.UserPrincipalName ) } } #End ForEach
Note that you’ll need to run the Connect-IPPSSession cmdlet first to connect to the compliance endpoint before running Get-RetentionCompliancePolicy to fetch the identifier for the retention policy. Running this PowerShell will report the exact set of inactive mailboxes assigned the retention policy, so there’s some value in that. Then again, if you use the one retention policy and assign it to mailboxes before deleting their Azure AD accounts, the Get-ExoMailbox cmdlet will return the same set.
Learn how to exploit the Office 365 data available to tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.
Hello,
worked better for me:
{Write-Host “No inactive mailboxes found – exiting”; break}
Write-Host (“The in-place hold for Inactive mailboxes applies to mailbox {0}” -f $M.UserPrincipalName)
Thanks. I made a couple of other changes too…