Site Collections Didn’t Win—AI Meeting Archives Land in Containers You Can’t See

There’s a quiet rule in M365 administration: if data exists in your tenant, eventually someone will ask you to find it, retain it, delete it, or hand it to a lawyer. Usually you can. You know where SharePoint sites live, you know which library holds the Teams recording, you know the mailbox the transcript lands in.

That assumption is about to crack. Office365itpros reports that tenants with Microsoft 365 Copilot licenses will soon start generating AI meeting archive files automatically for Teams meetings — and they don’t land in a site collection you can browse to. They land in SharePoint Embedded containers, a storage model most admins have never had to think about, created and read by Copilot and the Facilitator agent rather than by the people in the meeting.

So the old mental model — “meeting artefacts live in a SharePoint library I can navigate” — is done. Container-based storage won. If you run a Copilot tenant, here’s the order I’d work through it.

1. Confirm you’re actually in scope

This only touches tenants with Microsoft 365 Copilot licences. No Copilot, no AI meeting archive files, no new storage back-end to reason about. That’s the single fastest way to close the ticket if your organisation hasn’t bought in yet.

Don’t trust a gut feeling about who has what. Copilot gets assigned in pockets — a pilot group here, an exec team there — and “we don’t really use Copilot” is how you end up surprised. Pull the actual assignment count before you decide this is somebody else’s problem.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

# Read-only. Counts users with a Microsoft 365 Copilot license assigned.
# Requires: Microsoft.Graph module, scope User.Read.All + Organization.Read.All
Connect-MgGraph -Scopes "User.Read.All","Organization.Read.All" -NoWelcome
​
try {
    # Resolve the Copilot SKU by part number rather than hard-coding a GUID
    $copilotSku = Get-MgSubscribedSku -All |
        Where-Object { $_.SkuPartNumber -eq 'Microsoft_365_Copilot' }
​
    if (-not $copilotSku) {
        Write-Warning "No Microsoft 365 Copilot SKU found in this tenant. You are likely out of scope."
        return
    }
​
    $skuId = $copilotSku.SkuId
    $assigned = 0
    $uri = "https://graph.microsoft.com/v1.0/users?`$select=userPrincipalName,assignedLicenses&`$top=999"
​
    do {
        $page  = Invoke-MgGraphRequest -Method GET -Uri $uri -ErrorAction Stop
        $assigned += ($page.value | Where-Object {
            $_.assignedLicenses.skuId -contains $skuId
        }).Count
        $uri = $page.'@odata.nextLink'
    } while ($uri)
​
    Write-Host "Users with Microsoft 365 Copilot assigned: $assigned"
}
catch {
    Write-Error "Failed to enumerate Copilot assignments: $($_.Exception.Message)"
}

Verify the SkuPartNumber against Get-MgSubscribedSku output in your own tenant — part numbers vary by how the licence was purchased.

2. Learn what SharePoint Embedded actually is, before you form opinions about it

SharePoint Embedded is not a new SharePoint site type. It’s a headless, container-based storage model that rides on the same file infrastructure as SharePoint and OneDrive but exposes none of the site-collection furniture — no site, no familiar document library UI, no “share this folder” experience for end users. Applications create containers under a container type, and the application owns the governance surface, not a site owner.

The important shift for you: these containers belong to an application’s container type. For Copilot’s meeting archive files, the storage is managed by Microsoft’s infrastructure. You didn’t provision the container, a user didn’t create it, and there’s no site collection admin on it. That’s the point of the model — and it’s exactly why your usual “go look in the library” instinct returns nothing.

If you internalise one thing here, make it this: container type is the unit of governance in SharePoint Embedded, the way the site collection was in classic SharePoint. Everything downstream — who can enumerate, who can read, what tooling applies — hangs off that.

3. Try to inventory what’s there — and notice where the visibility stops

You’ll want a count. The Graph file-storage container APIs let you enumerate containers for a container type you have rights to. The catch, and it’s a real one, is that container types managed by Microsoft for its own services are not enumerable by tenant admins in the way custom-app container types would be. So this inventory is useful for any container types your own org registered, and it’s a good way to prove to yourself what you can and can’t see.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

# Read-only inventory of SharePoint Embedded containers for a given container type.
# You must supply a container type ID you are entitled to enumerate.
# Requires scope: FileStorageContainer.Selected (plus app-level consent/role on the container type)
param(
    [Parameter(Mandatory)]
    [string]$ContainerTypeId
)
​
Connect-MgGraph -Scopes "FileStorageContainer.Selected" -NoWelcome
​
try {
    $uri = "https://graph.microsoft.com/v1.0/storage/fileStorage/containers?`$filter=containerTypeId eq $ContainerTypeId"
    $containers = @()
​
    do {
        $page = Invoke-MgGraphRequest -Method GET -Uri $uri -ErrorAction Stop
        $containers += $page.value
        $uri = $page.'@odata.nextLink'
    } while ($uri)
​
    if (-not $containers) {
        Write-Warning "No containers returned. Either none exist for this type, or your identity cannot enumerate it (expected for first-party/Microsoft-owned types)."
    }
​
    $containers |
        Select-Object id, displayName, status, createdDateTime |
        Sort-Object createdDateTime -Descending |
        Format-Table -AutoSize
}
catch {
    Write-Error "Container enumeration failed: $($_.Exception.Message)"
}

When this comes back empty for the Copilot meeting archive data, that’s not a bug in your script — it’s the architecture telling you the container type isn’t yours to enumerate. Write that finding down. “Admin cannot directly list these containers through standard tenant tooling” is a material fact for your records team, not a footnote.

4. Treat quota, retention, and eDiscovery scope as open questions — and log them as open

Here’s where I’m going to disappoint anyone who wants a clean answer, because the honest one is: unknown, per the source. Office365itpros describes what these files are, where they live, and who uses them. It does not confirm whether they count against SharePoint storage quota, whether Purview retention and deletion policies reach them, or whether they fall inside eDiscovery search scope.

Do not fill that vacuum with a guess, and do not let a vendor FAQ fill it for you with a reassuring sentence that has no mechanism behind it. The three questions that decide whether this is a governance non-event or a genuine problem:

• Quota: does archive-file storage consume your tenant’s SharePoint quota, or is it carried separately? This changes capacity planning if meeting volume is high.
• Retention: do existing Purview retention and deletion policies apply to container content, or is it governed by its own lifecycle outside your labels? If it’s outside, your “delete after 90 days” promise has a hole in it.
• eDiscovery: is this content discoverable in a hold or search? If AI-generated meeting context is in the tenant but invisible to legal hold, that’s the kind of gap that turns into a very bad afternoon during litigation.

Raise all three with Microsoft support or your account team in writing, and keep the answer. “We asked, here’s the documented response, dated” is defensible. A guess is not.

5. Resist the urge to pre-emptively “turn it off”

The source does not confirm this is mandatory, and it does not confirm there’s an admin switch to disable it. So don’t promise your CISO you can flip it off, and don’t go hunting for a toggle that may not exist. If and when a control surfaces, it’ll show up in the Teams admin center or the Microsoft 365 admin center alongside the rest of the Copilot configuration — that’s where to watch. Until then, the responsible move is to understand the behaviour, not to manufacture a mitigation.

6. Brief the two people who will ask first

Your records manager and your eDiscovery lead need a one-paragraph heads-up now, not after the first subject access request lands. The message is short: Copilot meeting usage generates AI archive data stored in a container model that sits outside normal SharePoint governance, direct admin visibility is limited, and we have outstanding questions with Microsoft on retention and discoverability. That framing makes you the person who flagged it early rather than the person who missed it.

The files themselves aren’t for humans anyway — they exist so Copilot and the Facilitator agent have meeting context to draw on. That’s genuinely useful; agents reasoning over prior meetings is a large part of why anyone pays for Copilot. The friction isn’t the feature, it’s that a new data class landed in a storage model your compliance tooling was never pointed at.

If you do one thing this week: confirm your Copilot licence footprint, then send that six-line brief to records and legal with the three open questions attached. Everything else can wait for Microsoft to document the quota and retention behaviour — but your records team finding out from you beats them finding out from opposing counsel.