Odd Document Mismatch Notifications For No Apparent Reason

Sensitivity label mismatches occur when a user applies a sensitivity label to a document in a SharePoint Online site that has a higher priority to the container management label applied to the site. When this happens, SharePoint Online sends a document mismatch notification email to the user who caused the mismatch and to the site owners.

It’s a simple and effective way to draw attention to the potential danger of data leakage caused when sensitive information is stored in sites intended for material that perhaps isn’t so confidential.

A Flood of Document Mismatch Notifications

Recently, I noticed that some accounts were receiving a flood of document mismatch notifications. This seemed strange. The accounts receive document mismatch notifications for the entire tenant because I use a mail flow rule to centralize processing of mismatch notifications, but the volume was abnormal (472 in a week). It’s not as if many people in the tenant apart from me apply sensitivity labels to protect content!

When I examined the email, I saw that the mismatch was accurate (the Confidential -User Assigned label has a higher priority than the Confidential access container management label), but the notifications were for Word documents with odd names that humans were unlikely to have created (Figure 1).

Clicking the link to open the document brought me to the SharedVersions folder in the preservation hold library of the owning site. This is the location used by SharePoint Online to hold copies of cloudy attachments (aka “modern attachments”, or the sending of links rather than actual files) when an auto-label retention policy is in place to capture copies of cloudy attachments for eDiscovery purposes. The auto-label policy covers cloudy attachments shared in Exchange Online email and Teams and Viva Engage conversations. It also covers situations where Microsoft 365 Copilot extracts and uses content from a document in its responses, such as creating a set of key points from a document.

For instance, Figure 2 shows Microsoft 365 Chat (BizChat) extracting key points from a document. If a retention policy for cloud attachments is in force when this happens, a background SharePoint Online job captures a copy of the referenced document as a cloudy attachment and assigns the retention label defined in the policy. It can take up to an hour before SharePoint creates the copy of the cloudy attachment in the preservation hold library.

The purpose of retaining copies of cloudy attachments is to make sure that eDiscovery can find the exact content at the time it was shared through email, Teams, or Viva Engage rather than the current content. A document might be very different now to what it was when its author circulated it to peers for their review and comment. Because SharePoint Online knows what version of the file was shared, it can locate the correct copy for eDiscovery. In Figure 3 we can see that this copy of a cloudy attachment is for version 5.0 of the shared file.

The Problem with Document Mismatches in Cloudy Attachments

The idea behind retaining copies of cloudy attachments is great, but the implementation runs into a problem when a sensitivity label mismatch exists. SharePoint captures a complete copy of cloudy attachments, including the assigned sensitivity label and that’s what provokes the document mismatch notification.

There’s no way to fix the problem. You cannot change the assigned label for a file captured in the preservation hold library when a retention policy is in force because SharePoint Online blocks any attempt to change the label. Likewise, SharePoint blocks any attempt to delete (or move) labelled items, even by site or global administrators.

In summary, you can open the document and view its content, but you can’t change anything. If this wasn’t the case, it would be possible to compromise the integrity of files retained in the preservation hold library. You can exclude the site(s) from the cloudy attachment retention policy, but this only prevents the capture of future cloudy attachments.

The result is that SharePoint Online keeps on sending document mismatch notifications to the author of the cloudy attachments and the site owners. The flood of notifications continues until the retention period set for the label finishes and SharePoint Online moves the copies of the cloudy attachments to the second stage of the site recycle bin and eventually permanently deletes the files.

The simple solution would be for SharePoint Online to ignore document mismatches for anything stored in the preservation hold library.

Fix Cloudy Attachment Storage Before the Problem Gets Worse

No one seems to have protested (in a public forum) about the problem of protected cloudy attachments ending up in the preservation hold library. I guess not many tenants that use a cloudy attachment retention policy have hit the problem with document mismatches. Maybe they don’t use sensitivity labels or perhaps their users are very disciplined at how they assign sensitivity labels to files. However, as time goes on, sensitivity labels are likely to become more popular and more Microsoft 365 apps might generate cloudy attachments.

Now’s a good time to fix this particular problem. I’ve made that point to Microsoft. Let’s see if they fix the issue.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.