Performing eDiscovery Against a Specific Folder
One common request when performing an eDiscovery or using the Search-Mailbox cmdlet has long been...
Over the past few months, some significant improvements have been made around the external sharing functionality in Office 365. Some other very important features were introduced as well. The marketing teams at Microsoft, however, were more focused on getting the message for the new and improved OneDrive for Business (ODB) client out, so no big announcements or press focused on these sharing improvements. With that in mind, I decided to do a quick recap to put together an updated list of important improvements that everyone should at least know about.
First of all, we finally have the option to control external sharing on per-user level with OneDrive for Business. Up until recently, this was an “all or nothing” approach – while one was able to control this on the parent -My site collection, the settings configured on this level applied to each user’s personal site collection. With the latest changes, we can now control this per ODB site collection via PowerShell:
PS C:\> Set-SPOSite https://tenant-my.sharepoint.com/personal/user_domain_com -SharingCapability Disabled
As the individual ODB site collections are still not exposed in the SharePoint Online Admin center, this can only be configured via PowerShell. Note that the inheritance from the parent SC or the tenant-wide settings still applies. The External sharing settings for individual site collections cannot be less restrictive than the settings configured on the tenant level or the -My site collection, but these settings can be more restrictive. For example, if you have disabled External sharing in one of those places, the per-user settings will not have precedence and if you try to enable any kind of External sharing you will get an error like the one below:
PS C:\> Get-SPOTenant | fl SharingCapability
SharingCapability : Disabled
PS C:\> Set-SPOSite https://tenant-my.sharepoint.com/personal/user_domain_com -SharingCapability ExternalUserAndGuestSharing
WARNING: The SharingCapability set for this SPOSite will not take effect until the 'ExternalUserAndGuestSharing' SharingCapability is also enabled on the SPOTenant.
Set-SPOSite : You can't set the sharing capability to the level you specified, because it is a less restrictive setting than either its parent site collection or your organization.
At line:1 char:1
+ Set-SPOSite https://tenant-my.sharepoint.com/personal/user_domain_com -Sharing ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Set-SPOSite], ServerException
+ FullyQualifiedErrorId : Microsoft.SharePoint.Client.ServerException,Microsoft.Online.SharePoint.PowerShell.SetSite
In effect, if you are trying to configure the “disable sharing for everyone apart from a few specific users” scenario, you need to use a different approach – leave external sharing enabled on the tenant level and disable it on the user level for everyone except those few users. This can easily be automated via PowerShell and CSOM.
The opposite scenario, “enable sharing for everyone apart from a few specific users,” is much easier to accomplish now. Previously, we had to resort to workarounds such as removing the Site Collection Administrators role for the user and granting him some customized permission level (and breaking his personal site as a result of that :)). Now, it’s as easy as running a simple PowerShell cmdlet. In any case, the increased control that we have over the external sharing feature for ODB is welcome!
Next, we have the “Turn off sharing for non-owners on all sites in this site collection” feature. Enabling this feature basically restricts sharing invitations to only Site Owners and Site Collection Administrators.
To actually configure it, you can use either the GUI or PowerShell. Navigate to the SharePoint Online Admin Center and the Site collections node on the left, then select the site collection in question and press the Sharing button on the ribbon. The Sharing dialog will pop up, with a new section in the middle giving you a short description of the feature and its current status. To enable the feature (and disable sharing for non-owners), click the “Turn off sharing for non-owners on all sites in this site collection.” hyperlink (see the screenshot on the right).All other users will be only be able to share with users added to the site already (either internal or external) and are not allowed to invite new users. This is a one-way street– if you turn this feature on, there is no going back.
Alternatively you can configure the feature via PowerShell. This is done using the –DisableSharingForNonOwners parameter for the Set-SPOSiteWindows PowerShell cmdlet.
For example:
PS C:\> Set-SpoSite –Identity <URL> –DisableSharingForNonOwners
Once the feature is configured, it’s strongly recommended that you avoid breaking inheritance of permissions in any of the sub-sites under a given root site. This ensures that the allow non-owners sharing setting is consistently applied across all (sub-)sites. Breaking inheritance is always frowned upon in the SharePoint world, but now you have another reason to avoid it. And again, a reminder that this is a one-way street, no going back is possible!
The list of recent changes doesn’t stop here. Another set of improvements was focused on “ease of use”. This basically included a refresh of the sharing dialog and the introduction of company-wide links (that is a link that can be accessed by anyone inside the organization).
Company-wide links eliminate the need to have users added in advance, while at the same time providing you peace of mind that the file cannot be shared outside of your organization. You can send this link to anyone internally who can then forward it to others as needed; however, external access is not possible.
Along with these, on the security front we got the ability to set a mandatory expiration limit on guest links. While the end users are presented with the opportunity to configure link expiration upon sharing the document (or editing the link later on), this is not mandatory and the user can choose to configure a link with no expiration. We can however configure a limit on the validity of such links via the Set-SPOTenant cmdlet and the RequireAnonymousLinksExpireInDays parameter.
For example:
PS C:\> Set-SPOTenant -RequireAnonymousLinksExpireInDays 45
This limit will apply to both existing and newly created guest links. The acceptable values are between 1 and 730 days. To remove the limit, one can use:
PS C:\> Set-SPOTenant -RequireAnonymousLinksExpireInDays $null
Configuring a limit will also make it mandatory for the users to specify an expiration for given link upon creation.
Another great addition is the ability to “kill” any active sessions a given user might have. Why is this important? Because disabling a user account doesn’t immediately revoke access for said user. This is a well-known issue even in the on-prem world, caused by the different types of content or token caching performed on frontend and backend servers. In the cloud, the delay between disabling a user account and actually stopping the user from accessing your data can be even longer due to dependency on dirsync and the lack of control we have on the underlying infrastructure.
In other words, if you want to immediately revoke access for a specific user, you need to follow a certain procedure. What about SharePoint though? Until recently, there was basically nothing we can do but wait for the sessions to expire. With the latest version of the SharePoint Online module for PowerShell (16.0.4727.0 or above), we can now use the Revoke-SPOUserSession cmdlet to immediately invalidate any sessions. To use the cmdlet, you need to login as admin via the SPO PowerShell module and simply provide the user name:
PS C:\> Revoke-SPOUserSession -User baduser@domain.com -Confirm:$false
We successfully signed out baduser@domain.com from all devices.
Simple as that. And great new addition to the service!
Here’s also a short recap of other useful features introduced in the last year or so, in no particular order:
I’m sure I’ve missed a thing or two in the list above, but the changes are impressive. There’s still room for improvement, especially when it comes to reporting on all the shared files within the tenant or all the files a given external user has access to, etc. The situation is even worse if we consider ODB, and few Microsoft partners have already released products that can help on that part. But at the end, slowly but surely, Microsoft is going into the right direction. Personally I expect a lot more improvements in the coming months!
Vasil has been actively involved with Office 365 for over four years now. He spent over an year as Support Engineer for Microsoft Online Services with one of Microsoft's vendors, working with BPOS and Office 365 customers. Switching sides, he later held support positions with several multinational enterprises, before finally moving to a consultant role. This varied experience allows him to have an unique perspective on the ins and outs of the Office 365 suite. He has closely followed the evolution of Microsoft's cloud offerings, starting with BPOS, with expertise covering all stages of the Office 365 lifecycle. He holds a charter member certification for Office 365 (MCITP and MCSA), and has been awarded as Microsoft MVP for second year in a row.
One common request when performing an eDiscovery or using the Search-Mailbox cmdlet has long been...
It’s been a while since we covered SharePoint Online and OneDrive for Business, and some major...