One of the most awesome preview features today for Office 365 is the ability to set an expiration policy for the Office 365 Groups. Cleaning up old and unused content is something all organizations want, but people are inherently afraid of deleting content and thus become document hoarders. I truly believe this feature might help organizations finally rid themselves of old crap cluttering up all the good stuff.
Note: Groups expiration policy is a premium feature requiring all users in affected groups to have an Azure AD Premium license, and in my opinion this might be a good reason to invest AAD premium.
Currently each tenant support one expiration policy, and you have to decide if this policy should apply to all Office 365 Groups or only to a select number. I expect more policies to be possible in the long run, but one step at a time.
If you opt-in to include all Office 365 Groups in the expiration policy you are in the clear, and really don’t have to read the rest as it’s all automated for you :)
Still here? This means you don’t want all groups to have automatic expiration, and a common scenario indeed. You might have Office 365 Groups for departments, divisions, products etc., content which is long lasting and should never expire. And I’ll clue you in in case you want to skip to the good stuff, Option 3 is the best solution for now – until API’s and access change.
And this is where you really have to decide on your options, as the only way to include/exclude a group from an expiration policy today is to perform the action as a tenant administrator user. Yes, that’s correct – a global admin for everything Office 365. Really?? Yes, really :)
Option 1 – Manual assignment by a global tenant admin
Every morning a tenant admin of your choice can figure out which new Office 365 Groups have been created, and using either the Azure Portal or Azure PowerShell commandlets he/she can include the group in the policy.
My guess is you don’t like this option, so let’s take it one step further.
Option 2 – Create a tenant admin account with non-expiring password (and no MFA) which you use in a script/job
You hate manual work, and instead you create a separate service account which is global admin, stuff the username and password in Azure Keyvault, and let a script or similar access the credentials and automatically add Office 365 Groups to the policy based on business rules using either PowerShell or calls directly to the Microsoft Graph.You can create logic based on group naming or custom metadata (http://www.techmikael.com/2017/09/introducing-generic-all-mostly-purpose.html), and then enroll the ones matching your logic. This way department and division groups won’t be enrolled, while projects with an end date will.
My bad! You don’t like the fact that you need to create a God All user for this single purpose? Neither does my current customer and I have to agree it has a foul taste to it. I’d rather allow an ADAL application or a managed service identity in an Azure Function to be granted this right, but don’t worry. Currently that’s not possible, so let’s move on to the third option.
Option 3 – Enroll all groups, and then auto-renew the ones which should last forever
Reading the Microsoft Graph API documentation on renewing groups, meaning you extend expiration for another cycle, it states that you need Directory.ReadWrite.All delegated permissions. In layman’s terms this means you have to be a tenant admin to perform the operation. “What?? I thought you recommended option 3. Are you pulling my leg or what?”.If you have tested this functionality for yourself you know that as a group owner you will receive an e-mail to extend the lifetime of your group. And when clicking the Renew group link, the group is indeed extended.
Renew e-mail
Renew confirmation web page
And fortunately for us, the documentation is wrong. You can may indeed renew a group with both Group.ReadWrite.All or Directory.ReadWrite.All permissions. And it works both with delegated and app-only permissions.
This means that you can create a script to run on a schedule which loops over all your Office 365 Groups, or the groups you decide to filter in, and then automatically extend the period for those Groups, preventing the owners from receiving e-mails and taking explicit action.
Sure, it’s not the ideal solution, but at the current state of the Office 365 and Azure nation, this is probably the best option for now.
The Azure AD command for renewal is Reset-AzureADMSLifeCycleGroup in case PowerShell is your management poison. Also take a look at Using a Service Principal to connect to a directory in PowerShell for how to set up ADAL application login for the Azure AD commandlets.
If you prefer Microsoft Graph API's, you can you issue the following REST command currently on the /beta endpoint.
POST https://graph.microsoft.com/beta/groupLifecyclePolicies/renewGroup
Content-type: application/json
Content-length: 57
{
"groupId": "ffffffff-ffff-ffff-ffff-ffffffffffff"
}Summary
Ever since the stone age people have been hoarders, and hoarding makes it hard to find the good stuff. Having content automatically expire might be a good way to rid yourself of unwanted/unneeded content - much like your neighbor's ugly flowers which you forgot to water over the summer.Using an Office 365 Groups expiration policy might turn up to be one of the best features yet to be shipped for Office 365 Groups, allowing the organization to decide what should stay, and what should go. The API's and functionality is there, but at the current state, a bit quirky to get working in an ideal way - especially if you want to tack it onto a controlled self-service version of creating Office 365 Groups.
References
- https://docs.microsoft.com/en-us/azure/active-directory/active-directory-groups-lifecycle-azure-portal
- https://docs.microsoft.com/en-us/powershell/azure/active-directory/signing-in-service-principal?view=azureadps-2.0
- https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/api/grouplifecyclepolicy_renewgroup
