What it does

The admin policy layer that sets the defaults for every meeting a user organises — who walks straight in, who waits in the lobby, who can present, whether recording and transcription are on. Organisers then see those defaults in Meeting options and can change most of them per meeting.

Key facts

• Lobby and join settings live in the Teams admin center under Meetings > Meeting policies > Meeting join & lobby; the bulk of meeting settings are set with Set-CsTeamsMeetingPolicy, and Learn's lobby guidance now shows the lobby parameters on Set-CsTeamsEventsPolicy, so check the current cmdlet reference before scripting.
• AutoAdmittedUsers ("Who can bypass the lobby") takes Everyone, EveryoneInSameAndFederatedCompany, EveryoneInCompany, InvitedUsers or OrganizerOnly. The settings reference lists the default as "People in my org and guests".
• AllowPSTNUsersToBypassLobby ("People dialing in can bypass the lobby") defaults to Off. UsersCanAdmitFromLobby defaults to OrganizersAndPresentersOnly; the alternative is OrganizerAndCoOrganizersOnly.
• "Anonymous users can join a meeting" (AllowAnonymousUsersToJoinMeeting) defaults to On. "Anonymous users and dial-in callers can start a meeting" defaults to Off, so they sit in the lobby until a verified participant joins.
• Organisers can override "Who can bypass the lobby", "People dialing in can bypass the lobby" and "Who can admit from lobby" in Meeting options. Meeting templates and sensitivity labels (Teams Premium) can lock values, but they don't support "Who can admit from lobby".
• Guests, trusted (external access) organisations and anonymous users each need their own tenant prerequisite switched on — guest access, external access with mutual trust, anonymous join. If the prerequisite is off they can't join at all, whatever the lobby setting says.
• "People who were invited" counts invites forwarded through distribution lists of up to 10,000 users. In channel meetings only directly invited channel members bypass.
• Lobby features in Teams events only apply to events of up to 1,000 attendees; town halls have no lobby.
• Policy changes can take up to 24 hours to take effect.
• Other defaults worth knowing: "Who can present" is Everyone, meeting chat is "On for everyone", and BlockedAnonymousJoinClientTypes (PowerShell only) can block specific anonymous client types.
• Microsoft provides a Lobby diagnostic in the Microsoft 365 admin center (search "Diag: Bypass Lobby") that shows the expected lobby result for a given user and meeting.

When to use / skip

Everyone uses this whether they mean to or not — the Global (Org-wide default) policy is already doing the work. The real question is whether the defaults suit the client. For most corporate tenants they're fine: internal people and guests walk in, anonymous users and dial-in callers wait. Leave it there unless someone has a specific reason to change it.

Build extra policies when you have a population that genuinely behaves differently — an exec team who must never have strangers walk in, HR running sensitive interviews, or an external-facing sales team who want customers admitted without fuss. Resist building a policy per department. Each custom policy is one more thing the next admin has to reverse-engineer.

If the requirement is "organisers must not be able to loosen this", policy alone won't do it. That's a Teams Premium meeting template or sensitivity label job.

Configuration decisions

• Whether to tighten the Global policy or leave it at Microsoft's defaults and create a stricter custom policy for sensitive groups.
• Who can bypass the lobby by default — "people in my org and guests" versus "invited only" for regulated teams.
• Whether dial-in callers bypass the lobby; this matters most where people join from cars and can't be admitted easily.
• Whether anonymous join is allowed at all, and whether to block particular anonymous client types.
• Whether only organisers and co-organisers can admit from the lobby, or presenters too.
• Whether to enforce settings with Premium templates/labels, or accept that organisers can change them.

Gotchas

• The precedence surprises people: the organiser's policy drives most meeting-level settings, not the attendee's. A tightly locked user joining someone else's meeting gets that organiser's lobby behaviour.
• "People who were invited" behaves differently in channel meetings — channel members not directly invited still land in the lobby.
• Users from an organisation you trust that doesn't trust you back are treated as anonymous. Federation has to be mutual.
• Turning off anonymous join breaks people who join from a browser without signing in — usually the client's own customers. Test with a personal email account before you push it.
• Once a verified participant has started the meeting, anonymous users already admitted stay in even after the organiser leaves.
• Up-to-24-hour propagation makes testing slow. Assign the policy the day before the client demo, not the morning of.

Consultant notes

• Run the Lobby diagnostic before arguing about "the lobby is broken" — it tells you which setting actually won.
• Document the Global policy settings at discovery. Plenty of tenants have had it edited years ago by someone who's left.
• Use group policy assignment for custom meeting policies rather than direct user assignment; it scales and survives joiner/mover/leaver processes.
• When security asks for "no external people in meetings", walk them through the prerequisites matrix — guest, external access and anonymous are three separate switches with different blast radii.
• Pair any lobby tightening with end-user comms. Organisers will get calls from waiting externals and assume Teams is faulty.

---

Worth revisiting when Microsoft settles which cmdlet owns the lobby parameters, or if templates gain support for "Who can admit from lobby"