Promoting Azure Information Protection labels to SharePoint metadata column

Edit 1-March-2017:
Microsoft has reached out to ask me if I would be so kind to stress that the solution described below is a temporary solution and it could be that things might change in the future. Hereby stated. Now on to the article itself.

On February 8th this year, Microsoft made the latest version of Azure Information Protection (AIP) general available. You can find the announcement here: https://blogs.technet.microsoft.com/enterprisemobility/2017/02/08/azure-information-protection-december-update-moves-to-general-availability/

What was also part of that release, but wasn’t mentioned in the announcement, is the integration with SharePoint metadata columns. Before this GA release, some integration was already possible, but that required registry hacks on local client machines. With the latest release it is possible to do the configuration in the Azure Portal. There are some caveats, but we’ll get to that later in this article.

The scenario

When you label a document with AIP, the label information is stored in the properties of that particular document.

Here I have set the Sensitivity of my document to Internal:

When you have a look at the document properties, you’ll find that a couple of AIP related properties have been set for this document. Some MSIP_ properties and a Sensitivity property (or another name if you have defined another property title in your AIP configuration in Azure, see step 1 under Implementation, further down this article).

Now what we would like, is to have the value of the Sensitivity column promoted to a SharePoint metadata column. The main reason why you’d might want this, is because in SharePoint you cannot see the label of a document without opening that document. It could be quite convenient to see the label right in the Document Library or even create views or sortings based on the label.

Let’s see how we can accomplish this.

The implementation

First, we need to set up some things in the Azure Portal:

Step 1
Login to the Azure Portal and go to your Azure Information Protection overview page. Take note of the Title value. The default value for Title is Sensitivity. This is also the property name in Word, and, very important, this is also the name you must use for your metadata column in SharePoint. So, if you’d like a different property/column name than Sensitivity, this is where you should change that.

Step 2
Click the three dots on the right side of your policy:

and choose Advanced settings:

Step 3
Type in the following properties:

Name: SyncPropertyName
Value: Sensitivity
(the value here must be the same as the Title value you defined in step 1, and the same as the metadata column name in SharePoint)

Name: SyncPropertyState
Value: TwoWay

Next, let’s create a column in SharePoint:

Step 1
Browse to the Document Library of your choice, and create a new column of the type Choice. The column name must be that same name as the Title and the SyncPropertyName again.

Step 2
In the list with choices, type in the exact same labels as defined in Azure. When you use sub labels, type in the master label and sub label in one line, separated by a space.

Here’s an example of some labels I have defined in Azure:

Here’s how that would look in the choice column:

That’s it! We are now ready to use the SharePoint column. When you upload a document with a certain label set, the Sensitivity column in SharePoint automatically inherits the chosen label. Below you’ll find an example Test4.docx that has an AIP label applied and that has that same value in the SharePoint metadata column.

Caveats

Like I said in the introduction, there are some caveats you need to be aware of:

  1. For some reason, directly saving an Office document to SharePoint does not set the metadata column. This only happens the first time you save a document to SharePoint and only when you save it directly from the Office application. If you save the document locally first and then upload it to SharePoint, the column is set. If you open an already saved document from SharePoint in an Office application, then change the label, and then save the document again, the label is set as well.
  2. Like said before, if you change the label of an existing document in Office and save the document again in SharePoint, the metadata column is updated. This works the other way around too. If you change the value of the metadata column for a particular document and then open that document in Office, you’ll notice the label has changed accordingly. This is very useful, for example, for bulk setting AIP labels for documents. But his also has a drawback. If you have configured AIP in such a way that a user must justify the lowering of the classification of a document, the user will not be asked for this justification when he lowers the classification by changing the value of the metadata column in SharePoint.It is of course possible to make the SharePoint column read-only with some plumbing, but that is beyond the scope of this article. (You could even create the column as a Single line of text column then)

Microsoft is aware of the current caveats, and is working on better SharePoint integration for AIP. Still, the promotion of AIP labels to SharePoint metadata columns could be very useful, for reasons as laid out in this article. I hope this helps you with your AIP implementation

8 thoughts on “Promoting Azure Information Protection labels to SharePoint metadata column

  1. Remco

    Hi Maarten,

    Are you aware of any updates on the integration between AIP and SPO? I’m currently looking for a way to implement Azure Information Protection in combination with Sharepoint Online and would like to see the document classification within a document library in Sharepoint.

    Using the steps in your blog I’m able to create a new document locally, classify it and upload it to Sharepoint. The document library shows the correct classification based on the actual classification of the file.

    Whenever I change the classification in the document library and open the document, or open the document, change the classification and save it back to Sharepoint, the change doesn’t seem to sync back and forth. This also applies on documents which I create directly within Sharepoint.

    So basically the only way I’ve got this thing working right now is by uploading a document which I already classified from my local device to Sharepoint. In that case the classification shown in the document library corresponds to the classification property within my document.

    Have you had similar experiences to the one described above? Any help is welcome!

    Regards,
    Remco

    Reply
    1. Remco

      Never mind, Had a stupid typo by adding a ‘SyncPropertyValue’ attribute instead of ‘SyncPropertyState’.

      Thanks for this blog post, you helped me out :-)!

      Reply
  2. Vanessa

    Hi Maarten

    Trying to get this working in SPO and I’ve run across an issue.

    I’ve set SyncPropertyState to TwoWay as described. Updates from column to document are syncing as expected but the classification becomes ‘read-only’ in the Office application, i.e. can’t change or delete it within the document itself. I can only change it by updating the column value in SharePoint.

    Can you provide any advice?

    Regards
    Vanessa

    Reply
    1. Maarten Eekels Post author

      Hi Vanessa, just checked in my tenant and there it still works as expected. Could you remove the SyncPropertyState property and add it again? Make sure you really type it in, don’t copy it from my blog. It is essential that there are no spaces in the values.

      Reply
      1. Vanessa Oats

        Hi Maarten

        Apologies for the delay in responding.

        I tried as you suggested, with no luck; however then created a new column with a unique name and renamed everything correspondingly in AIP, and it’s now working as expected.

        Regards
        Vanessa

        Reply
  3. Éric Clément

    Thanks for your post.

    I’ve try hard to make i work but unfortunately, it works like Remco described it in July.

    I’ve check the “Stupid Typo” he described. I don’t have it unfortunately.

    Any other ideas of things to check ?

    Thanks.

    Reply

Leave a Reply to Éric Clément Cancel reply

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