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 16.47.218.0 (Mac).
Tenant Configuration
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.
We’ve been able to co-author work on the same protected Excel file here, even with users simultaneously on the O365 browser app and the desktop app at the same time, but ran into issues when we tried to unprotect the sheet to add information and protect again. I know that a sheet can’t be unprotected in the browser app, but even when our desktop app user unprotected it on their end, the file was still protected for the browser app user and we tried a few more things where ultimately a new copy was created in the OneDrive folder. Is this a hard stop for us that will force all users to use the desktop app? That’s the operating preference, but not the financial one yet.
When you say unprotect, do you try to remove the label from the document? If so, you might be running into a conflict condition between the desktop client and the online client and the way they’re using autosave to update the content in OneDrive for Business. Generally speaking, co-authoring works well while the encryption settings remain the same. SharePoint and OneDrive store the files in clear and encrypt on download. When you change a label with one client, the other client might think that the existing label and encryption remains in force and this causes the problem. It’s just a gut feeling on my part. You could ask the Microsoft Information Protection team on https://www.yammer.com/askipteam/ to see what they say!
Thanks for that reply! Yes, co-authoring has worked great between the browser and the desktop apps when the protection isn’t changed, but there will be times a manager needs to unprotect it to add/change protected info at the same time that team members are entering data into permanently unprotected cells, and that seemed to fail. I’ll say that “unprotecting” in this case means going to the Review ribbon and clicking on Unprotect Sheet in the Protect section of the ribbon.
So unprotect hasn’t anything to do with the sensitivity label… Maybe it’s just a scenario that wasn’t well tested. Worth saying it to the MIP team.
Great article,
i have all the co-authoring working online but still cant get the autosave feature to work 🙁
my OD version is updated, also my OFFICE is the latest 2105.
any tips ?
Presumably all the files you’re working with are stored in SPO or OneDrive? That’s a fundamental requirement for autosave (with desktop Office).
Thanks Tony. what about synced SharePoint site using OneDrive in file explorer. can we still use AutoSave setting on Office desktops apps?
I do that all the time.
Thanks, Tony, we keep receiving
I keep receiving the below messages when I tried to switch on AutoSave on synced SharePoint site or even when opening directly from SharePoint on desktop apps.
—-
This file has restricted permissions applied, please remove the permissions.
This file needs to be saved in the cloud-first.
—-
– The user has M365E5 license assigned.
– Co-authoring for files encrypted with sensitivity labels is enabled.
– M365 16.0.14326.20936.
– OneDrive 2022.
– No UL client installed.
Any thoughts?
The setup sounds OK. The error says that the file must be saved in the cloud first and is complaining about permissions. Can you remove the label, save the file, and then reapply the label?
I tried to remove and re-apply the label but no luck. Do you think it’s related to label permissions (Co-author – Co-owner) or something else?
Thank you so much!
The fact that you can’t remove the label means that you don’t have the rights to remove it. Who applied the label? Try doing this with a document where you apply the label and have author rights.
Issue is resolved and was related to M365 Apps version and update channel.
Great. Thanks for letting us know!
I can’t remove the label because of the applied label policy “Require users to apply a label to their email and documents”,
However, when I downgraded the label to a label with no encryption AutoSave started working and when I label it with a label with encryption the AutoSave will show that warning message.
Something screwy is going on. Given that I can’t debug your tenant, I suggest that you create a support incident and have Microsoft check things out. You’re paying them for support, so you might as well use it. And they have access and insight to way more data than you can communicate here.
Ok. Thank you Tony! Much appreciated!
Good article, many thanks for sharing – interestingly when i enable this setting (which i did through the GUI and also checked via PS) I still can’t co-author and autosave with Word documents on our test accounts. I’ve logged a call with MSFT to see what might be wrong.
How odd. I am co-editing with both Word and Word Online right now for a protected document stored in SharePoint Online…
Good to know it’s working – we’ve checked Office versions and any other pre-requisites but nothing we see that’s missing – we will try recreating a label to see if that makes a difference. Thanks for the reply…
More testing – didn’t work with Office 2103 or 2104 but did with 2105 – still waiting to hear from MSFT but when reading it suggests that 2103 should be ok…early days but will post results here when concluded
Interesting. Remember that each version has multiple builds, so the functionality might depend on a certain build. I can report with certainty that everything works just fine with Version 2105, build 14026.20164, which is what I am using right now.
What happens if an external user (other tenant) has been assigned as a co-author and the originating tenant is no longer available? We are in the process of migrating protected documents and emails but will need to retire the original tenant at some point.
If you plan to retire a tenant, you should remove the labels from protected documents before moving to the new tenant and reapply labels based in the new tenant. Otherwise once the old tenant disappears, no one will be able to authenticate and access the documents. See https://office365itpros.com/2021/03/25/decrypt-sharepoint-online-documents-graph/ for a script which can help you to remove labels.