Some of the most confusing tickets in an MSP are the ones where nothing is actually broken. A user swears something changed. The behavior looks like a bug. And yet the environment is doing precisely what it was designed to do. External file sharing in Microsoft Teams is one of those cases, and it is worth understanding not just because it comes up often, but because it teaches a lesson that repeats itself across Microsoft 365: the default is a decision, and the decision is not always visible where you would expect to change it.

The Symptom

A client shares a Teams chat with someone outside their organization — a vendor, a partner, a customer. They go to send a file the way they always do, and the option is simply gone. The + attach icon has disappeared from the toolbar. Dragging a file into the window produces a red X. They can still paste a SharePoint or OneDrive link by hand, but the direct attachment experience they expect has quietly vanished.

Nothing crashed. Nothing was misconfigured by the last engineer. This is the out-of-the-box behavior of the tenant. By default, Teams blocks native file attachments in any chat that includes an external participant. It is intentional policy, not a fault — and recognizing that early saves you an hour of chasing a problem that does not exist.

What’s Actually Happening

The setting responsible lives inside a policy called CsTeamsFilesPolicy, specifically its FileSharingInChatsWithExternalUsers value, which ships as Disabled — Microsoft’s own documentation lists Disabled as the default. The detail that trips people up is that this setting is not exposed in the Teams Admin Center UI. There is no toggle to find. It is PowerShell or nothing.

That alone is a useful reminder. The admin center is a curated surface, not the whole story. A meaningful amount of tenant behavior lives one layer beneath it, reachable only through the module. If you have ever felt certain a setting should exist somewhere in the portal and come up empty, this is often why.

There is a second layer that makes this genuinely tricky. External file sharing in Teams is really governed by two independent systems, and both have to agree:

  • CsTeamsFilesPolicy controls the attachment experience inside the chat — whether the + icon and drag-and-drop even appear.
  • SharePoint external sharing controls whether the recipient can actually open the file once it has been shared.

Enable the first without checking the second and you get the worst kind of half-fix: users can suddenly attach files again, feel like the problem is solved, and then the external recipient still can’t open anything. Two layers, both silent, both required. Understanding that shape up front is most of the battle.

The Shape of the Fix

The repair itself is short once you know where to look. You connect with the Teams PowerShell module, check the current policy state, and flip the value — either tenant-wide on the Global policy, or scoped to a custom policy assigned to specific users or groups:

# Enable globally for everyone in the tenant
Set-CsTeamsFilesPolicy -Identity "Global" -FileSharingInChatsWithExternalUsers Enabled

For most MSP scenarios, scoping to a group is the more disciplined choice. You leave the Global policy alone, create a custom policy, and assign it to a security or Microsoft 365 group so membership drives access automatically. The one trap worth flagging: Get-CsOnlineUser only shows direct assignments and will happily lie to you about a user’s effective policy. To confirm what a user is actually getting — direct or inherited from a group — you use Get-CsUserPolicyAssignment instead. And after any change, propagation can take up to an hour, occasionally longer, so a policy that “didn’t work” is often just a policy that hasn’t landed yet.

Why I Keep This Written Down

None of this is hard the second time. But almost none of it is memorable either — the exact cmdlet names, the group-assignment ranking rules, the two-layer dependency, the verification commands that actually tell the truth. This is exactly the kind of knowledge that evaporates between the day you solve it and the day it comes back six months later on a different client’s tenant.

So I keep it in a knowledge base — the full runbook, every command, the group-scoping steps, and the SharePoint side that has to line up with it. If you support Microsoft 365 tenants and want the complete, copy-pasteable version rather than the story around it, that’s where it lives:

→ Teams: External File Sharing via CsTeamsFilesPolicy — part of my open MSP Microsoft 365 knowledge base on GitHub.

The pattern underneath it is the part worth carrying with you, though. When a Microsoft 365 behavior looks broken, ask first whether it is a default doing its job. Then ask whether the thing you can change in the portal is really the thing that governs it. More often than you would think, the answer is sitting quietly in PowerShell, one layer down.