SharePoint Online External Sharing with Office 365 Groups

This has been nagging me for a long time, and I just found a fix! 

OK, so there are a lot of words in the title. All very Microsoft-y. I promise you, I’m writing this post on Chrome on Linux (Debian, to be exact. Screenshots available upon request.)

This post is for people who:

  • Use Office365 Groups to collaborate with, well, groups
  • Use SharePoint Document Libraries provided by Groups
  • Wish to share documents from SharePoint without requiring a login (in Microsoft language, this is considered external sharing to non-authenticated users)


…or, a Defense of Office 365 Groups and SharePoint, plus a rantlet

One of my favorite things about Office 365 is how Microsoft rolls out enhancements, new features, and bug fixes in a steady, transparent way. (I love the public roadmap.) I was very interested last year when Microsoft announced Groups as a simple way to collaborate with colleagues, including: shared conversations, document storage, calendar, notebook, and more. I decided to roll the dice and leverage Groups to support a particular organization I volunteer with. By and large, it’s been … OK. There was one rather painful issue that we resolved a few months back, but this post is not about that.

Sometimes new products from Microsoft can feel like a tangle of technologies that are generally (but not fully) coherent. There is overlap (“Hi, thanks for trying to sign in. Are you using a work/school account, or a Microsoft account?”); there is some instability (“We’re having issues, but we’re working on it.”)… Then there is a class of problems that (being kind) I will blame on having to support many different technologies — some legacy, some new — and it goes like this:

New feature A works great! Unless you’re also using Feature B, in which case Feature A doesn’t work at all. Unfortunately, we’ve been busy and we haven’t updated the documentation yet to reflect this, so we’ll give you a generic error message to puzzle through.

I seem to be pretty good at finding these issues.

The Issue – Sharing to “Anyone” is Blocked

With this organization, we have our core group of collaborators who have read/write access to content, and we need to share content with people outside the organization (external users) several times a year. The access should be read-only and it should not require a Microsoft account (or a Work/School account). If it’s able to use SharePoint’s auto-expiring links, even better. Those are cool.

Here’s what I see when I attempt to share something from the document repository:

Screenshot of Office 365 SharePoint Online External Sharing dialog

No sharing for you.

I searched and found lots of references to turning on external sharing in SharePoint Online. I checked many checkboxes that said things like “enable external sharing for all your sites!”, but somehow the option was never available to me here in this SharePoint library.

As you may have guessed — the documentation applied to SharePoint Online — but not when using it through Office 365 Groups. Ugh.

The Solution – PowerShell

I get an email once a week or so from Office 365 telling me about new features. Most recently, there was something that touched on sharing privileges in Groups. It got me thinking about this problem again, and I started looking for a solution. I came across a document (have I seen this document before? maybe in a frenzy of tabs when searching for this solution before?) that contained the answer, clear as crystal: 

The answer is PowerShell. The Cliffs Note version of the update is:

  1. Install the SharePoint Online Management Shell. That is unless you’re cool enough to already have it installed.
  2. Connect to your environment using the Connect-SPOService cmdlet.
  3. (optionally) Get your site’s current settings. I always like to see what I’m updating before I update it:
    (Get-SPOSite -Identity
  4. Perform the update. The SharingCapability you want is ExternalUserAndGuestSharing:

    Set-SPOSite -Identity -SharingCapability ExternalUserAndGuestSharing

And you’re set. Link expiration too!! Here’s the proof:

Screenshot of Office 365 SharePoint Online External Sharing dialog


How to Fix Failing Imports with WP All Import on Azure

I just spent a few hours troubleshooting this issue with running WordPress on Azure. I didn’t find anything helpful online, so I figured I’d share. This post is for people who:

There have to be some people out there who do this too, right??

The Issue – Failing Imports

If you use Microsoft’s Azure App Service to host your WordPress solution, you may have heard about WinCache:

Windows Cache Extension for PHP is a PHP accelerator that is used to increase the speed of PHP applications running on Windows and Windows Server. Once the Windows Cache Extension for PHP is enabled and loaded by the PHP engine, PHP applications can take advantage of the functionality without any code modifications.

I’ve found that enabling and configuring WinCache makes the largest improvement in WordPress performance on Azure short of page caching. It provides a big boost without the (shall we say) considerations of page-level caching.

However, it does seem that WinCache’s file caching in particular throws off WP All Import. I dug into the code a bit, and it appears that CSV uploads are converted to XML, which are output to disk and then immediately read back for processing. When WinCache’s file cache is enabled, this read-back is blank. As a result, WP All Import has no data to work with. Imports run but don’t import any data.

Importantly, even previews fail, which is how I was able to quickly test for the problem. I uploaded a trivial CSV file with the following info:




I configured a simple import to use Col1 as title and Col2 as Body, click preview, and the title field is busted:

Screenshot of WP All Import showing warning

Strangely, when I close the preview window and click to preview again, now Content is busted too!

Screenshot of WP All Import showing two warnings

Feels like a timing issue.

Workaround – Temporarily Disable WinCache File Cache

I added the following directive to the .ini file I used to configure WinCache, with a note reminding me to tweak this before and after an import. We’ll see if I remember to do that…

; uncomment before performing import with wp all import

Don’t forget to restart your app before attempting the import again. Once done, preview (and import) work successfully:

Screenshot of WP All Import showing no warnings