This is the third article in our series on Priority cleanup. Consider checking the first part for introduction on the feature and the second part for “backend” details and the reviewer experience.

Disabling and deleting priority cleanup policies

It is important to also understand what happens when you disable or delete a priority cleanup policy. For example, what will happen if you created a priority cleanup policy, only to later realize the KQL query you used has an error in it. Should you just edit the policy to remedy this? Should you disable it? Or outright delete it? What would the implications be for items that might have already been tagged, processed (reviewed) and potentially deleted?

When it comes to editing an existing priority cleanup policy, you can update the set of locations/mailboxes included, the set of approvers, and most importantly, the KQL query. Any changes will trigger the policy distribution process and will only be reflected after a MFA workcycle or two. Items that no longer fall into the scope of the priority cleanup policy will have the corresponding compliance tag stripped from them, and any actions that have not already been executed will be ignored. There are certain rough edges in this process however, as we would see in the next scenario, disabling an active policy.

To disable an active priority cleanup policy, you need to select it in the UI, click the Edit button and keep pressing Next until you get to the Policy mode page, where you can finally toggle the policy off. Press the Next button again, and finally, Submit the changes. The process can certainly be streamlined a bit, for example by exposing an Enable/Disable toggle on the policy list page, instead of having to go over the full wizard. As usual, you will have to also wait for the distribution process to complete and the MFA to reprocess the mailboxes under the policy’s scope. Once the process is complete, any items matching the policy will have their ComplianceTag property stripped. Interestingly, the four other tags stamped on processed/reviewed items do not seem to be removed.

In turn, this seems to result in a behavior where disabling a priority cleanup policy will not clear the list of items for review for the given policy. To put it in other words, you will continue to see the same set of items under the review experience, effectively working with a snapshot at the time the policy was disabled. This is another place where the process can be misleading, as lots of things can happen to said items in the meantime. For example, they might fall under the scope of another priority cleanup policy, and thus be tagged with its corresponding compliance tag and appear in the other policy’s disposition review experience.

In addition, reviewers will continue receiving notification emails, urging them to review items. In fact, items can still be approved for deletion, although luckily, the MFA does seem to ignore such items and will not proceed with the permanent removal. At least in my test, approving the deletion of an item under the scope of disabled priority cleanup policy updated it status to Awaiting deletion, however after multiple weeks (and additional MFA “nudges”), it remains available in its original place. While this is great news from data integrity perspective, we have yet another scenario where the review experience might give you the wrong impression. The exported list of items will not help either, though a content search with the policy keywords will reflect the “correct” picture.

The only way to make items disappear from the Pending Cleanups view is to delete the corresponding priority cleanup policy. Note that I specifically mentioned the Pending Cleanups view though, and not the review process as a whole – you will still see the “container” for a deleted priority cleanup policy under the Items for review page. This is fine, as you probably want to have a place where you can check which items were approved for deletion and by whom, even for deleted policies. And with the Pending Cleanups view being empty, there is less room for confusion.

But I digress. As soon as the policy distribution status is updated, all of its building block will be removed on the backend, and the MFA will ensure that the corresponding compliance tag has been stripped from matching items. As always, you can confirm this by running a content search based on the compliance tag value for the policy. Even for deleted priority cleanup policies, you will still see items retaining the four additional MAPI properties we detailed above. They do have different “tag” values though, which probably is what allows the disposition review UI to treat them differently, compared to the “disabled” scenario above. At least that is my best guess. Lastly, no additional email notifications are sent to the designated approvers for a deleted policy.

Monitoring the progress of the cleanup process

It is also important to know the ways you can monitor the progress of the cleanup operation. Above, we touched on the usefulness of running a Content search in order to estimate the number of items that will be affected. You can also use content searches to get a list of all items currently tagged via the compliancetag keyword, for example compliancetag= “Test Exchange Policy 2”. Though, content searches cannot give you information of which locations are yet to be (fully) processed. The alternative would be to enumerate items in the locations defined in the policy via the Graph API or EWS, then check the tag assigned. Not a pleasant task when using the Graph, I can tell you that much.

When it comes to checking on deletion progress, you might be able to leverage the Get-MailboxFolderStatistics cmdlet for some quick insights. If the number of items in say the Purges folder of a given mailbox is going down, you have a strong indication that items are being removed. A more robust method would be to leverage the Get-RecoverableItems cmdlet, and you can also use Content searches to confirm the number of items matching the policy’s KQL (or items tagged with its compliance tag) is going down. All that said, with the risk of repeating myself I will again point out that the feature can benefit from some reporting/insights.

Audit trail

An important part of the priority cleanup process is the audit trail it leaves, as after all we can potentially be dealing with very sensitive items. Microsoft has made sure that every step of the process is audited, from creating the policy and making changes to it, to approvals, to each individual item being removed. And they’ve also made it easy to single out all relevant events, by means of using the GUID of the compliance tag corresponding to the policy in your audit log query. Here is how the various audit records generated for processing a specific item will look like, across the entire priority cleanup process:

$res = Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date).AddDays(1) -SessionCommand ReturnLargeSet -ResultSize 5000 -FreeText 5604baa3-f7d4-4fa3-817f-56f4c7203285

From top to bottom, we have the initial processing of the item via the MFA background process, tagging it with the priority cleanup tag (ApplyPriorityCleanup). This event is followed by the two approval stages (ApproveDisposal) and the subsequent deletion of the item (PriorityCleanupDelete). We can see that it took almost a week before items appeared for review, although the timestamps for the approval events cannot be reliably used to point out delays (as approvers can take their time to review the item). On the other side of the spectrum, once the approvals were granted deletion was processed hastily, only to have the corresponding audit log entries lag for another week or so. But all is well when it ends well.

One thing to keep in mind here is that some of the audit records correspond to actions taken on individual items, such as the ApplyPriorityCleanup entries, which are generated when the MFA stamps a matching item or the ApproveDisposal entries generated upon granting approval. On the other hand, some audit records can be “composite” and combine the operations performed on multiple items. One such example is the audit entry for the PriorityCleanupDelete operation, under which you will find a list of up to 100 items removed from a given mailbox.

Another important note is that audit records might not be available immediately after the operation has been performed. Putting aside the usual delays of ingesting items within the Unified audit log datamart, it looks like there are dependencies on the MFA or other background processes for ingesting the relevant audit records. This is most evident for audit records of the PriorityCleanupDelete variety. Thus, even though you might be able to confirm that the items in question have been already deleted, the corresponding audit logs will only appear after a few days. At the same time, other records, such as ApproveDisposal appear with “standard” delay. Hopefully Microsoft will address this going forward.

Lastly, different audit records expose different set of details for the processed item. For example, ApplyPriorityCleanup events surface the item’s Subject and Id, whereas ApproveDisposal events shows Subject (“Title”) and InternetMessageId (“Id”), and PriorityCleanupDelete entries expose all three. Thus, the best value to use should be the Subject one, which unfortunately it the least reliable when leveraged in audit search.

Closing remarks and summary

In this series, we took a look at the latest feature in Microsoft’s compliance arsenal, dubbed Priority cleanup. The feature is designed to address scenarios where a need to remove items under hold arises, and you can think of it as the ability to add item-based “exceptions” to locations covered by existing retention policies. The “priority” moniker does not mean the process is fast however, in fact the need for multiple levels of approval before disposing of the items and the reliance on the MFA makes it quite slow. Instead, “priority” means that the feature can take precedence over existing retention controls.

Priority cleanup cleverly reuses existing functionalities and integrates seamlessly with other functionalities within the Microsoft 365 suite. The configuration is stored as a Retention policy/rule that applies a Compliance tag to items designated by a KQL query; item review and approval is done via the disposition review facilities; Audit covers all the stages of the cleanup process. On the other hand, this reliance on existing building blocks results in inheriting some shortcomings, too. This is most notable in the review process, which hopefully will be improved going forward.

Speaking of limitations, Priority cleanup only supports Exchange Online user mailboxes currently, with other mailbox types supported via PowerShell. Support for mailboxes with auto-expanding archives is also included. The feature also supports adaptive scopes and has robust support for KQL keywords and queries. Microsoft 365 Groups, Teams, SharePoint Online and OneDrive for Business sites are currently not supported, but are obvious candidates for future improvements.

Considering the potential impact this feature can have if misused or misconfigured, Microsoft has designed it with strict requirement for multiple distinct admin accounts and clear separation of duties. That said, a rogue admin with sufficient permissions can still provision multiple accounts and grant all the necessary permissions to run a Priority cleanup on his own, which incidentally is how I am able to bring you this review. And while the feature is designed to respect items marked as records and will not process them, there are still many possibilities for abuse. Perhaps integrating parts of the process with Privileged Access Management would help with that regard, if anyone at Microsoft remembers that this feature exists, that is.

At the end of the day, Priority cleanup is not a feature that you should be employing on a regular basis, and without proper oversight. Don’t get me wrong, the feature certainly has its uses and will enable organizations to address some scenarios that were previously impossible. But it should be used sparingly, and with surgical precision. It is most definitely not a solution for the “my Recoverable Items subtree is full” type of issues. If the need to use Priority cleanup arises, make sure that all users involved in the process work together as a team and share a clear understanding of the expected outcome, specifically the potential legal ramifications deleting any single item will have.