You ran a cleanup. Deleted old files, cleared some recycle bins, maybe even archived a few sites. Then you checked your storage and the number barely moved.
That's not a failure of effort. It's a signal that the biggest contributors aren't where most admins are looking.
Version history, recycle bin lag, and the Preservation Hold Library get most of the attention in storage conversations, and they matter. But two culprits consistently fly under the radar because standard admin tooling doesn't surface them obviously: SharePoint Embedded containers and meeting recordings.
This post covers both: what they are, why they don't show up where you'd expect, and what to do about them.
If you want the full picture, we covered all of it live in a recent webinar:
Most admins are familiar with the SharePoint/OneDrive split: SharePoint sites draw from a shared tenant pool, OneDrive runs on separate per-user allocations. Overage charges hit the tenant pool, so SharePoint tends to get the governance attention.
What's less well-known is the third category: SharePoint Embedded (SPE) containers. These are storage units created by Microsoft apps and third-party tools that run on SharePoint's infrastructure. They count against your tenant quota. And they don't show up in the standard SharePoint admin site list.
That architectural blind spot is where both culprits in this post live.
SharePoint Embedded is Microsoft's way of letting apps store content in SharePoint's infrastructure without creating traditional sites. Loop workspaces and Copilot Pages are the most visible examples, but a growing number of first- and third-party apps are also using SPE for storage.
All of it counts against your SharePoint tenant quota.
Here's the problem: if you go to your SharePoint admin center and sort sites by storage, you won't see SPE containers. They're invisible to traditional admin tooling.
This is a growing blind spot for a simple reason: Copilot adoption is accelerating it. Every time someone in your organization uses Loop or Copilot, we risk more unmanaged containers getting created. Third-party apps are multiplying too as more ISVs build on the SPE developer platform.
Organizations that are actively rolling out Copilot right now are building an SPE storage footprint they may not be measuring at all.
If your organization used Microsoft Stream before 2023, recordings lived in Microsoft's own infrastructure and didn't touch your SharePoint or OneDrive storage. That changed when Microsoft moved Stream to SharePoint.
Now every recorded meeting draws from the same storage pools you're already managing:
Auto-expiry is enabled by default at 120 days. That sounds like a self-cleaning mechanism, but in practice it mostly cleans up the recordings nobody cared about. Recording owners can extend the expiry or remove it entirely -- and for any meeting that feels important, they usually do. The result is that important recordings get extended indefinitely, and the 120-day policy only catches the ones nobody was going to watch anyway.
The math adds up fast. If you have 500 users and even a fraction of them are in recurring meetings with recordings, you're generating meaningful storage every week. Unlike documents, recordings are large by default and almost never get trimmed for version history.
For the non-channel recordings specifically, there's a compounding problem: those files land in individual OneDrives. When someone leaves your organization and their OneDrive isn't properly offboarded, those recordings stay. They keep consuming quota. And because they're in personal storage, they're often the last thing anyone thinks to check.
SPE containers and meeting recordings don't just add storage in isolation. They interact with the mechanics that are already inflating your tenant.
The core problem with SPE containers isn't version sprawl (.loop and .fluid files have a hardcoded version cap), it's that the storage footprint is invisible to standard admin tooling. Most admins aren't monitoring SPE containers directly, so that footprint grows without any visibility into what's accumulating or where.
Meeting recordings sitting in sites governed by a Retention Policy or Legal Hold are protected by the Preservation Hold Library. If you try to delete them, the PHL intercepts the deletion and preserves the content. Your storage number doesn't move. That's not a bug (it's compliance working as designed) but it means storage cleanup efforts hit a wall that's completely invisible unless you know to look for it.
One-time cleanups can't keep pace with these patterns running simultaneously across a growing tenant. You can clear bins and trim versions on a set of sites today. But SPE containers are being created in the background, recordings are accumulating on a weekly cadence, and the cycle starts again.
Neither blind spot has a perfect native solution today, but you're not without options.
For SPE containers:
For meeting recordings:
Before acting on any of this, it's worth running a baseline triage to understand where your tenant actually stands today.
The reason storage keeps growing isn't that admins aren't trying. It's that isolated cleanup events can't outpace continuous accumulation. SPE containers multiply with every new Copilot user. Recordings stack up every week. Versions compound in the background on every active site.
What actually changes the trajectory is treating storage as a governance problem rather than a cleanup problem. That means three levers working continuously, not in sequence:
The sequencing of trim and archive matters more than most organizations realize. If you archive a site without trimming its version history first, you're paying archive storage costs on versions nobody needs. If you trim first, then archive, the savings compound.
Orchestry's role is to make these levers operational at scale: surfacing where storage is growing, executing version trimming safely, and routing archiving decisions through workspace owners instead of landing everything on a small admin team.
It's worth noting that SPE containers handle storage differently from standard SharePoint libraries. Only .loop and .fluid files live in the container, and those files have a hardcoded 50-version cap. Version trimming doesn't currently apply to SPE, so the governance lever here is visibility, not cleanup.
We covered all of this live, including a walkthrough of the storage math, a demo of what proactive governance looks like in practice, and a Q&A with some genuinely sharp questions from attendees.