Updated retention settings for the Recoverable items subtree

As part of Message center post MC288630, Microsoft just announced plans to update the retention settings for some of the folders you can find under the Recoverable Items subtree. Specifically, the retention duration for the Purges, DiscoveryHolds and Versions folders will be set to “1 day”, with the action remaining “Move to archive”. Those of you that are familiar with retention settings in Exchange Online might recall that there is a 7-day workcycle for the MRM to do its job, so the change mentioned here likely leverages the improvements made to the service to ensure faster processing of Teams records.

Few things in the announcement are a bit misleading or unclear, so I’ll try my best to interpret them here. First, the title of the message center post specifically mentions auto-expanding archives, thus leaving the impression that this change might only be applicable to mailboxes with auto-expanding archives. I’d wager that this is not the case, and instead it will be applied to all mailboxes instead. Any mailboxes that have no archive enabled will simply ignore the policy, much like they currently do for the default “Recoverable Items 14 days move to archive” tag.

Interestingly, the announcement does not mention SubstrateHolds, one of the folders you can find under the RecoverableItems subtree. The folder is used to retain copies of Teams chat messages and is governed by separate controls now, and seems to be excluded from any “move to archive” workflows. Back in the day though, this was not the case, and for my own mailbox for example, a handful of Teams chat entries can be found in the Recoverable Items\SubstrateHolds folder of the archive mailbox. Other folders that are not affected by this change include the Audits one (governed by a separate property, AuditLogAgeLimit), the Calendar Logging one (90-ish days, can be toggled off via the CalendarVersionStoreDisabled parameter), as well as the Deletions folder (14-30 days, configurable via RetainDeletedItemsFor parameter).

Next, the message center post mentions something along the lines of “the existing archiving policies you have created for these folders”. Thing is, we have never been able to create tags for those specific folders. The only Recoverable Items tag we are able to configure is the “top level” one, and we can only set a “Move to archive” values for it. While subfolders generally inherit the parent folder tag, many of the folders found within the Recoverable items subtree have their own retention settings that can be controlled by various mailbox-level settings, such as toggling Single item recovery or modifying the RetainDeletedItemsFor value. None of these are configurable via actual “tags” though. Thus, one can argue that the statement quoted above is a bit misleading.

The message center post goes to mention that existing policies affecting the three folders (Purges, Versions, DiscoveryHolds) will be ignored going forward. Microsoft already did something similar with the Deleted items folder back in the day, although we were given some workarounds in case we wanted to keep the old default of 30 days soft-delete, or modify it per our needs. No such workarounds are mentioned for the three Recoverable Items subfolders. This in turn begs the question what will happen with the good old SingleItemRecoveryEnabled toggle, will we be allowed to disable the feature going forward, or will a “1 day move to archive” policy always be in effect.

Overall, the changes mentioned in MC288630 leave few unanswered questions, which will hopefully be clarified going forward. As to why Microsoft is introducing this change, that’s also unclear. Sure, they can take advantage of the new, shorter MRM workcycle, but 14 days are hardly enough time for even the busiest mailboxes to amass that big of a volume within the main mailbox RecoverableItems subtree. Questions, questions…

UPDATE 05/10/2021: As suspected, the changes detailed in MC288630 apply to all mailboxes with archives enabled, and not just auto-expanding archives as the title might have you believe.

UPDATE 15/11/2021: Apparently I wasn’t the only one getting a bit confused about the announcement above, as Microsoft has since updated it several times. Here’s how the current version of the message center post looks like:

MC288630

Leave a Reply

Your email address will not be published. Required fields are marked *

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