Azure Information Protection is a powerful solution. But there are still scenarios where integration with other Microsoft platforms need improvement.
There are so many sources of information on Microsoft’s solutions out there on the internet. And I try to follow many of them. One of these sources is Yammer. There’s a lot of Yammer networks focussing on specific Microsoft topics. One of these is used by Microsoft to discuss Azure Information Protection with people outside of Microsoft.
These groups (and the one I mentioned in particular) offer a great source of information on issues, bugs, questions and more. And this week I came across this issue.
Sharing scenario
Let’s say you stored AzureIP protected documents in a SharePoint or OneDrive library. Then you will know that some Office 365 functions will not work. For example: the preview function in Office Web Applications.
You access this libary by using the OneDrive client. And using this client, you’re sharing a document. No problem – that’s a simple function using the client.

The person you’re sharing with will receive a link. If he/she’s external, then the document is also protected by a confirmation code. But in the end, the working is the same. The link opens the document.
Now what?
And now the weird thing happens. First of all, you’ll see a message stating that the document cannot be opened. And this is correct (unfortunately) – Office Web cannot decrypt the document. No problem – just open the document in de Office application itself….
But when you share a protected document with someone outside of the organisation, the Edit in option disappears. I’ve just tested this with Edge. With an external account, the edit button is gone and for an internal account it is present. All other document options (like download) are greyed-out.

So there is no way for the external party to open the document. Now you can choose to send the document as an attachment of course. But there’s also a quick work-around for this. But not a permanent one, because it’s not user-friendly.
Work-around OneDrive
If you get a link like this:
https://<OneDrive>/:w:/r/personal//_layouts/15/Doc.aspx?sourcedoc=<documentnumber>&action=default
you will see the error without the Edit option.
Just replace the entire bit after /_layouts/15/Doc.aspx with /Documents. You will end up with a view of the document-library and the document you shared. Including the option for downloading the document or opening in Word.
Work-around SharePoint
For SharePoint you use /Shared%20documents and it will work.

But I’ve got folders?!
However. The problem arises when you share a document in a folder. When you use the workaround, then it will not show the document. You will need to include the name of the folder as-well.
You can add the folder to the URL of course.
https://<SharePoint>/site/shared documents/folder
The name of the subfolder is present at the screen (top left). And by adding this (replace spaces with %20) it will show the document.
Let’s be fair
Ok. This is a work-around of sorts. But is it workable? Think about it, you’ll need to explain to your external parties how they can open protected documents using this work-around.
To be very honest, I’m not sure there is a nice solution at this moment. Having AzureIP integrated into Office Web Applications (which is coming soon) would be the definite solution. At this moment you’ll either have to explain this scenario to your users and/or use e-mail to exchange the protected documents. Or use the work-around. Or don’t use AzureIP and SharePoint/OneDrive but use information rights management instead.
Either way, it’s something which is going to be solved. But hasn’t yet.
Last remarks
For those of you who are wondering:
- I tested this with Google Chrome as-well and got the same results;
- I sent the link with the “Editing” permissions.