Policy

Microsoft 365 Group Expiration Policy Considerations

Microsoft 365 has an in-built option to expire Microsoft 365 Groups that are no longer in use. Details around this are well documented Microsoft 365 group expiration policy | Microsoft Docs – but I thought it was worth digging a bit deeper into the why and how of Microsoft 365 Group Expiration Policy. The below is my understanding of how the platform works based on personal testing.

It’s easy for an administrator to come to the conclusion that they have their Microsoft 365 Groups under control. Maybe the creation of Microsoft 365 Groups is restricted in the tenant to a subset of users, or admins only – ensuring only approved groups are created with a reasonable naming convention. Maybe that is combined with a Microsoft 365 groups naming policy | Microsoft Docs which includes blocking custom words so users can’t create another group with the name ‘Finance’ in it and create ungoverned areas.

If these controls are in place, why would you want any Microsoft 365 Group to expire? There’s the risk that a wanted group gets deleted and misses the 30 day window of recovery (maybe it’s a group used heavily only once a year for a week) and group expiration is more hassle than it’s worth?

There are a few main driving factors on why you should deeply consider enabling Microsoft 365 Group Expiration Policy:

Clean up old groups – despite having a good control of group creation and naming convention sorted, users will rarely advise when a group is no longer used or abandoned. Maybe it was a committee that fell apart when certain people left the organization – IT will rarely be across and care about abandoned groups. Although it’s messy and confusing to have a bunch of abandoned groups sitting around, there’s a bigger driver to clean these groups up;

Reduce data held – Data should be held for as short as time as possible; of course complying with data retention laws and in line with the company’s data retention policy. The more data you have, the more data you have to lose. Useful data of course should be kept for as long as it is useful, and it can be very difficult to define what data falls into this category. There’d be a faily strong argument though, that an abandoned group holds no important data (unless the group had been targeted by a data retention policy, because the data had already been classified). Hanging onto unmanaged, abandoned data is an easy way for the data to be leaked down the track. Think of a group that has guest access but nobody’s managing – that guest could come back years later and extract the data which should have been cleaned up.

Microsoft 365 Groups should have more than one owner – avoid scenarios where the 1 admin of a group departs the company and abandons is, by always having at least 2 owners of a group. If they end up being the last owner, it’s up to them to find a second one. Microsoft 365 Group Expiration Policy will handle the scenario of an abandoned group (one with no owners) by instead sending an email to a specified address in the Microsoft 365 Group Expiration Policy settings:

Source: Microsoft

Other considerations before enabling Microsoft 365 Group Expiration Policy:

Exchange licenses: All owners of groups need an Exchange license. It should work if they’re on-premises and in Exchange Hybrid mode, AND an Exchange Online license applied to the account. There are scenarios where this license component may not be enabled against an account to avoid having multiple mailboxes (one in cloud, one on-prem), so it’s worth verifying.

User awareness: Before turning this on, make sure communication is provided to end users. People have a tendency to ignore things they don’t understand or don’t think are important, and will then be complaining loudly when their group was deleted after the third email notification asking them.

Pilot: Rather than enabling this for all groups in your tenant, start with a subset of selected groups to make sure you understand how the process works. This list is limited to 500 groups.

Automatic Active Group Checking & Group Lifetime: A great component of Microsoft 365 Group Expiration Policy is the automatic checking of active groups. If a group is detected as being active, then it will auto-renew and not ask any user to verify. As noted on Set expiration for Microsoft 365 groups – Azure Active Directory – Microsoft Entra | Microsoft Docs:

When you first set up expiration, any groups that are older than the expiration interval are set to 35 days until expiration unless the group is automatically renewed or the owner renews it.

and from Activity-based automatic renewal – Azure Active Directory – Microsoft Entra | Microsoft Docs

For example, if an owner or a group member does something like upload a document to SharePoint, visit a Teams channel, send an email to the group in Outlook, or view a post in Yammer, the group is automatically renewed around 35 days before the group expires and the owner does not get any renewal notifications.

For example, consider an expiration policy that is set so that a group expires after 30 days of inactivity. However, to keep from sending an expiration email the day that group expiration is enabled (because there’s no record activity yet), Azure AD first waits five days. If there is activity in those five days, the expiration policy works as expected. If there is no activity within five days, we send an expiration/renewal email. Of course, if the group was inactive for five days, an email was sent, and then the group was active, we will autorenew it and start the expiration period again.

If you carefully read the above, there’s a few takeaways. Regardlesss of the Group Lifetime value, when you first enable the policy, it will immediately treat groups without an expiration date as being 35 days until expiration. If the group gets renewed in this window, the expiration date gets set to the current day + group lifetime value (default 180 days). It would be easy to assume that when enabling this, you’d have a 180 day window but that’s not the case.

The other big clarification is around how automatic renewal works. It doesn’t check for the entire lifetime of a group on whether it’s active or not – there is a 5 day window when the group is 35 days from expiry, to 30 days from expiry, where it will check for certain actions to automatically renew.

Microsoft 365 Group Expiration Policy is a feature worth considering and investigating, and hopefully the above gives you some other considerations that may not be clear from an initial look.

Removing Unwanted SMTP Records From Exchange Hybrid

I’m still new to Exchange Online and Office 365 mailbox management, but got stuck on this scenario for a bit.

After testing an E-mail Address Policy, I wanted to remove what the policy had done. I’d already discovered that taking an address off a policy itself doesn’t remove it from the accounts, and run this simple script to remove the unwanted SMTP record off each account. However, accounts that had been migrated to Office 365 didn’t change and still had the unwanted SMTP record.

I checked on Exchange Online itself, and the address I’d added hadn’t flowed through. I believe this was because it was using a domain that Office 365 didn’t know about – but that also meant that I had no records to change at that end. I could however go into the mailbox itself via the Exchange console and remove the unwanted record.

It turns out, that I had to use the ‘Get-RemoteMailbox’ and ‘Set-RemoteMailbox’ command in place of the ‘Get-Mailbox’ command. Although I was working with Exchange PowerShell on-premises, the mailbox type is “RemoteUserMailbox’. ‘Get-Mailbox’ against any migrated item will not find those objects that live in the cloud.

 

If you want to see which Exchange objects have a particular SMTP record in Exchange 2010, regardless of what mailbox type they are or where it lives, there’s an easy way.

Make sure the ‘Recipient Configuration’ tree option in the Exchange Console is selected, and filter with E-Mail Addresses > Contains > your unwanted SMTP record:

This will make sure all object types (including groups, contacts etc) don’t have the unwanted SMTP record.