The smell of something quite not right gathered around Office 365 Groups this week as users found that they could not access the OneDrive for Business sites used by Groups for document storage because of an obscure SharePoint Online setting.
Starting on November 14, reports flowed in that users who could access their documents in the morning couldn’t in the afternoon. The response from Office 365 support was uninspiring as no one seemed to know what was happening. The error message generated by SharePoint wasn’t exactly informative. “Sorry, something went wrong” was an understatement, but as it turns out the clue was underneath in the words “Group files can't be shown, because your organization has turned off custom script protection.” Not that this advice would mean much to the average user. Or even perhaps, to the average Office 365 administrator.
When support fails with cloud services it’s quite common to find that people turn to online forums and social media to get a better explanation. In this instance, the discussion that emerged in the Office 365 Groups section of the Yammer-powered IT Pro Network was quite revealing when a Microsoft representative offered the information that “The team that owns this UI had some issues and had the UI turned off.”
In other words, the development team ran into some problems with the Groups user interface that allows access to the files section and decided that they would make a change. The change involved forcing administrators to ensure that the setting that allows users to run scripts for personal sites is disabled.
After some behind-the-scenes complaints, a more comprehensive explanation was offered by Eric Zenz of Microsoft on November 19, five days after the problem surfaced. Posting in the Yammer group, he said:
“Group files are visible in OneDrive for Business using a cross-domain call from a user’s personal site to a group’s site
As a security measure, such a call requires custom script protection [to be] enabled on personal sites
The deployment of the UI setting for custom script protection conflicted with logic that set this setting correctly for Groups
A fix is underway, but the workaround is for a tenant to enable custom script protection. Changing the setting can take up to 24h to take effect.
Updates will be provided on the state of the fix on the network tomorrow [November 20] by noon pacific time.”
Like many Office 365 administrators who have a passing acquaintance with the finer details of SharePoint, I knew little about SharePoint’s scripting capabilities, which allow sites to be customized through the addition of user interface components like web parts. Apparently the sites used by Groups are “personal sites” and allowing custom scripts to run caused the issue referred to above.
Hmmm… In any case, to make everything work, you have to access the SharePoint Admin menu, then select “Settings” and then scroll down to the “Custom Script” section where you can disable custom scripting for personal sites. The new setting might not be effective immediately as it seems that SharePoint takes its sweet time to recognize what’s going on – but it eventually will and then files access for Groups will work again.
I genuinely like the features that Microsoft has introduced in Office 365 Groups. Sure, there are some rough edges (no support for the #1 corporate client – Outlook – for one) but I anticipate that these will be addressed over time. However, this experience makes me think that insufficient testing occurred before Microsoft decided to launch Groups into the wild. The fact that almost no management capabilities are yet available to help control the creation and spread of Groups is also regrettable.
But all of this is very much in line with the thinking that new features should be given to users as soon as the code is ready (or almost ready) on the basis that we live in a fast-paced world where people are quite happy to interact with bleeding-edge technology on a daily basis. This might be true for the millennials who exert an increasing influence over the way we work but it seems to me that this kind of thing runs counter to Microsoft’s stated goal of being the “productivity” company. No doubt someone has noticed that you can’t be productive when software fails but in case the developers who made this change haven’t, I’d like to bring this fact to their attention.
Microsoft can plead two points in mitigation for their approach. First, if you’re going to make a change that disrupts users, do it early before the feature is in heavy use. Second, the problem only affected part of the overall Groups feature and it is unlikely that many Office 365 customers had deployed Groups into production.
Both points are true. However, I believe that the lack of up-front communication about the change was regrettable as many people ran into the problem without warning. The lack of subsequent clear and explicit explanation about what was going on provided a salutary reminder of just how much control companies cede when they run software in the cloud.
Evergreen cloud-based software can deliver great benefits. Having Microsoft do all the heavy lifting to integrate the components necessary to make Exchange, OWA, and SharePoint function together in Groups is nice too. But it would be so much nicer if developers thought about the impact of the changes that they make and, if they make a change, to let us know what’s happening so that we don’t all waste time chasing our tails to find out why a feature works in the morning and not in the afternoon.
Follow Tony @12Knocksinna
