Three ceilings, three different walls
| Ceiling | Number | What it is |
|---|---|---|
| Outlook invite fan-out | 750 recipients | The calendar invite itself. Above this, address a distribution list or group instead of individuals — the invite send fails, not the meeting |
| Interactive room | 1,000 participants | Full citizens: mic, camera, chat, reactions, roster |
| View-only overflow | +10,000 attendees | One-way broadcast bolted onto the meeting — only if policy allows |
| Town hall | 10,000 (20,000 with Teams Premium) | A different product on the streaming pipeline, presenter-first by design |
| Webinar | 1,000 | Registration + attendee management on the interactive room |
The 750 and the 1,000 are unrelated limits that get conflated constantly: 750 caps the invite, 1,000 caps the room. A 400-person invite can still hit the 1,000 wall (forwarded invites, channel meetings), and a 2-person invite posted in a big channel can too.
What decides attendee 1,001's fate
Two conditions, both required, evaluated against the organizer's policy (never the attendee's):
TeamsMeetingPolicy.StreamingAttendeeMode = Enabled— the view-only overflow switch- The attendee would bypass the lobby under the meeting's lobby settings
Both true → seamless drop into view-only. Either false → rejected, with a "meeting is full" message that generates a helpdesk ticket every single time.
In your tenant, this is not hypothetical. Our scan reads
StreamingAttendeeModeon every meeting policy — if it saysDisabled(the default), your 1,001st attendee is being turned away today. Decide deliberately:Set-CsTeamsMeetingPolicy -Identity Global -StreamingAttendeeMode Enabled.
What view-only actually means
- A broadcast, not a seat. Presenter audio + active video + screenshare, delayed by several seconds. Nothing flows back.
- No promotion path. A view-only attendee cannot be made a presenter or unmuted — they must leave and rejoin when an interactive seat frees up (and there is no queue; it's a race).
- Roster invisibility. They are not interactive roster entries — organizers see an overflow count, not names. Attendance reporting treats them separately.
- Licence-gated. The organizer needs an enterprise licence; view-only is not part of every SKU.
Information barriers change the math entirely
If your tenant runs Purview Information Barriers, the admission rules above get a second gate that most event teams discover live, mid-all-hands:
- The join gate becomes the meeting CHAT roster. In an IB tenant, a user may join a meeting only if they can be added to its chat roster — that is how IB decides "may these people communicate". Every meeting gets this check at entry, even when the organizer is in no IB segment at all.
- The chat roster caps at 1,000 — and it is not the same number as the 1,000 interactive participants.
- Teams pre-adds 750 invitees to the chat roster before the meeting starts (for large invites), reserving only ~250 slots for people who actually join. Pre-added users consume roster capacity even if they never show up.
Do the arithmetic: 750 pre-added no-shows + ~250 real joiners = roster full. Your IB-enabled meeting starts rejecting attendee ~251 while the interactive room is three-quarters empty. The rejection looks identical to a capacity problem, so everyone debugs the wrong limit.
Recurring meetings compound it: anyone who ever joined one occurrence stays on the chat roster for the whole series — a weekly divisional call quietly accretes toward the 1,000 wall over months, then fails one Tuesday for no visible reason.
Two escape hatches, both documented and both ugly:
- Prune the chat roster — remove inactive members to free join slots.
- Keep meeting chat disabled until the meeting starts, which stops the pre-add from consuming the roster, then enable it live if needed.
And one clean one: view-only attendees are not IB-checked — the overflow pipeline
bypasses the chat roster entirely, which makes StreamingAttendeeMode Enabled even more
valuable in IB tenants.
Tenant note: Information Barrier policies are among the Purview surfaces Microsoft
does not serve to read-only app-only sessions — our execution audit records
Get-InformationBarrierPolicy as RBAC-gated rather than pretending to have checked it.
If you run IB, tell us; if you don't, none of this section applies to you.
The roster at scale
The roster is a subscription, not a list. Clients receive delta updates ("Priya joined", "mute state changed"), and the service throttles those updates progressively as the meeting grows — which is why in very large meetings the participant list loads lazily, search-first, and presence/mute states can lag reality by seconds. That lag is load shedding, not a bug: a 1,000-person roster emitting per-event updates to 1,000 subscribers is a million messages per event.
Practical consequence: never script against the live roster of a large meeting and expect real-time accuracy; use the post-meeting attendance report instead.
Chat in large meetings
Interactive participants keep meeting chat; view-only attendees have none. Two behaviours to know:
- Chat notifications in large meetings are aggressively muted by default — attendees see the thread when they open it, not a ping per message.
- The meeting chat thread lives on after the call with everyone in it. For a 1,000 person all-hands, that is a 1,000-member thread someone will reply-all to at 23:00. Set meeting chat to In-meeting only for large events unless you want the thread.
Failure signatures
| Symptom | Cause |
|---|---|
| "Meeting is full" at ~1,000 despite "we have overflow" | StreamingAttendeeMode disabled on the organizer's policy, or attendee hits the lobby |
| Some users get view-only, colleagues get rejected | Lobby bypass differs between them (external vs internal, different lobby rules) |
| Invite send fails around 750 recipients | Outlook invite fan-out cap — use a DL/group, or switch to town hall with a public link |
| Executives complain the stream is "behind" | View-only delay is by design — put VIPs in the interactive room |
| Roster shows fewer people than attended | View-only attendees never appear as roster entries |
| Can't promote an overflow attendee to speak | No promotion path exists — plan presenters into the interactive room in advance |
| IB tenant: joins refused with the room ~250 full | Chat roster hit 1,000 (750 pre-added + ~250 joined) — prune the roster or disable chat until start |
| IB tenant: recurring series suddenly refuses joins | Roster accretion — everyone who ever joined an occurrence still holds a chat-roster slot |
Choosing the right vehicle
- < 1,000 and interactive → normal meeting, restrict attendee mics/cameras in options
- ~1,000 with a tail of viewers → meeting +
StreamingAttendeeMode Enabled - Broadcast-first, 1,000-20,000 → town hall (green room, producer controls, eCDN)
- Registration, reminders, capped audience → webinar
The classic mistake is stretching a normal meeting to do a town hall's job: you get the 1,000-wall surprises, the reply-all chat thread, and none of the production controls.