Make sure Deleted items are automatically removed from Microsoft 365 mailboxes

In another “forgotten knowledge” topic, let’s discuss how to automatically clean up/remove items from the Deleted items folder in Exchange Online/Microsoft 365. Nothing has changed in this process for years now, but it looks like people online are still having a hard time finding proper instructions on how to configure a solution for this scenario. A quick search reveals that most articles incorrectly talk about the RetainDeletedItemsFor property, which does NOT relate to the Deleted items folder. Others relay incorrect instructions and fail to reflect the changes Microsoft made back in 2015. So, in this article I will try to provide you with a end to end solution that will help you solve the “Deleted items are kept forever” issue. But first, an introduction to retention tags and policies in Exchange, and a history lesson 🙂

Crash course in Exchange Online retention

To understand how what changes are needed, you need a basic understanding of retention policies and retention tags in Exchange Online. The documentation does a good job in detailing this topic, so I will just give you the short version: think of retention tags as “labels” that can be assigned to items or folders within your mailbox. The settings of the retention tag dictate the “expiration” date for an item and the action to be taken upon reaching said date. In turn, the set of retention tags is packaged within a retention policy, which is then assigned to mailboxes. A policy can be designated as “default”, meaning each newly created mailbox within the organization gets the policy assigned to it.

Now, an important note is due here. Retention tags and policies in Exchange Online are not the same thing as Retention labels and policies in Microsoft 365. In fact, one can argue that retention tags and policies in Exchange Online have nothing to do with actual retention, as they cannot be used to guarantee preservation of items for compliance purposes. Instead, they are used to either delete items or move them to the Online archive (if such is present). In turn, some of the features supported by (the now called “legacy”) Exchange retention tags and policies are not supported by their “modern” counterparts, so both continue to be used side by side. The important thing to understand here is that for the scenario at hand, we need to use “legacy” Exchange retention tags.

But I digress. Apart from understanding what retention tags and policies are, you need to also understand how retention age is calculated, as well as some additional details, all of which you can find in the documentation articles cited here and the references therein. Another important thing to understand when it comes to processing Deleted items in Exchange Online is how the Recoverable Items subtree works. With this knowledge at hand, you will be able to better understand the role of the Deleted items folder, as well as why most articles online that talk about “Deleted items” retention mean something different altogether.

A short history lesson

So, assuming we know how Exchange Online retention works, coming up with a solution that will periodically clean up the Deleted items folder doesn’t seem like a hard task, right? All we need to do is create a Deleted items tag with the desired action/period and assign it to our user via retention policy. So why am I bothering you will yet another wall of text?

You see, back when Exchange Online/Office 365 first launched, the Deleted items folder behaved differently. Thanks to the presence of a folder-specific Deleted items retention tag within the Default MRM Policy, items moved to the Deleted items folder were automatically removed after 30 days. Apparently, this behavior puzzled some users and resulted in a number of support cases opened, which prompted Microsoft to take action.

The action was not to educate users or admins, but “solve” the issue altogether, by removing the Deleted items tag from the Default MRM Policy across all tenants, effectively halting processing of every item held within the folder. Put another way, Microsoft’s “solution” was to ensure items in the Deleted items folder are kept FOREVER. Tenants were given a month to rename their default policy or create/apply a custom one, should they want to keep the existing behavior.

The rest is history, or the lack of it, as for years this change was not mentioned anywhere in the documentation. In fact, the only place you could find it was the original article over at the Microsoft blog, and we all know how many admins keep current on that. After numerous nags, we finally got Microsoft to update the documentation with the following note:

The Default MRM Policy doesn’t include a default tag to automatically delete content from the Deleted items folder as per Extended email retention for deleted items in Office 365. If you want to apply the 30-day retention or set a custom retention period, that can be done by adding an appropriate retention tag for deleted items folder to the Default MRM Policy.

Today, a folder-specific Deleted items tag with 30 days retention period and a Delete action is still present (created by default) in every tenant. However, the tag is not assigned to the Default MRM policy, effectively enforcing what Microsoft says is the desired behavior. To confirm this, open the Compliance center > Data lifecycle management > Exchange (legacy) page and check both the MRM retention tags and MRM retention policies tabs. Alternatively, use PowerShell:

C:\> Get-RetentionPolicyTag -Types DeletedItems | ft Id,Type,RetentionEnabled,RetentionAction,AgeLimitForRetention,TriggerForRetention

Id Type RetentionEnabled RetentionAction AgeLimitForRetention TriggerForRetention
-- ---- ---------------- --------------- -------------------- -------------------
Deleted Items DeletedItems True DeleteAndAllowRecovery 30.00:00:00 WhenDelivered

C:\> Get-RetentionPolicy | ? {$_.RetentionPolicyTagLinks -match (Get-RetentionPolicyTag -Types DeletedItems).Id}

C:\> Get-RetentionPolicy | ft Name,IsDefault,RetentionPolicyTagLinks -Wrap

Name IsDefault RetentionPolicyTagLinks
---- --------- -----------------------
ArbitrationMailbox False {Never Delete, AsyncOperationNotification, ModeratedRecipients, AutoGroup}
Default MRM Policy True {5 Year Delete, 1 Year Delete, 6 Month Delete, Personal 5 year move to archive, 1 Month Delete, 1 Week Delete, Personal never move to archive, Personal 1 year move to
archive, Default 2 year move to archive, Junk Email, Recoverable Items 14 days move to archive, Never Delete}

The cmdlets above were run against a fresh demo tenant, and their output shows us that a retention tag of type DeletedItems does exists. However, the tag is not assigned to the Default MRM Policy, and thus not in effect. In fact, you cannot assign it to the Default MRM Policy even if you try – the operation is simply ignored. No documentation article tells you about this! The behavior only applies to the “default” Deleted items retention tag, which you can identify by its RetentionId value of 05d4c642-352c-4228-ad32-6d4d1e9a77c1. And herein lies the significance of that “appropriate” adjective from above. If you create a different Deleted items tags, you will be able to add it to the Default MRM policy with no issues.

Solution #1: Use same retention settings for all users

Let’s summarize the important points from the above sections. We now know that a Default MRM policy exists in each tenant, however said policy does not include a Deleted items tag. Moreover, you cannot add the “default” Deleted items retention tag (the one with RetentionId value of 05d4c642-352c-4228-ad32-6d4d1e9a77c1) to the Default MRM policy. Instead, you can either create a new Deleted items tags, or create a custom retention policy.

If you want to use the same retention settings across your entire user base, the first option is easier. The only caveat here is that you cannot create a tag with the same name as another tag, though nothing is stopping you from naming it “Deleted items 30 days” or similar. And if you really really want to use the simpler “Deleted items” name, you can simply remove the default tag of same name – in most cases it will not be in use anyway.

If you decided to create a new retention tag, you can do so by using either PowerShell or the UI. For example, the cmdlet below will create a new retention tag of type DeletedItems and set the retention age to 7 days. The default action will be used, which is to delete the item and allow recovery (in other words, move the item to the Deletions folder).

New-RetentionPolicyTag -Name "Deleted items 7 days" -Type DeletedItems -AgeLimitForRetention 7 -RetentionAction DeleteAndAllowRecovery

Name Type Description
---- ---- -----------
Deleted items 7 days DeletedItems Managed Content Settings

Alternatively, you can create the tag by going to the Compliance center > Data lifecycle management > Exchange (legacy) page and selecting the MRM retention tags tab. Hit the New tag button and follow the prompts of the Create a retention tag wizard. On the first page, enter a Name and an optional Description for your tag. Do note that just like M365 retention tags, you are not allowed to have Exchange retention tags with duplicate names. Of course, it makes sense to use proper names for your tags, or at least add the appropriate description.

On the next page, we configure the type of the tag. In our scenario, this would be a folder-specific tag, so we select the Automatically to default folder option, then select Deleted items from the Apply tag to this folder picker control. Next, we set the Retention period to the desired value (in days), and select the desired Retention action. Stick to the default Delete and allow recovery value here. Next, review the choices and if everything checks out, hit the Submit button to create the tag.

After you have made sure that an appropriate Deleted items tag exists, it’s time to assign it to users. To do that, we need to assign it to a retention policy, which in turn is assigned to the user’s mailbox. If you want to enable Deleted items processing for all of your users, the easiest way is to add the Deleted items tag to the default MRM policy within the organization. To do this via PowerShell, you can use the following cmdlets:

#Get the default retention policy
$policy = Get-RetentionPolicy | ? {$_.IsDefault}

#Add Deleted items tag
$policy.RetentionPolicyTagLinks += "Deleted items"

#Update the policy tags
Set-RetentionPolicy $policy.Id -RetentionPolicyTagLinks $policy.RetentionPolicyTagLinks

In effect, the default retention policy will now include a Deleted items tag and will soon start processing items in the Deleted items folder as dictated by the tag’s settings. Of course, the same operation can also be performed via the UI (see example in the next section if you need more detailed instructions).

IMPORTANT NOTE: The above method will only work against custom-created Deleted items retention tags. As mentioned few times already, Exchange Online will ignore any attempt for adding the “default” Deleted items retention tag to the Default MRM policy. Even though both PowerShell and the UI will signal a correct execution of the operation, no actual changes will be committed!

Solution #2: Use multiple retention policies

If you want to apply different retention settings to different groups of users within your organization, or simply don’t want to mess with the Default MRM policy, the second solution comes in play. Namely, create (one or more) additional retention policies, ensure the relevant Deleted items tags is added as appropriate and assign the policy to your users. This method has the added benefit of allowing you to leverage the “default” Deleted items tag, as Microsoft will not prevent you from adding it you any custom created retention policy (only the Default MRM policy is affected).

To leverage this solution, ensure that you have the appropriate set of retention tags created. If needed, use the examples from the previous section to create additional retention tags. Once you are satisfied with the set of retention tags available for assignment, it’s time to create a new retention policy. As usual, we can do this either via PowerShell or the UI. Below is simple PowerShell-based example:

New-RetentionPolicy -Name "MRM policy with Deleted items processing" -RetentionPolicyTagLinks "Deleted items","Recoverable Items 14 days move to archive","Junk email","Default 2 year move to archive"

As you need to list each tag individually, creating the policy via the UI is much easier. To do so, navigate to the Compliance center > Data lifecycle management > Exchange (legacy) page and selecting the MRM retention policies tab. Hit the New policy button, then enter a Name for your policy. Hit the Add tag button and add one or more retention tags as needed, including the desired Deleted items tag. You can refer to the official documentation for more details.

Once the new retention policy is created, you need to assign it to your users. Optionally, you can set this policy as the default one. The examples below show how you can achieve this via PowerShell:

#Assign the policy based on group membership
Get-DistributionGroupMember "Sales Team" | ? {$_.RecipientTypeDetails -eq "UserMailbox"} | Set-Mailbox -RetentionPolicy "MRM policy with Deleted items processing"

#Assign the policy based on Department attribute
Get-User -Filter {Department -eq "Marketing" -and RecipientTypeDetails -eq "UserMailbox"} | Set-Mailbox -RetentionPolicy "MRM policy with Deleted items processing"

#Set the policy as default
Set-RetentionPolicy "MRM policy with Deleted items processing" -IsDefault:$true -Confirm:$false

Rinse and repeat the process for any additional retention policy you might need to create and assign. If you need specific instructions on how to perform the same operations via the UI, refer to the official documentation.

Verifying the solution

After creating a retention policy with the desired Deleted items tag and assigning it to your users, your job is done. It will take some time for Exchange Online to process the changes, as the corresponding MRM assistant runs on a 7-day lifecycle. You can use the Start-ManagedFolderAssistant cmdlet to “signal” the assistant to process a given mailbox, but there is no guarantee that processing will actually happen before hitting the SLA limit. But at some point, users will start noticing items disappearing from the Deleted items folder.

Now, another common misconception revolves around item expiration. Without going into too many details, the “standard” scenario in Exchange Online is as follows: Items get stamped with the Deleted items retention tag once they get moved to the folder (in other words, once the user deletes them) and are kept in the folder for the defined tag duration. This behavior (as illustrated on the screenshot below) is enforced by the fact that there is no default tag with the “delete” action in Exchange Online, thus the PR_RETENTION_DATE flag is first calculated when the item gets moved to the Deleted items folder. If a tag with the “delete” action was applied to the item beforehand, the date of delivery/creation is used instead, which can cause items to be removed sooner than the period specified by the Deleted items tag. Refer to the official documentation for more details.

If you want to make sure that the Deleted items tag is play, open an item within the Deleted items folder and look for the retention info tip. Note that some items that have recently been moved to the folder might not yet display an expiration value – remember that 7-day processing SLA we mentioned earlier. That same SLA is the reason why you cannot realistically have a working “1 day delete” tag within Exchange Online (which does not mean you cannot create such).

In any case, if you are having trouble with any of the solutions outlined above, you can use the steps in this article for the initial troubleshooting. More detailed explanations can be found in Tony’s Exchange Inside Out books, and hopefully, in a soon-to-be-published article by him 🙂

Summary

In summary, this article addresses some of the “lost knowledge” and common misconceptions around the workings of the Deleted items retention tag within Exchange Online. Stemming from some changes Microsoft made back in 2015, some confusing statements and outright wrong instructions are circulating the web, so my hope is that this article will help people find a proper solution for the “automatically delete items in the Deleted items folder” conundrum. Which in turn should help keep the folder to a manageable size!

Of course, there’s much more we can discuss when it comes to retention policies and retention tags. For example I haven’t even mentioned the possibility of using personal retention tags and applying them programmatically to the Deleted items folder. But that’s just an overkill for this scenario. And while this article grew to be way larger than expected, I hope it illustrates that the process you need to follow in order to make sure that Deleted items will be processed as desired is actually relatively simply. And, configuring this is usually a one-time operation, so don’t be scared!

 

P.S. Forgot to mention that renaming the Default MRM policy will also allow you to include the “default” Deleted items tag in it. It is of course the easiest solution, but I needed an excuse to explain the process of creating a retention tag. So if you made it this far, here’s the bonus solution!

Solution #3: Rename the Default MRM policy

Similar to #1, this is appropriate for scenarios where you want all your users to have the same settings. The setup is a bit simpler though, as we have no need to create any new retention tags. Instead, renaming the Default MRM policy will allow us to add the “default” Deleted items tag, and we’re in business. Here’s the PowerShell for it:

#Get the default retention policy
$policy = Get-RetentionPolicy "Default MRM Policy"

#Rename it
Set-RetentionPolicy $policy.Guid -Name "MRM Policy"

#Add Deleted items tag
$policy.RetentionPolicyTagLinks += "Deleted items" 

#Update the policy tags
Set-RetentionPolicy $policy.Guid -RetentionPolicyTagLinks $policy.RetentionPolicyTagLinks