Tame the chaos of sprawling Microsoft Teams and unused SharePoint sites with practical, real-world strategies. Learn how to audit your environment, implement automated policies, and prevent future messes before they start.

From Sprawl to Control: My Playbook for Taming Teams & SharePoint Chaos

I remember the day it all clicked. It was a Tuesday morning, and I was staring at a storage consumption alert from our Azure tenant that made my coffee go cold. The bill was creeping up, and fast. After a few hours of digging, I found the culprit: thousands upon thousands of SharePoint sites. But we didn’t have thousands of active projects. The sites were ghost towns, graveyards of digital collaboration. They had names like “Test Team,” “Project Brainstorm Temp,” and my personal favorite, “Planning for Dave’s Leaving Party.” Every time someone clicked “Create Team” for a five-minute chat, they were unknowingly provisioning an entire suite of resources, with a SharePoint site at its core, that would likely never be used again. That was the day I stopped treating this as a cleanup task and started treating it as an architectural problem.

First, Let’s Understand the “Why”

Before we jump into the fixes, you have to understand the root cause. This isn’t your users’ fault; it’s a feature, not a bug. When a user creates a Microsoft Team, they aren’t just creating a chat room. They are creating a Microsoft 365 Group. This is the key. That single action provisions:

• A Microsoft Team for chat.
• A SharePoint Online site for file storage (this is our main problem).
• An Exchange Online shared mailbox and calendar.
• A Planner plan.
• A OneNote notebook.

Your users see a “New Team” button. The system sees a request to build a small digital kingdom. Without governance, this inevitably leads to sprawl, security blind spots, and a storage bill that will make your finance department very, very unhappy.

Fix #1: The Manual Purge (Or, “The Weekend Warrior’s Script”)

This is the reactive approach. You’ve already got a mess, and you need to clean it up. This is where you roll up your sleeves, fire up PowerShell, and go hunting for digital ghosts. It’s not a permanent solution, but it’s a necessary first step to get things back to a manageable baseline.

The goal is to identify groups with no activity over a certain period (say, 180 days). You can use the Microsoft Graph API or the older AzureAD PowerShell module for this. Here’s a conceptual snippet using the newer Graph SDK to get you started.

# NOTE: This is a simplified example. You need to handle authentication,
# pagination, and error checking in a real script.
# Ensure you have the Microsoft.Graph module installed.

Connect-MgGraph -Scopes "Group.Read.All", "Directory.Read.All"

# Define how far back you want to check for inactivity
$inactiveThreshold = (Get-Date).AddDays(-180)

# Get all M365 Groups (which includes Teams)
$allGroups = Get-MgGroup -Filter "groupTypes/any(c:c eq 'Unified')" -All

$inactiveGroups = foreach ($group in $allGroups) {
    # Check SharePoint site activity
    $siteActivity = Get-MgReportSharePointSiteUsageDetail -Period 'D180' | Where-Object { $_.SiteUrl -like "*sites/$($group.MailNickname)" } | Select-Object -Last 1

    # Check for recent Teams chat messages (more complex, requires further Graph calls)
    # Check for recent mailbox activity (also requires more Graph calls)

    if ($siteActivity.LastActivityDate -lt $inactiveThreshold) {
        [PSCustomObject]@{
            DisplayName = $group.DisplayName
            MailNickname = $group.MailNickname
            LastActivity = $siteActivity.LastActivityDate
            GroupId = $group.Id
        }
    }
}

$inactiveGroups | Export-Csv -Path "./inactive_teams_report.csv" -NoTypeInformation

Warning: Never, ever delete a group without first contacting the listed owner. The script might say it’s inactive, but it could be holding the one file the legal team needs for an audit. Your script is for reporting; your communication skills are for actioning. Create a report, email the owners, and give them a 30-day grace period before you even think about soft-deleting anything.

Fix #2: The Grown-Up Solution (Proactive Policy Management)

Cleaning up is tiring. Preventing the mess in the first place is where we, as architects, earn our keep. This is the permanent fix. It requires an Azure AD Premium P1 license, but in my opinion, it pays for itself by avoiding the manual labor and storage costs of the first fix.

The magic bullet here is the Microsoft 365 Groups expiration policy. It’s beautiful in its simplicity:

1. You set a group lifetime (e.g., 180, 365 days).
2. 30 days before a group expires, the owner gets an email notification asking if they want to renew it.
3. If they click “Renew,” the clock resets.
4. If they do nothing, the group (and the Team, SharePoint site, etc.) is soft-deleted and can be restored for 30 days.

This single policy automates the entire lifecycle. It puts the onus on the users to justify why a group should continue to exist, rather than on IT to prove it’s abandoned.

How to Set It Up (The Gist):

You can do this in the Azure AD portal under Groups > Expiration. You can apply it to all groups or just selected ones.

Pro Tip: When you first roll this out, set a long expiration period (like 365 days) and apply it to a pilot group of users. Don’t surprise the entire organization with a 90-day deletion policy, or you’ll have a rebellion on your hands. Communicate the change clearly and explain the “why” behind it.

Combining this with a Naming Policy (e.g., forcing a prefix like `PROJ-` or `DEPT-`) can also work wonders for at-a-glance organization.

Fix #3: The ‘Nuclear’ Option (Locking Down Creation)

Sometimes, you’re in a highly-regulated environment or a situation so out of control that you need to stop the bleeding immediately. This is the “break glass in case of emergency” option: restricting who can create Microsoft 365 Groups.

Essentially, you create a dedicated security group (e.g., `M365_Group_Creators`) and configure Azure AD so that only members of this group can create new Teams/Groups. Everyone else sees the “Create Team” button greyed out.

This is a powerful but blunt instrument. I’m generally not a fan because it solves one problem by creating another. Let’s be honest about the trade-offs:

My advice? Use this option only as a last resort. For 99% of organizations, a combination of Fix #1 for the initial cleanup and Fix #2 for long-term, automated governance is the right path forward. It keeps users empowered while giving you, the engineer, the guardrails you need to keep the environment sane.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions