Complex Interaction Between Office, SharePoint, and OneDrive
One of the many announcements at the recent Ignite event covers co-authoring of Office files protected by a sensitivity label with encryption. Up to now, co-authoring was only possible when everyone uses the Office Online apps (Word, Excel, and PowerPoint). When they edit files protected by a sensitivity label with encryption, the desktop apps take an exclusive lock to allow the apps to remove protection and then reapply it when the edit session finishes. For this reason, the autosave feature built into Office to capture changes on an ongoing basis also didn’t work.
Now available as a preview, both co-authoring and autosave work, but only if supported by the tenant configuration and if users have the right software. It’s early days yet but having the ability for concurrent editing of protected files with desktop apps is an important step forward for those of us who prefer desktop Office to its online counterpart.
You can’t co-author using the mobile Office apps, but then again, would you want to?
The Right Version of Office
Microsoft details the prerequisites to make co-authoring for protected documents in this article, which I don’t intend repeating here except to draw attention to some critical points.
The biggest hurdle for some organizations is that everyone in the tenant must use recent versions of Office which support the new location for the metadata to store sensitivity label information. The change in location came about through version 1.7 of the Microsoft Information Protection SDK, specifically to support co-authoring. The Office Online apps support the new location for labeling data, as do builds of the Microsoft apps for enterprise (aka desktop Office click-to-run) from 16.0.13801.20182 (Windows) and 126.96.36.199 (Mac).
After making sure that appropriate client software is available, you can update the tenant configuration for co-authoring by going to a specific location in the Microsoft 365 compliance center to enable the feature. Figure 1 shows what I see in my tenant after the configuration update. Note the warning that only Microsoft support can reverse the configuration change.
I anticipate that Microsoft will make this change unnecessary (or the default) in the future. They are cautious now because many Office clients incompatible with the updated metadata location are in active use. Over time, as people install updated versions of Microsoft 365 apps for enterprise, the need will reduce, and co-authoring will become part of the normal support for sensitivity labels built into SharePoint Online and OneDrive for Business. In other words, the configuration update is a necessary evil for now.
I used the PowerShell Set-PolicyConfig cmdlet to configure co-authoring. Not by choice, but because I was told to do so by a Microsoft engineer. The cmdlet is part of the compliance set, so after connecting to the Exchange Online management module, you can run the Connect-IPPSession cmdlet to connect to the compliance endpoint and then update the configuration. For example:
Connect-IPPSession Set-PolicyConfig -EnableLabelCoauth $True
For now, co-authoring is supported for documents protected by labels with predefined permissions. Microsoft told me that they’ll support labels with user-defined permissions soon.
Unified Labeling Client
Among the prerequisites listed by Microsoft is a version of the Unified labeling client to support co-authoring of protected documents. The implication is that workstations used for co-authoring must install AzInfoProtection_2.10.46_CoAuthoring_PublicPreview.exe. This is incorrect. Despite its name and inclusion in the list of prerequisites, co-authoring doesn’t depend on the UL client. The Co-authoring version of the UL client mentioned in the prerequisites is intended for organizations which already use the UL client for its functionality, like client-based automatic labeling and the ability to apply protection to non-Office files. Azure Information Protection P1 licenses are needed to use the UL client
It’s important to emphasize that the Office apps have native support for sensitivity labels, meaning that they can apply and remove encryption and understand how the rights stated in the labels work. Many Microsoft 365 and Office 365 plans include licenses to apply sensitivity labels to Office documents or emails and store the items in SharePoint Online or Exchange Online. The need for higher-end (Office 365 E5 or Microsoft 365 E5 compliance) licenses only come into play for features like automatic policy-driven application.
OneDrive Sync Client
Co-authoring of protected files requires a recent version of the OneDrive sync client (version 19.002.0121.0008 or above). The sync client powers autosave by making sure that incremental or differential synchronization flows between the clients where changes are made back to the source document stored in SharePoint Online or OneDrive for Business. Changes made to the source document then go to other copies being edited, which prompts the apps to refresh what’s shown to the user.
In the past, the desktop apps disabled autosave for protected documents. Now, they can cope with the arrival of incremental updates for protected documents because the desktop apps understand that SharePoint Online stores protected documents in an unencrypted state (to allow features like indexing, DLP, and eDiscovery to work). SharePoint encrypts documents on download.
No Screen Captures to Prove Co-authoring Works
Because applying a sensitivity label with encryption to a file results in blocking screen captures, it’s difficult to show the effect of the change on the desktop version of Word. Techsmith’s Snagit (my personal favorite program for screen captures) and the Windows Snipping tool both produce black space where Word should be. You can’t even use the video capture feature built into Stream to create an image. This is how it should be, and I am not complaining too much. After all, you don’t want it to be too easy for people to capture details of confidential information from a screen.
Protection can’t block all attempts and I could have taken a photo with a smartphone or camera but chose not to due to the image quality. Instead, I include Figure 2 showing one side of the editing experience where co-authoring happens for a protected document. Of course, this is Word Online (Chrome knows nothing about Microsoft Information Protection and so doesn’t block the screen capture), and you’ll just have to accept that I was editing the same document with Word desktop.
Pay Attention to Label Permissions
Co-authoring only works when both authors have permissions to update a protected file. The author always has full control over a file, but the rights assigned in the sensitivity label protecting the file might block other people from making changes. For instance, it’s common to find that the rights assigned in a label include Viewer access for everyone in an organization and restricts the Co-Editor role to a limited set of users, perhaps defined in a distribution list. If a user tries to co-author a document and finds that the app displays a read-only version of the file, it’s likely because they don’t have permission to edit the file.
Import to Some but Not to All
You might never co-author a document and you might not use Office, in which case you won’t care a hoot that Microsoft has made this change. But those who do use the feature with protected documents will be happy that they can now use the desktop apps. Good as the online apps have become, the desktop apps are still where serious work gets done, which is why being able to deal with all aspects of protected documents is important.