Note: for a breakdown and overview, see the bottom of this article.
Mary works for Tailspin Toys. Excited about her new project, collaborating with a freelance artist on a new product, Mary uploads her project proposal and design documentation to a document library in a subsite dedicated to this project, and hosted in SharePoint Online. Wanting to share only this file, she breaks inheritance and grants permissions to the file to an external collaboration group, per her company policy regarding external collaboration. She then emails her SharePoint Admin, who then adds her collaborator, Abdoulaye, to the group.
Abdoulaye receives an invitation email to Tailspin Toy’s SharePoint Online tenant and clicks the accept invitation link. He proceeds through the registration process, using his own Office 365 Small Business Account (Organization Account) but gets an access denied. He copies the text of the error and forwards it on to Mary, who sends it to her SharePoint Administrator, Peter. Peter opens a support case with Microsoft, and together with the Support Engineer Alice, set up a troubleshooting session with Abdoulaye. When they ask Abdoulaye to access the file, he can access the file with no issues.
At first, Alice is leaning towards this being an isolated issue, but Peter, who has had this same exact thing happen to him twice before, forwards Mary the Service Request Numbers of the previous two interactions, mentioning that he has had reports of this prior to opening a request with Microsoft. Alice agrees that this is peculiar, and the two agree to attempt to reproduce the problem. Working together, Peter walks Alice through each step in the process.
Because Alice was able to capture a reproduction of the error, she is immediately able to access backend logs. SharePoint Online generates a significant amount of telemetry data in the form of usage logs, and there is a limited time window when the full logs are available before they are scrubbed clean of any Personally Identifiable Information. When she reviews the logs, she’s immediately able to spot the issue.
With broken inheritance subsites or items, the group has only limited access to the resources that exist higher up the hierarchy. When the invitation is being generated however, it is done not in the context of the item, which exists in a subsite below the main site, but rather in the context of the root of the site collection, where all groups for all subsites exist. Because of this, the invitation email was forwarding the user to the root of the site collection, and not the item. The invited user does not have the proper permissions to the root of the site collection, and thus gets the access denied. Subsequent attempts have the user going directly to the resource, and so it works.
Peter is now really frustrated. He wants to be able to implement an approval process to include some sort of check on external user sharing, and now he’s being told he can’t do that. However, by explaining to Alice the specific business needs he’s trying to accomplish, Alice can suggest an alternative method to satisfy those business needs, while at the same time, not having to instruct users to ignore error messages. Together, they turn to look at a different process.
We will be taking a deeper look at the way in which Azure Active Directory Business to Business (AAD B2B) interfaces with SharePoint Online in a future article that will be linked below when it becomes available. But after looking at the feature sets and process ideas suggested by Mary, Peter was not only interested in using Azure B2B to satisfy his requirements, but also excited at the possibilities for auditing and security reports available to him using his AAD Premium subscription.
Peter decided on implementing a process where the external user would receive a B2B invitation, accept that, and then be directed to the resource to which they were invited. With Azure B2B Invitation API, Peter could customize the invitation email to include instructions on what to expect as well as a privacy and consent disclaimer.
As Mary resolved and closed the latest Service Request, Peter was thankful he and Mary were able to discuss not just the technical problem that started the service request, but the underlying implementation goals that allowed Mary to direct him to a far richer and less frustrating feature set for him to accomplish the same task, with less worry and less overhead.
The next time you find yourself speaking with Microsoft SharePoint Online Support, remember to take a step back, and consider the underlying goals you’re attempting to accomplish. Perhaps your Support Representative can suggest a new or different method of accomplishing the same objective, and in doing so, help you be more successful and more efficient.
Join us next time for more on how Azure B2B and SharePoint Online interface for rich collaboration experiences that are simple and secure.
Many thanks to my Colleague, John Fulton, for the idea that led to this post.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.