When it comes to meeting compliance needs within Microsoft 365 and particularly within Exchange Online, it is not that uncommon to have the entire content of a mailbox preserved for an extended period of time. There are in fact multiple ways you can go about this, from the good old Litigation hold controls, to “modern” retention labels and policies and (premium) eDiscovery case holds. And, we also have support for the FINRA/SEC Rule 17a-4 and similar, thanks to record labels and the preservation lock feature.

In reality, the majority of content held within a mailbox can be irrelevant to potential legal enquiry, but instead of switching to more targeted retention many organizations prefer the “better safe than sorry” approach. Nothing wrong with that, and Microsoft will happily accept any data you’re willing to ingest into mailboxes, including data from third-party apps. All is fine and dandy, until you inevitably arrive at a situation where you need to remove some data, either because it represents a privacy or security risk, your compliance needs changed, or you simply need to free up some storage.

The way you would go about addressing such scenarios is detailed in the following article. In a nutshell, one would disable any holds affecting the mailbox as well as the single item recovery and delay hold features, then go about deleting the items in question and finally, re-enable holds and the aforementioned features. It’s not a pleasant experience, but it’s doable. Until you run into a scenario that involves a preservation lock. Or you inadvertently cause additional items to be removed (lost forever).

To address the need for removing items on hold, and put some structure around the process, Microsoft is introducing the Priority cleanup feature. It’s a clever implementation that takes advantage of existing functionalities, comes with an easy to use UI and ensures that functionalities such as record labels are respected. And, Microsoft is including this in the Office 365 E5 or equivalent SKUs featuring the “compliance” bits, instead of introducing yet another SKU/add-on. Here’s a quote from Microsoft introducing the feature:

Priority cleanup is a new feature that offers a safe and secure way to permanently delete content from Exchange Online mailboxes even when subject to retention policies, retention labels, and eDiscovery holds, by dynamically requiring multiple levels of approval based on retention/holds that apply to the item.

Before we dig deeper, one thing needs to be said. There are obvious implications for a feature like this, which range from “I made a whoopsie”, to rogue admins wreaking havoc, to general compliance concerns, such as ensuring data immutability, proper audit trail and proof of disposition for removed items. Covering scenarios where Priority cleanup can be problematic is worth an article on its own, but for this one, I am more interested in the technical aspect, i.e. how the feature works. We will cover some of the controls that Microsoft has made available to address potentially problematic scenarios, but the article is certainly not exhaustive in this aspect.

A quick introduction

Here’s how the Priority cleanup feature works. You configure a policy, which is technically a retention policy, to define the locations to include in the “cleanup”. A rule object is also created, with 1:1 correspondence between it and the policy object. The rule defines the items to be matched within the selected locations, and the “matching” itself is represented by assigning a compliance tag to the corresponding items. Those are all already existing components within the compliance stack, now extended to cover the new type of PriorityCleanup objects (more on this later). Lastly, you designate a set of reviewers to approve the cleanup action, which is again leveraging bits from existing functionality, namely disposition review.

Of course, most of this complexity is conveniently hidden behind the streamlined, wizard-like interface you should already be familiar with from other compliance features. To access Priority cleanup, navigate to the Purview portal > Data Lifecycle Management > Priority cleanup or use this direct link. You will of course need the necessary permissions, which for the purposes of creating/managing the policy objects and their dependencies translate into being a member of the Priority cleanup admin role, which is by default assigned to all members of the Organization management role group.

On the top right corner of the Priority cleanup page, you will find the Priority cleanup settings button, currently exposing a single control – the Configure priority cleanup settings for your entire organization​ setting, which toggles the feature globally on or off. You can also toggle this setting via PowerShell, via the Set-PriorityCleanupSetting cmdlet, after connecting to the SCC endpoint that is. The Get-PriorityCleanupSetting cmdlet in turn can be used to query the current status of the setting. Keep in mind that this setting simply disables the creation of new priority cleanup policies and the modification of existing ones. Any active priority cleanup policies will continue to be enforced.

Creating a Priority cleanup policy

Provided you have the necessary permissions, you are able to create a new policy by hitting the Create a priority cleanup button. In the wizard, enter a Name (mandatory) and Description (optional) for the policy object. While this step of the process seems straightforward, it’s actually quite important. The Name you assign to the policy will trickle down to all its building blocks and thus must be unique and cannot contain most special characters. The wizard will only validate these requirements at the final step of the process, so if you enter something inappropriate, you will not know until later. As for the Description, I would strongly advise you to diligently detail the intent and expected outcomes of the policy.

Clicking the Next button will take you to the Locations page, where you detail which objects will fall under the policy scope. The feature currently only supports Exchange Online mailboxes, including those belonging to Microsoft 365 Groups. You can designate the set of mailboxes either directly, via group membership or via adaptive scopes. The picker does not allow you to select shared or room mailboxes, but you can add such via the underlying PowerShell cmdlets if needed. Exclusions are also supported, and if you aren’t certain which mailboxes to cover, you can just use the all-encompassing option, too.

Next comes the most important part – defining the KQL query Conditions that will be responsible for matching the items we want to get rid of. This step is mandatory – you cannot create a priority cleanup policy that targets all items within a mailbox, though you might be able to achieve the same by getting creative with the keywords. Speaking of which, most of the supported Exchange Online keywords can be used, with few exceptions. For example, you can create a query based on the folderId property, in order to cover all items in a specific folder, akin to targeted collections for Content search.

I’d strongly suggest that you be as specific as possible with the query, as well as double-checking that only the desired items will be matched, by using the same query to perform a Content search on the side. While no item is ever removed without an approval from the reviewer(s), by design the person who created the cleanup policy will be different from the person(s) reviewing the items, so there’s the possibility they will have a difference of opinion. With that in mind, I believe the Priority cleanup policy creation process will greatly benefit from additional contextual information.

In the current experience, we are presented with no estimates on the number of items potentially affected by the policy, and the only way to obtain this data is to wait for the initial processing of the mailbox(es) to complete, then check with one of the designated approvers to check/export the set of labeled items. There are some limitations of the reviewer experience, which we will cover later, that can negatively affect this process. The worst part is that if you discovered a mismatch in the expected set of results or a potential error in the KQL query, you have to start the process from scratch.

Anyway, back to the creation process. On the next page, Settings, you can define how matched items will be processed. The Delete items as soon as possible option allows you to delete the items as soon as the MFA processes the mailbox (only after the appropriate approvals are given!). Alternatively, if you are not looking for immediate deletion but instead want to override the retention period set for matched items, you can choose the Prevent permanent deletion until a set time option. Doing so requires you to then also define the period duration and start of the period. As the feature is effectively stamping items with a new label, you can also use the “when labeled” option.

Defining the set of Approvers is done next. This part of the process can use some streamlining IMO, as currently you are required to define three distinct individuals (and cannot use the person who created the policy as approver). The idea is to enforce the four eyes/two person principal, but in effect results in at least four people being granted admin permissions. And yes, you do need to specify users with active role assignments, as the wizard will check whether each of the approvers has a suitable role assigned, and will not allow you to complete the creation process otherwise.

Here are the set of approver roles, their responsibility and the respective permission requirements:

• Priority cleanup admins, responsible for approving items not subject to retention/eDiscovery holds. Requires the Priority Cleanup Admin role, which is by default assigned to the Organization Management role group.
• Retention managers, responsible for approving items that are subject to other retention policies/labels. Requires the Retention Management role, which is by default assigned to the Records Management role group.
• eDiscovery admins, responsible for approving items that are subject to eDiscovery holds. Requires the Search And Purge role, part of the Data Investigator role group. eDiscovery Administrator role group.
• In addition, all the assigned approvers will need to have access to the Data Classification Content Viewer and Data Classification List Viewer roles, part of the Content Explorer Content Viewer and the Content Explorer List Viewer role groups, respectively.

Once approvers are defined, the last remaining choice is whether to enable the policy immediately, create it in disabled state or use simulation mode, similar to what other compliance features offer. With that, you can proceed to the Review page, where you can take one last look at the policy settings before creating it. An additional acknowledgement is needed on this page, as Microsoft wants to make it clear that enabling a priority cleanup policy can and will result in permanently deleting items that are subject to holds.

For additional details on the priority cleanup policy creation process, as well as screenshots, please refer to the official documentation. Instead of parroting the instructions you can find therein, I prefer to focus on some of the more interesting bits, such as how things work on the backend.

In part 2 of these series, we examine how Priority cleanup magic works on the backend, then cover the reviewer experience.