Posted by One of the most anticipated changes (or enhancements) to the Microsoft Information Protection ecosystem has been the ability to co-author and auto-save encrypted documents from the Office apps. This functionality is now General Available.
Why the anticipation? Because this change really enhances the user-friendliness of Microsoft Information Protection and Microsoft 365. And as such, removes possible barriers for organizations to start using information protection. An example:
Co-authoring and AutoSave
Let’s say we have a highly confidential Excel sheet. This has been labeled with a specific sensitivity label enforcing encryption. Only people in the Finance department are allowed to edit this type of documents. Francis opens the document in Teams and decides to open it in the Excel app. A couple of minutes later, Peter opens the same document using the Excel app. Instead of opening the document, he is shown an error message, stating that the document is already opened by another user.
Let’s say that Peter can open the document in the end and can edit this. He wants to enable the AutoSave feature, as he is used to this by now. Unfortunately, this option is now disabled. As the document is encrypted, AutoSave will not work.
These two limitations have bothered a lot of organizations and have even kept organizations from implementing Microsoft Information Protection altogether. So being able to co-author and autosave documents is a great enhancement.
Co-authoring encrypted documents is a great enhancement. But as you might have noticed when enabling this feature, there is a subtle mention of “metadata”. In this blog, I want to delve deeper and show what this is all about. And warn you about some consequences.
Enabling and limitations
Before I delve deeper into the metadata changes, some remarks on enabling and limitations. To enable the feature, you will need to use the compliance center. Enabling is very simple, but beware that’s that the case for disabling the feature.
Also, beware of the limitations. This feature will not work when you have “user-defined permissions” and/or content expiration has been set in the label. Also, Double Key Encryption and the Office apps for iOS and Android are not supported.
Metadata changes
Enabling the co-authoring and AutoSave feature for encrypted documents has one major impact on the service; The metadata for encrypted (Office) documents will change. And if you use this metadata, for example, to search documents or enable DLP/mail rules, you will need to take attention.
Label as plain text
One of the key functions of Microsoft Information Protection is to have the label information stored with the document in plain text. This allows for other platforms to retrieve the label, without the need for opening the document. It can also be used within Office 365, for example when using the content search function.
The metadata can be found in the custom properties of (Office) document (File | Info | Properties | Custom). Here you will find several items which begin with MSIP_Label_<labelid>. Some of the more important items are:
MSIP_Label_<labelid>_Enabled
MSIP_Label_<labelid>_SetDate
MSIP_Label_<labelid>_Name
You will notice that every property contains a unique labelid. And this is important because these properties can be used by Microsoft 365 and other (non-Microsoft) platforms as well. For example, you can do an eDiscovery search or content search based on a query containing these properties. For example: the search schema for SharePoint Online showing the crawled properties;
You can also setup mail rules in Exchange Online to act on e-mails and/or attachments having these properties. So these are important – if you are using them this way.
What’s about to change?
When enabling the new co-authoring experience, this metadata schema will change. And there is a difference between documents that have already been labeled and documents that are new. But first: the change. And for this we will need to look at the makeup of an Office Document. This is called the OPC or Open Packaging Conventions.
Any Office document is stored using this OPC. When you replace the extention an Office document to .ZIP, you can open this document as an OPC. You’ll notice that the document is made up of different sections. For example: Microsoft Word.
The word section contains the contents of the document itself. The docProps section contains any properties regarding the document. Including the custom properties where the MSIP_ information is stored. This is stored in a file called Custom.XML and it looks like this.
The section called docMetadata is new and will only be shown when the new metadata has been activated. And this is the location for the new labelinformation.
The new label information is stored in a file called LabelInfo.xml (makes sense). This file also contains the labelid, but also any other (earlier) label information. If these have been removed because of the enabling of co-authoring, it will have the setting removed=”1″.
New and existing documents
Newly created and labeled documents automatically receive the new LabelInfo.XML. The custom properties are only used to store information on visual marking in the document. This is also new by the way.
Documents that have already been labeled (and have the customer properties enabled) will be modified. If the label information is still correct (the label is available, etcetera), then this information will be converted to the LabelInfo.XML when the document is opened and saved. The custom properties will still be there but are no longer used by Microsoft Information Protection.
That’s it in a nutshell, but if you want to take a deeper dive, then go to this article on Microsoft Docs.
Now what?
Because of this metadata change, you will no longer be able to use specific systems (like Exchange Online mailrules) to detect these labels. Systems can be changed to take this metadata configuration into account.
For the Microsoft 365 administrator, my recommendations would be to switch to either Microsoft 365 Data Loss Prevention options and use the labels as a condition. Or use client-specific advanced configurations. These are really comprehensive and allow you to use the label-ids as well. For example:
Set-LabelPolicy -Identity Global -AdvancedSettings @{OutlookWarnUntrustedCollaborationLabel=<labelid>}
You can also use the data explorer in the Compliance Center to get an insight into the labels and where these are used. And auto-classification of information is still available, either active or at rest.
So there a couple of options available. But be aware that using the metadata in your solutions will most probably fail on the short run.
AlbertHoitingh.com 
Great post. It looks like the xml data is not present in labeled documents that are encrypted (or, at least, not present in decrypted form).
Informative post! So I was able to create a manage property off of a custom property (Purpose). I created a condition in “Except if document property is” in my DLP policy. Do you know if Microsoft will ever remove this “Purpose” custom property in word/excel/powerpoint?
Also, there used to be a “SetBy” metadata for the sensitivity labels (MSIP_Label__SetBy). Microsoft may have removed this crawled property. Do you know how I can find other ways of capturing who changed the label. I want a managed property off this so I can create another DLP condition. By the way, I believe the “User” is captured in the Activity Explorer for “Label changed” activity, so I assume there would be a crawler property.
Thanks in advance!
Hi there,
Thanks for these very interesting questions. As far as I know, the MSIP_Label_SetBy is not part of the standard part of the information protection metadata (https://learn.microsoft.com/en-us/information-protection/develop/concept-mip-metadata), but this might be added by SharePoint Online. I do see this one popping up in my demo-tenant SharePoint search schema.
But as I understand it, for any newly created documents, the MSIP_ metadata will not be populated and cannot be used. And there is no built-in DLP condition to check for sensitivity label changes. But there is the audit log. So you could set up a notification (alert) to inform you when a label for a file or site is changed. You might even use Sentinel or Power Automate to act on these alerts. The alert-category is FileSensitivityLabelChanged. Which also gives to the previous and new label and the justification. https://compliance.microsoft.com/auditlogsearch?viewid=Async%20Search
As to the “Purpose” property. I simply don’t have the answer to this. I’ve checked the roadmap (https://www.microsoft.com/en-us/microsoft-365/roadmap?filters=Word%2CPowerPoint%2CExcel%2COffice%20app) but I don’t see anything there. But you can look at this as-well 🙂
Great article, I was not able to understand this when reading MS articles. Your is great. Thanks!!!
what about third party product, we are using Proofpoint information protection to detect the label is in the metadata of MS files, does the Label GUID get written to the LabelInfo.XML?
I cannot be sure. Although Microsoft does state:
“Do not enable this setting if you use any apps, services, scripts, or tools that reads or writes labeling metadata to the old location.”
https://learn.microsoft.com/en-us/microsoft-365/compliance/sensitivity-labels-coauthoring?view=o365-worldwide#metadata-changes-for-sensitivity-labels
So, I think we can assume that this also goes for Proofpoint. Unless this is using a different kind of detection mechanism.