How to work with Inactive Mailboxes


It usually starts with the following question: Is there a way to release the license of an Exchange Online user that left the company, but at the same time, keep the mailbox content? To get this done, we have a feature called Inactive mailboxes, but as we have seen some of our customers being a bit confused about the sequence of steps that needs to be taken to do this correctly, I wanted to cover this scenario.

Scenario

David is a cloud-only user. David currently has an Office 365 Enterprise E5 license. David leaves the company, so as an Admin, I’ll need to remove his account, but I still need to have access to his emails.

Note: In this article, we will provide the steps that have to be taken in order to correctly move a mailbox from the Active state to the Inactive state. Details about how to access the content of an inactive mailbox can be found here.

Before you begin

You have to be connected with PowerShell to Azure Active Directory / Microsoft Online Directory Service (MSODS) and to Exchange Online in order to complete tasks mentioned on this article.

Steps to take

1. Put the mailbox on a hold (which will also place the Archive on the hold, if it is present). For this scenario I’ve used LitigationHold, but, any hold from Exchange Online, or Security and Compliance can be used:

Set-Mailbox David -LitigationHoldEnabled $True -LitigationHoldDuration Unlimited

Note: The hold setting may take up to 60 minutes to take effect.

2. Ensure the mailbox has Litigation Hold enabled:

Get-Mailbox David | fl PrimarySMTPAddress, Identity, LitigationHoldEnabled, LitigationHoldDuration, MailboxPlan, PersistedCapabilities, SKUAssigned

User properties should now show:

PrimarySmtpAddress : David@contoso.com
Identity : David
LitigationHoldEnabled : True
LitigationHoldDuration : Unlimited
MailboxPlan : ExchangeOnlineEnterprise-0527a260-bea3-46a3-9f4f-215fdd24f4d9
PersistedCapabilities : {BPOS_S_O365PAM, BPOS_S_ThreatIntelligenceAddOn, BPOS_S_EquivioAnalytics, BPOS_S_CustomerLockbox, BPOS_S_Analytics, BPOS_S_Enterprise}
SKUAssigned : True

3. Check the number of licenses you have in total/assigned:

Get-MsolAccountSku | fl AccountSkuId, ActiveUnits, ConsumedUnits

Example of what you might get:

AccountSkuId : contoso:ENTERPRISEPREMIUM
ActiveUnits : 25
ConsumedUnits : 3

ConsumedUnits represents the number of licenses that are currently assigned.

4. Remove the Azure Active Directory user, which will move the mailbox to inactive state:

Remove-MsolUser -UserPrincipalName David@contoso.com

5. Check if the mailbox was deleted and become an inactive mailbox:

Get-Mailbox David -InactiveMailboxOnly | fl PrimarySMTPAddress, Identity, LitigationHoldEnabled, LitigationHoldDuration, SKUAssigned, IsInactiveMailbox, IsSoftDeletedByRemove, WhenSoftDeleted

The results should be similar to:

PrimarySmtpAddress : David@contoso.com
Identity : Soft Deleted Objects\David
LitigationHoldEnabled : True
LitigationHoldDuration : Unlimited
SKUAssigned : False
IsInactiveMailbox : True
IsSoftDeletedByRemove : True
WhenSoftDeleted : 6/4/2018 6:42:11 AM

6. Check if the Azure Active Directory user was deleted (you should be able to see it in the list of Deleted users, or you can run a command similar to the one below):

Get-MsolUser -ReturnDeletedUsers -All | where {$_.ProxyAddresses -match "David@contoso.com"} | fl UserPrincipalName, IsLicensed, Licenses

The results should be similar to:

UserPrincipalName : David@contoso.com
IsLicensed : True
Licenses : {contoso:ENTERPRISEPREMIUM}

7. Check the number of licenses you have in total/assigned (the license for the user that is now deleted should be released):

Get-MsolAccountSku | fl AccountSkuId, ActiveUnits, ConsumedUnits

The results should be similar to:

AccountSkuId : contoso:ENTERPRISEPREMIUM
ActiveUnits : 25
ConsumedUnits : 2

Optional (if you want to remove the Azure Active Directory user for good):

8. Wait for 30 days to have the Azure Active Directory user deleted from the Deleted Users list, or run a command similar to the below in order to permanently remove the user:

Get-MsolUser –ReturnDeletedUsers -All | where {$_.ProxyAddresses -match "David@contoso.com"} | Remove-MsolUser -RemoveFromRecycleBin

9. Check if the user still exists in the Active Users, or in Deleted Users (for both commands no results should be returned and you should not see the user within Deleted users anymore):

Get-MsolUser -All | where {$_.ProxyAddresses –match “David@contoso.com”}
Get-MsolUser -ReturnDeletedUsers -All | where {$_.ProxyAddresses -match "David@contoso.com"}

10. Verify that the mailbox is still in the inactive state, and the Litigation Hold is still enabled:

Get-Mailbox David -InactiveMailboxOnly | fl PrimarySMTPAddress, LitigationHoldEnabled, LitigationHoldDuration, SKUAssigned, IsInactiveMailbox

The result should be similar to:

PrimarySmtpAddress : David@contoso.com
LitigationHoldEnabled : True
LitigationHoldDuration : Unlimited
SKUAssigned : False
IsInactiveMailbox : True

References; additional information / more details on:

Thanks to Mark Johnson, Nino Bilic and Murali Natarajan for their support and contribution to this blog post!

Cristian Dimofte

Comments (20)

  1. Coert K says:

    Is there a good reason to choose Litigation Hold instead of an organization-wide retention policy? We use an automatically assigned retention policy so the first two steps are not needed and every deleted user’s mailbox is accessible.

    1. @Coert K, the answer can be found on https://docs.microsoft.com/en-us/office365/securitycompliance/create-and-manage-inactive-mailboxes:
      “A mailbox becomes inactive when a Litigation Hold or an Office 365 retention policy (created in the Office 365 Security & Compliance Center) is applied to the mailbox before the corresponding Office 365 user account is deleted.”

      It is up to you which one is most suitable for you to use. Even so, if you’ll use Organization-Wide Retention policies from Security & Compliance do not exclude the double-check that you have to take, in order to ensure that the MBX in question is under the governance of that policy, and is not excluded from it.
      More details about this on https://docs.microsoft.com/en-us/office365/securitycompliance/identify-a-hold-on-an-exchange-online-mailbox:

      Excluded from an organization-wide Office 365 retention policy
      -mbxe9b52bf7ab3b46a286308ecb29624696
      If a mailbox is excluded from an organization-wide Office 365 retention policy, the GUID for the retention policy the mailbox is excluded from is displayed in the InPlaceHolds property and is identified by the -mbx prefix.

  2. Are there any advantages in making the mailbox inactive vs converting the mailbox to shared?

    I think when the mailbox is inactive you cannot gain access without first attaching it or restoring it elsewhere.

    Where as a shared mailbox you can access via RBAC & you also get to free up your license.

    1. @Steve_Lindsey – Shared mailboxes have a 50GB limit vs 100GB limit for regular user mailboxes (disabled or not). Shared mailboxes can still be used to send and receive email by users who have been given full access. Unlicensed or deleted users with mailboxes on lit hold cannot be accessed by anyone except those with Discovery Management rights.

      1. @Jeff ==> a 100GB mailbox converted to a Shared keeps its mailbox limits + nowadays, SharedMailboxes are 100 GB, no longer 50GB. At least in a few customer Tenants I have access to – and as far as I can tell.
        A Shared isn’t a so bad solution, easier to manage for some people and doesn’t require E3+ or Exchange Online Archiving.

        1. @Benoit, the following article will provide a better overview on the things that you know about shared mailboxes:
          https://blogs.technet.microsoft.com/exchange/2018/06/21/correcting-shared-mailbox-provisioning-and-sizing/

          Answering to you affirmation, with few words, there were cases in which Microsoft provisioned Shared MBXes with 100 GB in size. Microsoft corrected this, and, if a Shared MBX has more than 50 GB in size, it has to have a proper license assigned to it.
          Also, on the following article you can find more details about Archive MBXes attached to Shared MBXes:
          https://docs.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits#storage-limits-across-office-365-options

          Shared mailboxes don’t require a separate license. However, without a license, shared mailboxes are limited to 50 GB. To increase the mailbox size, an E3 or E5 license must be assigned. This will increase the mailbox to 100 GB. If you want to enable the archive mailbox or put a Litigation Hold on a shared mailbox, then an Exchange Online Plan 2 license or an Exchange Online Plan 1 with Exchange Online Archiving license is required. If you enable the archive mailbox and auto-expanding archiving for a shared mailbox, additional storage is automatically added when the 100 GB storage capacity for the archive mailbox is reached.

          1. Oh yes I remember now! Thanks for the refresher.

      2. I agree with Jeff in this, but, I would like to enter in some more details on this topic.
        You have to understand the pros and cons for both scenarios. Below I’ll try to provide few of them (might be others, as well):

        Shared Mailbox:
        Pros:
        – The content of the mailbox can be used at any certain point in time, directly, from clients like Outlook/OWA;
        – The mail-flow is still functional. So, in case you still want to receive or send emails from this MBX, you can do it;
        – If the MBX is not bigger than 50 GB in size, if you do not have an Archive mbx attached to it, and you do not need to use Hold related features on it, no Exchange Online licenses need to be assigned to it.

        Cons:
        – If the Primary MBX has more than 50 GB in size, if it has an Archive attached to it or if you want to benefit of the Hold features, a proper license has to be assigned to it;
        – The MBX might still be visible in GAL

        Inactive Mailbox:
        Pros:
        – The mail-flow to this MBX will not work anymore;
        – Doesn’t matter the size of the mailbox, or if it had an Archive MBX attached to it, or not (properly licensed at the time the MBX was moved into the Inactive state), the entire content (Primary MBX, Archive MBX, AUXArchives) will be retained until the time the hold will expire, without a need to have a license assigned (this is something that may change in the future, but, at this time, there is no cost attached to an Inactive mailbox).

        Cons:
        – The content of the mailbox is available only through eDiscovery searches;

  3. Mike Crowley says:

    The UI (PowerShell) states that it may take an hour to kick-in, so we’ve always measured this time window before removing an account (such as moving to the cloud immediately before off-boarding). Can we ignore that 60 minute warning/SLA and rely only on LitigationHoldEnabled?

    Also, yes, as Coert K said, Microsoft has recommended we use retention policies in the security and compliance center instead, so please discuss the recommended best practices with these policies as well.

    1. Policies are Best Practice but a pain to manage with automation. There is still a requirement to split bunches of 10K users (was 5K before) across policies. I use a modulus on the Guid’s HashCode to provide as much as randomness and balance as possible.

      Indeed, LegalHold is far easier to manage however it’s the old-school way to do it (and the question is why is the Exchange Team recommending a legacy pathinstead of the a modern path :))

      1. Even if you wouldn’t have a message like that (wait for 60 minutes), you have to understand that Exchange Online is a huge environment, in which replication of settings may not be done instantly. Because of this, even if you are not informed that you have to wait, as a best practice my advice will be to wait.

        Related to the question about which Hold option should be recommended (legacy from Exchange Online, or new ones from Security & Compliance), indeed, Microsoft recommends the new ones. Even so, it is up to you (until the time you’ll be forced to use just the new ones) which one is most suitable for you, when speaking about moving a mailbox into the Inactive state.

  4. MichaelGun says:

    When being in hybrid mode with AAD connect. Could we achieve the same thing when moving the AD account to an OU that is not synced to O365 instead of removing the AD account?

    1. Hybrid or just sync’d identities, you can. However you’ll need to ensure the Mailbox has been put in Legal Hold before (and therefore have E3+ or ExO Archiving license assigned before). Filtering is a convenient way to remove in AAD w/ providing a fast way to recover. Your AD become a 1st level of tombstone and you can recover easily before 30 days (after this delay, a moving back to synce’d OU will only create a fresh new user).

    2. I agree with Benoit on this.
      So, the first checks, that will confirm you the MBX is on Hold, have to be done. When you have this confirmation, in order to soft-delete the MSODS / Azure AD user (move it into Deleted Users view), you can remove the On-Premises AD user (or, at least to remove if from the AADConnect sync scope).

    3. Please see my companion article, How to work with Inactive Mailboxes in a Hybrid Environment. http://www.expta.com/2019/01/how-to-work-with-inactive-mailboxes-in.html

    1. You should maybe update the guidance on Shared Mailboxes since the *-RemoteMailbox cmdlets now accordingly deal with the -Type Shared parameter/value. No longer needed to fiddle AD attribute.

      1. @Benoit, you are right, but, not totally right.
        The “-Type Shared” can be used on the *-RemoteMailbox just for specific versions of Exchange (Exchange 2013 CU21 or later and Exchange 2016 CU10 or later).

        More details on:
        https://support.microsoft.com/en-us/help/4133605/cmdlets-to-create-modify-remote-shared-mailbox-in-on-premises-exchange
        https://docs.microsoft.com/en-us/powershell/module/exchange/federation-and-hybrid/set-remotemailbox?view=exchange-ps

        In case customer’s environment is on Exchange 2010, or unsupported versions of Exchange 2013/2016, we recommend what Jeff mentioned in his blog. More details on https://support.microsoft.com/en-us/help/2710029/shared-mailboxes-are-unexpectedly-converted-to-user-mailboxes-after-di, but, in this situation, the steps provided by Jeff are right and enough. Different than the Microsoft official article, Jeff mentioned, as well, to disable the On-Premises AD object’s account, as this is now a RemoteSharedMailbox/SharedMailbox, and the AD account of it should not be active, like for the RemoteUserMailbox/UserMailbox object.

  5. Thanks, that’s a good step by step guide. Now the second part of this blog is in order! :)
    How to work with users who returned and now need to reactivate their license and get their account and mailbox back.
    No I am not kidding. It’s a typical task at many customers (think medical or research institutions where doctors or researchers come to work for a year or two, then leave to another institution, then come back).
    We have had to develop this process for my customer.

    1. Hi Boris,

      Thanks for asking!
      If the MSOLUser still exists (this means that the date on which you moved the MBX to Inactive state is less than 30 days ago), you should restore it, assign an EXO license and the magic will happen.

      If the MSOLUser do not exist anymore (soft-deleted more than 30 days ago, or manually hard-deleted), the answer to your question is documented on:
      – Recover — https://docs.microsoft.com/en-us/office365/securitycompliance/recover-an-inactive-mailbox
      – Restore — https://docs.microsoft.com/en-us/office365/securitycompliance/restore-an-inactive-mailbox

      My recommendation will be to try first with the recover option (New-Mailbox -InactiveMailbox). In the situation in which customer is in Hybrid, they should do the recover, and after that do a Hard-Match of the MSODS user with the On-Prem user (set the correct ImmutableID on the MSODS user), and just after that sync the user from On-Prem, using AADConnect tool.

      If the recover will not work, you should try the restore one (New-MailboxRestoreRequest). In the situation in which customer is in Hybrid, I assume that the steps that they are taking are: create the On-Prem user (enabled as RemoteMailbox), sync it to MSODS (this will create the new MBX in EXO), restore the content of the old MBX to the new one (using New-MailboxRestoreRequest command)

      Even so, based on the customer needs, it is up to them which method will use to reaccess data from the old mailbox (recover or restore).

Skip to main content