SharePoint Sharing Involved Only – Not Microsoft 365 Groups
Sometimes Microsoft publishes text in message center notifications that is, to be blunt, misleading. Such is the case for MC220791 published August 21, 2020, updated May 7, 2021 (Microsoft 365 Roadmap item 43797). You can see from the dates that this change has been bubbling up for a long time. It is now available in Office 365 tenants, and it’s a good change because it allows organizations to control how long people outside their tenant can access content in SharePoint Online sites and OneDrive for Business accounts after gaining that access. In other words, you can cut off everlasting access.
Explaining the Guest Expiration Policy
Here’s how Microsoft explains the change:
@In order to better manage sharing, tenant admins will be able to create a policy to revoke guest access to SPO sites and individual OneDrives after a defined period of time. With this policy, you can limit guest user access; thus guests who are no longer active partners will not retain indefinite access to documents and files.
- This policy is not retroactive; it does not apply to guests who already have access to sites, documents and files.
- The policy applies to a user’s access to a given SPO site or individual OneDrive. When the access period reaches your policy threshold, such as 10 days, then the guest loses access to all content in that site. Guest access expires on a site-by-site basis, determined by when the guest was granted access to each site, whether that is an SPO site or an individual OneDrive.
- After a guest loses access to a site, any user with the ability to share content externally can re-invite the guest to each document or item as needed.”
The first thing that came into my head after reading MC220791 was “what about guest access to SharePoint Online files gained through membership of Microsoft 365 groups and teams?”
The only documentation I could find said:
“Guest membership applies at the Microsoft 365 group level, therefore guests who have permission to view a SharePoint site or use a sharing link may have also access to a Microsoft Teams team or security group. Therefore, when SharePoint site or sharing link access expires, some guest users may still have access to a Team or security group elsewhere.
The guest expiration policy only applies to guests who use sharing links or guests who have direct permissions to a SharePoint site after the guest policy is enabled. The guest policy does not apply to guest users that have pre-existing permissions or access through a sharing link before the guest expiration policy is applied.
Guest user expiration policy applies to guest users only. Standard user expiration can be set manually on any user in a site collection, and any user with an expiration value will be removed when the expiration passes unless they are site admins, in which case the expiration will be deferred until they are no longer site admins, or expiration value is cleared for them.”
The text isn’t very clear, but it can be read to imply that guest members of group-enabled SharePoint Online sites are affected by the guest expiration policy. Thankfully, the policy is not retrospective, but if guest members of groups and teams are within scope, the implementation of a guest expiration policy for a tenant could have an unexpected side-effect.
No Effect on Microsoft 365 Groups and Teams
I checked with Microsoft, and they confirmed that the guest expiration policy has no effect on guests belonging to Microsoft 365 groups and teams. The policy is directed solely at:
- Sharing links created to allow guest access to documents, folders, and lists.
- Changes made to SharePoint group membership for a site (not Microsoft 365 group membership).
- Direct permission changes made to allow access to content for guest users.
If your usage of SharePoint Online is mainly for document management for Microsoft 365 groups and teams, you probably never update the SharePoint group membership for a site or add a direct permission for a guest, so sharing links might be the only element affected if the tenant implements a guest expiration policy.
Implementing Guest Expiration for SharePoint Online Sites
As is usual for SharePoint Online settings, the guest expiration policy comes in a general tenant setting which can be overridden on a site-by-site basis. To create the tenant-wide policy, go to the Policies section of the SharePoint Online admin center, select Sharing, and open More external sharing settings. You’ll then see the option to enable the policy to control Guest access to a site or OneDrive will expire automatically after this many days. To enable the policy, set the checkbox and select an expiration period of between 30 and 730 days.
The new policy applies to any new sharing links, group changes, or direct permissions made afterwards. You can also use PowerShell to control the policy. This command sets the policy for a 60-day period:
Set-SPOTenant -ExternalUserExpireInDays 60 -ExternalUserExpirationRequired $True
Make sure that you download and use the latest version of the SharePoint Online management module from the PowerShell gallery. At the time of writing, the latest version is 16.0.21411.12000, which is what I used for testing.
Site-Specific Expiration Settings
Global and SharePoint administrators can change the policy for an individual site through the SharePoint Online admin center (select the site and update its policy settings as shown in Figure 2). The guest expiration settings only appear if the sharing setting for the site allows external sharing.
Alternatively, you can use PowerShell to apply a site-specific guest expiration setting. This command updates a site to set the maximum expiration period:
Set-SPOSite -Identity "https://office365itpros.sharepoint.com/sites/brk3001" -OverrideTenantExternalUserExpirationPolicy $True -ExternalUserExpirationInDays 730
During testing, I noted that the SharePoint admin center and individual site settings sometimes didn’t synchronize after making changes with PowerShell. This is likely to be due to cached data. Things will settle down eventually and all components will agree about the expiration period.
Changes made to apply guest expiration at the tenant or site levels apply only to new sharing after the policy becomes effective. Sharing expiration never applies to tenant accounts.
What Site Administrators Do
Site administrators cannot change the tenant-wide guest expiration settings and are limited to managing the extension or removal of access for guests, accessed through Site permissions and then Guest expiration. If a previous tenant-wide policy was in place which might have affected guest access, you’ll see a warning to that effect (Figure 3). A site administrator can extend guest access at any time up to the point it expires. Once expiration happens, it happens, and the guest will need a new permission to access whatever content you want to share with them.
Value Depends on Your Perspective
If you’re used to traditional SharePoint and operate sites for more than Microsoft 365 groups and teams, you’ll probably find value in the guest expiration policy. It’s certainly something worth including in your organization’s data governance best practices. But if SharePoint Online activity in your tenant is dominated by Microsoft 365 groups and teams, then guest access to information remains unaffected by this policy. In that case, you could choose to ignore it or go ahead and set a long expiration period (like 120 days) for the tenant.
I found in a lab environment that the policy is, in fact, retroactive. Any previous guest accounts that had access are also affected when enabling the policy. Any idea if the way this policy has changed since you posted this article?
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
No idea. It’s been two years since the article appeared.
Hi Tony.
Thanks for this explanation, really helpful – do you know of a straightforward way to revoke guest access to a site for an individual before the access expiration date kicks in please? I would like to revoke guest access to a couple of users before then
The easiest and quickest way is to remove the guest accounts from Azure AD. That might be a tad drastic too, but it will work.
Hi,
We have E3 licence. How can we get expiration option available, when sharing files with guest users?
Thanks
Can we notify the Site Owner for Guest Expiry ? Lets assume only Administrators are added in Site Collection Admin.
What details will the notification email triggered to Site collection admin will have?
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
I don’t believe so.
Great article Tony.
You mention in a comment above that it will affect sharing granted to guest accounts because “SPO is integrated with Azure AD for B2B collaboration”. Does this mean the AD B2B collaboration is different to guest access via an M365 Group?
External collaboration is so confusing as there are many ways to achieve it.
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
What I mean is that SPO can be (I believe it’s still optional) integrated with Azure B2B collaboration (see https://office365itpros.com/2021/08/17/sharepoint-online-embraces-azure-b2b-collaboration-external-sharing/). When this is configured, guest accounts are created each time someone shares a document or folder. These guest accounts are liable to the expiring access policy. Guest accounts created by Microsoft 365 groups and used to share documents with group members are not.
Thanks Tony…..I’m unsure if there is any article on Direct Sharing vs Guest Sharing. As their seem to be good enough change on how the Direct Share gonno work agaist the Guest User Sharing. We can have all the policies / controls / reviews when it comes to Guest Users….but Direct Sharing will work with out such controls in place. Do you agree?
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
The expiring access policy works for direct sharing only. It doesn’t affect the access guests obtain through group membership. It would affect sharing granted to guest accounts when guest accounts are created because SPO is integrated with Azure AD for B2B collaboration (as it should be).
Does this setting affect Microsoft Teams. Since SharePoint is part of the teams.
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
No. Guests who have access to SPO via Teams aren’t affected (as stated in the article).
Thanks Tony for your thorough investigation!
Do you see an easy way to ensure that expiration policy is applicable to OneDrive only? I understood it would naturally happen if all SPO sites were linked to O365 groups, but we are not there yet.
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
I don’t know if it will be possible to confine this policy to OneDrive for Business. My sense is that it will apply across OneDrive for Business and SharePoint Online.
Is this triggered by guest user inactivity, or purely since account creation?
Inactivity would make sense, you wouldn’t really want to pull the rug out from under people happily working together! (or maybe there’s a setting that controls this behaviour?)
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
I believe it’s a simple date check. Activity (or lack thereof) doesn’t seem to come into it. If you want guests to have long term access to shared information, set a suitable expiration period for the site or use a site connected to a Microsoft 365 group.
I have a PowerPoint SlideDeck, that show the renewal Process, and there i see diffrent timelines, when the renewal process begins.
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
Care to share more information? I checked the information with the SharePoint product group before publishing and they confirm what I have described.