A client ran into a seemingly odd issue within SharePoint Online recently. The user was an Owner of the Microsoft Team and wanted to setup alerts on a specific folder within one of the Channels within that team. Being a “SharePoint savvy” user they knew they could setup the alerts for their users via the SharePoint Site Collection used to store the Teams files, however when they attempted to setup alerts for a few of their guest users, they were unable to do so. Fortunately, we have access to this client’s Azure AD Administration which made this was a very quick issue investigation.
A quick glance at the permissions on the SharePoint site showed that the guest users in question did have the appropriate permissions assigned to access the folder, which ruled that out quickly, and was essentially the “aha” moment on our end. The client was certain the issue was related to guests not being able to utilize the alert functionality however we knew that was not the problem, as other guests in their tenant had subscribed to alerts and we see it done frequently. We threw that red herring to the side and jumped right into Azure AD Administration to confirm our suspicions.
As expected, the guest users the client was unable to setup for alerts in SharePoint had not accepted their initial invite and never logged into the client’s Microsoft 365 environment. SharePoint knew who they were because they were granted access, but because they never logged into the tenant the details about those guests were never “confirmed” by the system. This meant that there was no way to setup the SharePoint Alerts for them until they accepted the invitation and logged into the client’s site which is the expected requirement, at least from a technical standpoint.
Ultimately, this is likely a “one-off” scenario, but it emphasizes one of many potential issues with guest access scenarios in Microsoft 365. Thankfully, the user reached out when they did as they were investigating workarounds with Power Automate Flow. A quick email to the guests to accept their invite versus creating unnecessary Flows was a definitive win for everyone involved😉.
Interactive Business Systems is now Planet Technology. Looking for a new job? We work with some of the biggest names in tech, and we’re hiring! Check out our open jobs and make your next career move with Planet.
Recently we were asked by a client to create a solution to automate the removal of Teams Groups in their environment that are inactive for longer than two years. Microsoft Admin Tools in conjunction with PowerShell cmdlets like Get-Team allow us to easily apply a Microsoft 365 Group Expiration Policy to each Team programmatically. This seemed to represent an ideal solution for our client, however its implementation was eventually canceled due to challenges caused by its limited viability and testability for several crucial business use cases.
This post covers our solution for the automated application of Group Expiration Policies to Teams Groups in a Microsoft 365 Environment, as well as the limitations of the current implementation and documentation of Group Expiration Policies for several crucial business use cases.
We will briefly outline our customizable solution as well as the solution requirements to explain the business use case limitations of the current Expiration Policy implementation.
To better relate its use case limitations, we will briefly outline the key features of the MS 365 Group Expiration Policy. The complete documentation for the configuration of Expiration Policies is found here.
What does the Expiration Policy do?
You can manage the lifecycle of Microsoft 365 groups with an Expiration Policy. According to Microsoft’s documentation (as of 1/13/2021):
‘Once you set a group to expire:
Groups with user activities are automatically renewed as the expiration nears.
Owners of the group are notified to renew the group, if the group is not auto-renewed.
Any group that is not renewed is deleted.
Any Microsoft 365 group that is deleted can be restored within 30 days by the group owners or the administrator.’
Create a Group Expiration Policy in the Azure Active Directory Admin Center
Group Expiration Policies will automatically delete Microsoft 365 Groups which are inactive for longer than the set Group lifetime (in days). After navigating to the proper location in the Azure Active Directory Admin Center -> Groups tab, we created the Group Expiration Policy for this tenant.
To suit our requirements, we set Group Life to 730 days.
We set the ‘Enable expiration…’ toggle to Selected, as we only wanted to add Microsoft 365 Groups which are associated with Microsoft Teams. The initial ‘Selected’ list was empty. After we added our Teams Groups with PowerShell in the next step they appeared in this list and could the managed from this interface.
Apply Group Expiration Policy to Teams Groups using PowerShell
After retrieving a collection of Teams Groups with the Get-Team cmdlet, along with a reference to the Expiration Policy we just set, we were able to apply the Expiration Policy to whichever Teams we choose.
Using Get-Team to retrieve a collection of all Teams Groups:
Retrieving the Expiration Policy Id from the Azure AD:
Applying the expiration Policy:
Limitations of the Current Group Expiration Policy Implementation
We have shown that we could easily apply a Group Expiration Policy to whichever Microsoft 365 Groups we wished. The Microsoft 365 Admin tools also provided us with usage reports, which gave us an idea of which groups would be immediately be flagged by the Expiration Policy for deletion upon application. This solution would have been a great fit for our client if we did not run into serious limitations of the Expiration Policy implementation and documentation once we reached the testing phase of our project.
Renewal Notification Email Use Case
Once a group has neared it’s it’s expiration date due to inactivity, a renewal email is sent out to the group owner at 30, 15, and 1 day(s) priror to the expiration of the group, allowing them to manually renew the group.
If the owner, willfully or not, ignores the renewal emails, the group reaches its expiration date and is deleted.
A rightfully curious owner receiving the renewal email, who, by our explicit definition, has not been active in the group for nearly two years, may decide to view what content is associated with the group to evaluate whether it should be renewed. Regarding Teams Groups, according to the Expiration Policy documentation as of 1/13/2021, the act of investigating content in this way will automatically renew the group.
If an owner has investigated their group in this manner and has decided that the group should indeed be deleted due to inactivity, the ‘Group Lifecyle’ date has already been extended 730 days, meaning deletion of the inactive Microsoft 365 group will have to be done by other means. This did not suit the needs of our client.
It is possible that once a notification email is sent out for group inactivity, activity-based renewal is halted until receiving manual renewal confirmation. There is no reference to this use case in the official documentation or Microsoft 365 developer ecosphere, so it was impossible for our team to verify this assumption without explicitly testing the expiration of a group.
Uncertain of the usability of Group Expiration Policies, and with no clear path to test our assumptions about these use cases, progress on our implementation ceased.
The existing technology supporting a feature like Group Expiration Policies is extremely developer friendly and powerful. The interaction with the various Microsoft 365 groups and policies in PowerShell is seamless and intuitive. However, documentation of the Group Expiration Policy feature itself is somewhat wanting and the Group renewal activity triggers are perplexing to say the least.