RetentionHoldEnabled Inconsistency

I ran into an issue today where we discovered that a subset of our users with mailboxes that had been migrated to Office 365 had Retention Hold enabled on their mailboxes – what was strange about this was that we hadn’t set this at all during our migration, and it seemed to be randomly applied to about 30% of the mailboxes.

You can check this setting with the following command:

[powershell gutter=”false”]Get-Mailbox -ResultSize unlimited | Where-Object {$_.RetentionHoldEnabled -eq $true} | Format-Table Name,RetentionPolicy,RetentionHoldEnabled –Auto[/powershell]

With this result:


Looking through the list of users, there was a mixture of E1 and E3 licenses, but no K1 licenses or shared mailboxes. This made sense, as K1s and shared mailboxes didn’t have archiving enabled.

It’s important to note that Retention Hold is not the same as Litigation Hold – Litigation Hold puts a change freeze on a mailbox so that a user can’t delete or change items in their mailbox. It generally happens behind the scenes, and most users don’t notice that their mailbox has litigation hold applied, as deleted items disappear as normal, and the deletions/changes end up in a separate folder that the user cannot see.

Retention Hold, on the other hand, prevents the Managed Folder Assistant from running on that mailbox and processing retention tags. This means that users with Retention Hold enabled will not have their emails archiving or deleting based on the policies that have been set up in their Retention Policy.

After looking around a bit, I began to notice a pattern – each of the users who had their RetentionHold set to Enabled were users that we had been importing PST files into their online archives using the Office 365 Import Service. We had already noticed a bug (and opened a ticket), because we were not able to manually delete the jobs, and they weren’t automatically being deleted after 30 days the way they’re supposed to be.

It seems like Retention Hold is being enabled when a PST import job starts, and the flag is not being cleared automatically because the jobs are not being deleted properly.

You can fix this on a single mailbox by running the following command:

[powershell gutter=”false”]Set-Mailbox -RetentionHoldEnabled $false[/powershell]

Alternately, if you want to run this for all affected mailboxes, here’s the command to use:

[powershell gutter=”false”]Get-Mailbox -ResultSize unlimited | Where-Object {$_.RetentionHoldEnabled -eq $true} | Set-Mailbox -RetentionHoldEnabled $false[/powershell]

Hopefully Microsoft will get this bug resolved soon so that we have better control over the PST Import service – in the meantime, you can use this script to get retention policies functioning properly again.

Hope this helps!

6 thoughts on “RetentionHoldEnabled Inconsistency

  1. Hi Jeremy,

    Thanks for this post. We noticed the same sporadic behaviour on mailbox during a migration.




  2. its now 2018 and the bug STILL exists. On phone with Microsoft they were adamant that it must be another admin at the company that has enabled the RetentionHoldEnabled via PowreShell!!! Makes sense that people imported this week sometimes now have RetentionHoldEnabled set to True.

    you can fix each with this:

    Get-Mailbox -Identity | Fl *retention*
    Set-Mailbox -Identity -RetentionHoldEnabled $False
    Start-ManagedFolderAssistant -Identity


    1. Thanks Craig, that’s a good tip! If you don’t manually start the Managed Folder Assistant, it’ll run automatically every 7 days – that said, I always love being able to make things happen on MY time, and that’s exactly how you’d do it. 😀


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.