Enabling litigation hold on an Exchange Online mailbox fails because of invalid license

A query came up about not being able to activate Litigation hold on a (shared) mailbox in Exchange Online. While the there have not been any changes in the process of enabling a hold on a mailbox, we did get a change in the provisioning behavior for shared mailboxes few years back, and more recently, the “license stacking” feature. Or in other words, I simply needed a reason to bore you with some details 🙂

First things first. Litigation hold has always been a “premium” functionality and one that requires the Exchange Online Plan 2 service plan, or any equivalent license. While Microsoft does not always enforce licensing requirements in code, this is not to say that you can just use any feature you like, for free. In other words, even if you had the option to enable litigation hold without the needed license, doing so puts you in a license terms violation.

For putting a mailbox on litigation hold, Exchange Online does perform a check. This is what the error message tells you:

The action ‘Set-Mailbox’, ‘LitigationHoldEnabled’, can’t be performed on the user ‘UserXXX’. Your Microsoft Exchange Online license doesn’t permit you to put a litigation hold on this mailbox.

In technical terms, the check is performed against the “capabilities” made available to the user (or mailbox) via any licenses assigned, as represented via the PersistedCapabilities property. Nothing new here, as even back in 2015 we used a filter on said property to quickly list all mailboxes eligible for the hold functionality. Specifically, we used a filter against the value of BPOS_S_Enterprise (corresponding to Exchange Online Plan 2):

#List all mailboxes eligible for Litigation hold
Get-Mailbox -RecipientTypeDetails UserMailbox -Filter {PersistedCapabilities -eq "BPOS_S_Enterprise"}

#List all mailboxes eligible for Litigation hold that do not currently have hold enabled
Get-Mailbox -RecipientTypeDetails UserMailbox -Filter {PersistedCapabilities -eq "BPOS_S_Enterprise" -and LitigationHoldEnabled -ne $true}

Any mailbox object returned by the above cmdlets is eligible for Litigation hold, and you should have no issues enabling that. In contrast, if the mailbox is not returned, you will not be able to toggle the feature on (see examples below). The solution for most such cases is quite simple – you will need to assign a licenses that includes the Exchange Online Plan 2 service plan. Give it some time to replicate, and try again.

On a side note, the SKUAssigned property is not a correct representation of any (Exchange Online) licenses assigned to the user. Even if it was, it does not only reflect the Exchange Online Plan 2, so it is not a good choice here.

OK, not that we got this out of the way, are you ready for some more details, which you will probably never need? Let’s start with the way mailboxes are provisioned in the service. In a nutshell, each tenant has a set of mailbox plans available, which in turn govern the set features and limits applied on newly provisioned mailboxes. Back in the day, Microsoft used the “most superior” mailbox plan for provisioning shared mailboxes, which for Enterprise customers meant that shared mailboxes can grow up to 100GB and have features such as Online Archive and litigation hold enabled out of the box.

At the same time, the official documentation pointed out the actual licensing requirements, for shared mailboxes included. A freebie is not something we usually get out of Microsoft, so this all changed back in 2018, with the “correction” of the shared mailbox provisioning process. In practice, this meant that newly provisioned shared mailboxes now use the “standard” plan, instead of the Enterprise one, which in turn meant that you could no longer enable archive or put them under litigation hold (without assigning additional licenses, that is).

The changes however did not affect existing mailboxes, likely because Microsoft did not want to deal with potential data loss scenarios. In effect, it is not that uncommon to see (unlicensed) shared mailboxes that can still be enabled for litigation hold. In all cases though, the requirement to have the PersistedCapabilities property value set to BPOS_S_Enterprise remains valid. Here are some examples that illustrate this:

#Mailboxes with PersistedCapabilities of BPOS_S_Enterprise can have Litigation hold enabled
Get-Mailbox -RecipientTypeDetails SharedMailbox -Filter {PersistedCapabilities -eq "BPOS_S_Enterprise"} | select -First 1 | Set-Mailbox -LitigationHoldEnabled $true -WhatIf

#The above applies even if the SKUAssigned doesn't say "True"
Get-Mailbox -RecipientTypeDetails SharedMailbox -Filter {PersistedCapabilities -eq "BPOS_S_Enterprise" -and SKUAssigned -ne $true} | select -First 1 | Set-Mailbox -LitigationHoldEnabled $true -WhatIf

Both examples should return any “eligible” mailboxes and will try to doubly confirm this by running the Set-Mailbox cmdlet in test mode (via the -WhatIf switch) against the first one. Mailboxes that do not have the PersistedCapabilities property value set to BPOS_S_Enterprise cannot have litigation hold enabled. While all the examples provided thus far are for shared mailboxes, the last statement holds true regardless of the mailbox type. The screenshot below should hopefully illustrate all that we covered thus far:

Get-Mailbox -Filter {PersistedCapabilities -ne "BPOS_S_Enterprise"} | select -First 1 | Set-Mailbox -LitigationHoldEnabled $true -WhatIf

Another licensing related change that has some potential impact here is the so-called license stacking, introduced in 2023. In a nutshell, this allows you to apply multiple Exchange Online licenses to a user. On the backend, this is “translated” into the introduction of the RootCapabilities property, a multi-valued one, listing each individual Exchange “capability” assigned to the user. The property is available for all recipient types, not just mailboxes and is therefore exposed via the Get-Recipient cmdlet.

The example below illustrates how you can leverage the RootCapabilities property for our scenario. As the litigation hold feature only affects mailboxes, we can continue relying on the Get-Mailbox cmdlet, but can complement its output:

Get-Mailbox -Filter {PersistedCapabilities -eq "BPOS_S_Enterprise"} | ft Name, SKUAssigned, @{n="RootCapabilities";e={(Get-Recipient $_.UserPrincipalName).RootCapabilities}},PersistedCapabilities -AutoSize

Two issues prevent us from using the RootCapabilities property for our use case. First, as you can see from the screenshot above, the property is not reliable, much like the SKUAssigned one. Since it’s a fairly recent addition, only objects that have been provisioned since the summer of 2023, or have had license changes since, will have a proper value. This however is the smallest of two issues. The big one is that we cannot filter based on its values, as neither the –RecipientPreviewFilter nor the –Filter parameters recognized it as valid filterable property. Shame.

So, we’re back to the beginning then. Even in 2025, the best way to determine which mailboxes can be enabled for litigation hold remains a filter against the good old PersistedCapabilities property.