Microsoft 365 Group Expiration Policies Have Some Business Use Case Limitations
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.’
What activities trigger auto-renewal?
According to the documentation (as of 1/13/2021):
‘The following user actions cause automatic group renewal:
- SharePoint: View, edit, download, move, share, or upload files
- Outlook: Join group, read/write group message from group space, Like a message (in Outlook Web Access)
- Teams: Visit a Teams channel’
Requirements and Environment
The requirements for our solution were as follows:
- Delete Teams Groups and their associated content after they have been ‘inactive’ for two years (730 Days)
The basic status of the Client’s Microsoft 365 Environment was as follows:
- Azure AD P2 licensing
- Available Power Automate Per User Plan license
- Many Teams Groups with varied activity
- Valid credentials with the correct permissions provided to the developers
After some brief research and the discovery of some exceptionally helpful resources we were able to craft a solution which followed these basic steps:
- 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.
Configure the Expiration Policy for Microsoft 365 groups
Add Expiration Policy to Teams with PowerShell blog post