Monday, January 24, 2022

New metadata model MIP

Must read

avatar
Albert Hoitingh
Office 365 business consultant/architect and Microsoft MVP with a core interest in everything to do with information management, (Azure) information protection, governance and security. Frequent speakers at SharePoint Saturday (VIanen, London, Cambridge, Lisbon), Office 365 Engage and Dutch Information Worker User Group.

 

 

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.

thumbnail image 3 captioned Figure 2: Co-authoring experience when protected document is opened in two different Microsoft 365 apps for Windows and Mac

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.

Enableing 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.

Option to turn on co-authoring for files with sensitivity labels.

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.

More articles

Leave a Reply

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

Latest articles