SharePoint (and Project Server) Shenanigans

This article is part of a series:

In the first article of this series we discussed what IRM was, some scenarios and high level device supportability.

Part 1: https://spandps.com/2015/09/21/o365-sharepoint-onlineinformation-rights-management-irmwhat-works-what-doesnt-in-a-business-context-part-1/

In the second article we covered file type support.

Part 2: https://spandps.com/2015/09/22/o365-sharepoint-onlineinformation-rights-management-irmwhat-works-what-doesnt-in-a-business-context-part-2/

Welcome to the third article in this series about the IRM implementation in SharePoint.  This post will be mostly focusing on how Windows Explorer interacts with Document Libraries with IRM enabled.

The Scenario

We are maintaining the same settings as the previous two articles, but using a document library instead of a list. 

As stated previously, behavior is the same but of course with a document library you can interact with it via Windows Explorer, drag and drop, in application via Word etc. as well as the standard upload process.  Let’s see if it maintains the protection that we have put in place…

To recap the supported file types:

• Word, Excel, PowerPoint 2003 to 2016
• PDF

Now as part of my ongoing research I have found mentions of XPS and InfoPath as well, so we shall give those a go as well.

In these tests I shall try all variants of the files for doc to docx and the macro and template versions in between.

Also unlike the previous articles I shall widen the uploads to include Excel and PowerPoint in the examples.

So without further ado…

Standard Upload

• Supported File Type (Word, Excel, PowerPoint, PDF, XPS,)
• Unsupported File Type (PNG, InfoPath)

From my standard upload testing the results are as follows:

Document Library Screenshot:

XPS files uploaded fine and were protected by SharePoint IRM however, my client was not configured and could not access the IRM server in my setup.

Furthermore, I got this result when trying to open a protected XPS in the browser (IE11):

The client result was:

PS. I found that InfoPath was not supported in SharePoint Online (as of 2015-09-23 – not surprising given that it is not part of Office 2016 anymore.  (Office 2016 was released this week by the way – yay )

Drag and Drop

In true scientific experiment fashion, same files, different upload method…

• Supported File Type (Word, Excel, PowerPoint, PDF, XPS,)
• Unsupported File Type (PNG, InfoPath)

For this I shall be using the drag and drop capability that was introduced in SharePoint 2013 and is still available in 2016.  I shall drag and drop all files (supported and unsupported at once)

It is good to say that the result is the same as the standard upload method and the error messages it returns for unsupported file types make sense.

Just remember the issues with XPS I experienced this time round and the PDF IRM supportability issues from the last post are still present in the document library.  See Part 2 for details.

Windows Explorer

One more time around…same files, different upload method…

• Supported File Type (Word, Excel, PowerPoint, PDF, XPS,)
• Unsupported File Type (PNG, InfoPath)

Like the drag and drop method to the document library I shall be dragging all files into the Windows Explorer view that opens up when you click this button on the library ribbon:

Dragging the files into Windows Explorer view… in progress:

So everything was going will until I got to the unsupported files:

So as you would expect, it definitely stopped the file getting into the library as you would expect.  You have the option to skip the file which moves on to the next file and processes it based on the same rules.

The good news is, we have stayed in compliance!

The bad news is that error message:

An unexpected error is keeping you from copying the file.  If you continue to receive this error, you can use the error code to search for help with this problem.

Error 0x80070021: The process cannot access the file because another process has locked a portion of the file.

Now as a techy, I would totally expect that error from Windows Explorer… after all, it doesn’t know what SharePoint is, it just knows that it has failed.

From a business user perspective, this is confusing and will no doubt start calls to the help desk.  The help desk may not know the answer either and it will result in an escalated call to the SharePoint Admins / Operations teams.

Not much to be done, but adds credence as to why I am blogging on this subject.  Hopefully some google’rs / bing’rs will find this post and have a bit more information about what could be going on.

Conclusions

So there you have it, whatever way you get files in, it works… I can confirm that in each case, opening the files showed that they were protected with IRM.  Windows Explorer for unsupported files is a bit messy but not surprising.

Next Post(s)

• I will eventually get to how to deal with unsupported file formats with the desktop RMS client but as I dig deeper, more and more topics become more appropriate to discuss
• IRM permissions vs. SP Library permissions
• Client Experience – Protect & Unprotected…

Anyway, till the next one…  stay SharePointin’