Microsoft 365 Groups Expiration Policy: Automating Cleanup Without Breaking Active Work

Microsoft 365 groups rarely die when the project ends. They linger—mailboxes fill with stale threads, SharePoint sites keep serving documents, Teams channels stay one click away—until nobody remembers who owns them. That sprawl is not just clutter: unowned groups with active guest access become a security blind spot, and search results drown in abandoned workspaces. The useful takeaway is that Microsoft 365's group expiration policy can automate the cleanup, but only if you audit ownership and exclusions first.

The hidden cost of expired projects

When a group has no owner, it has no accountable administrator. Guest members may retain access to files and conversations months after a contract ends. From a discoverability standpoint, every orphaned group adds noise to the Global Address List and SharePoint search. Manual cleanup fails because it depends on someone remembering to delete the group; expiration policy replaces that memory with a timer.

How the expiration policy actually works

An administrator enables the policy in the Microsoft 365 admin center and sets a group lifetime—commonly 90, 180, or 365 days. The policy applies to all Microsoft 365 groups or a selected audience. Before a group reaches its expiration date, the service sends renewal notices to the group owners. If an owner renews, the clock resets. If nobody responds, the group enters a grace period and is then soft-deleted.

Soft deletion matters. A deleted group is not purged immediately; it remains in the recycle bin for 30 days. During that window, an administrator can restore the group and its connected resources. After 30 days, the group and its contents are permanently removed.

What the policy does not cover

Expiration policy is not universal. Dynamic groups—those whose membership is driven by Azure AD rules—are typically excluded, as are certain groups created by services. Policy changes apply to new and existing groups, but existing groups may not reflect a new lifetime until the next evaluation cycle. Owners must also have valid, routable email addresses; an unowned group can be deleted without a renewal prompt.

Because service behavior evolves, verify current default lifetimes, notification cadence, and service-specific exclusions in the Microsoft 365 admin center or current Microsoft documentation before broad rollout.

Audit before you flip the switch

The safest way to adopt expiration policy is to find the risky groups first. You need to know which groups have no owners and which already carry an expiration date. The following diagnostic uses the Microsoft Graph PowerShell SDK.

Pre-flight check with Microsoft Graph PowerShell

# Run in PowerShell 7+ or Windows PowerShell 5.1 with the Microsoft Graph PowerShell SDK installed.
# Requires delegated consent for Group.Read.All and User.Read.All.
# Connect first: Connect-MgGraph -Scopes "Group.Read.All","User.Read.All"

$groups = Get-MgGroup -All -Property "id,displayName,mail,expirationDateTime,groupTypes" `
  -Filter "securityEnabled eq false and mailEnabled eq true"

foreach ($g in $groups) {
    $owners = Get-MgGroupOwner -GroupId $g.Id -All
    if (-not $owners) {
        [PSCustomObject]@{
            DisplayName    = $g.DisplayName
            Mail           = $g.Mail
            ExpirationDate = $g.ExpirationDateTime
            OwnerCount     = 0
            Action         = "Assign an owner or exclude before enabling expiration"
        }
    }
}

Expected checks: Groups with zero owners are candidates for silent deletion. If ExpirationDateTime is populated, the group is already under policy evaluation; if it is null, the policy may not apply yet or the group is excluded.

Relevant risks: Large tenants can trigger throttling; process in batches or use server-side filtering where possible. Missing consent scopes return 403 Forbidden. Cmdlet parameters vary by module version—verify with Get-Help Get-MgGroup.

The trade-off: automation versus active context

Expiration policy treats silence as consent to delete. That works for abandoned groups, but it can break active work. A Teams team or Planner plan backed by an expiring group may hold live project context even if the owner is on leave and misses the renewal email. Exclusions are therefore necessary for high-value groups, automated provisioning pipelines, and any group tied to a compliance or eDiscovery workflow.

Restoration is not always seamless. While the group itself is recoverable for 30 days, some linked resources—Planner plans in particular—may behave differently after restore. Treat the recycle bin as a safety net, not a backup strategy.

A practical rollout path

1. Pilot first. Enable the policy for a single test group or in a non-production tenant to confirm renewal email delivery and deletion timing.
2. Set a conservative lifetime. Start with 365 days and a monitored contact email so you can observe the notification flow before shortening the window.
3. Assign owners. Use the audit above to give every critical group at least one owner with a valid mailbox.
4. Exclude ineligible groups. Add dynamic groups and service-created groups to the exclusion list.
5. Verify recovery. When the first soft-deleted group appears, restore it and confirm that Teams, SharePoint, and Planner content returns intact.

Group expiration policy is a governance control, not a set-and-forget switch. The groups that hurt you most are the ones nobody owns; the groups you cannot afford to lose are the ones actively in use. Audit the difference, then let the timer run.