Exchange room mailboxes: stop double-booking, restrict who can book, and let external people book
Three room-mailbox questions recur on every IT forum, and the native answers exist but arrive with traps the threads keep rediscovering. All three live in one cmdlet: Set-CalendarProcessing.
1. "Rooms are getting double-booked"
The intended state is the default: AllowConflicts $false with
AutomateProcessing AutoAccept — the booking attendant declines anything that overlaps.
When double-bookings happen anyway, check that the attendant is actually on; a
2025 Microsoft Q&A thread
shows the diagnostic that resolves most cases:
Get-CalendarProcessing -Identity "Boardroom" | FL AutomateProcessing, AllowConflicts, AllRequestOutOfPolicy
Expected: AutoAccept, False, False. Mailboxes converted from
user mailboxes, or created long ago, are the usual offenders (AutomateProcessing left at
AutoUpdate).
The recurring-series subtlety that looks like double-booking even when everything
is configured right: per Microsoft's documentation,
a recurring series whose conflicts stay under ConflictPercentageAllowed /
MaximumConflictInstances is accepted, with only the conflicting occurrences
declined — in a decline notice organisers routinely don't read. To them, the series "booked fine" and
the room is double-booked on the 14th. Set both thresholds to 0 if you want series to behave like
single bookings.
2. "Only certain people should be able to book this room"
The native mechanism is BookInPolicy with AllBookInPolicy $false:
Set-CalendarProcessing -Identity "Boardroom" ` -AllBookInPolicy $false ` -BookInPolicy "[email protected]","[email protected]"
Everyone else's requests need delegate approval (or are refused, depending on the request-in-policy settings). The threads that fail at this usually fail on two traps:
- Replace-only.
BookInPolicyhas no add/remove verb — setting it replaces the whole list. A Microsoft Q&A asker wiped five users adding two; the accepted answer is read-append-set. Use groups instead of user lists — but note the docs: dynamic distribution groups are not supported. - The workaround that bypasses the attendant. A 2020 Spiceworks thread wanted two users to skip delegate approval without receiving everyone's requests; the in-thread answer granted them Author rights on the calendar folder — which writes appointments directly, skipping conflict checking entirely. The asker abandoned it as "not as simple as a couple of clicks". The native answer (those two users in
BookInPolicy, everyone else out) was never mentioned in the thread.
3. "People outside our organisation need to book the room"
Two different ceilings, regularly confused:
- Booking by invitation works once you flip the switch that is off by default:
ProcessExternalMeetingMessages $true. Per the docs, the default$falsemeans "Meeting requests from external senders are rejected." With it on, an external organiser can send a meeting request to the room's address and the attendant processes it under the same policies. - Direct calendar access does not work, ever. A 2025 thread where the asker had configured everything correctly got the definitive MVP answer: "Cross-tenant calendar sharing is always read-only, what you are trying to achieve is simply not possible… No way for edit access though." External users also can't see your rooms in Room Finder — a 37-post, 13,900-view thread trial-and-errored its way to the same wall.
So natively: external bookers can email a meeting request at the room blind (no availability view), and cannot browse or edit. For visiting-tenant, multi-company-building or client-facing rooms, that blindness is usually the dealbreaker.
Where our product fits
These three problems are policy problems bolted onto a calendar that was designed for people, not rooms. Meet Me At Work was built rooms-first, so the same three are settings, not incantations: conflicts are refused at booking time (recurring series get a per-occurrence conflict panel instead of silent partial declines); who-can-book is a per-room restriction plus trusted domains and an invited-users list — which is also how external people book: they scan the same QR code or open the same room link, see live availability, and book with their own email, no tenant relationship required. This does not mean leaving Outlook: with the add-in and Teams tab rolled out, meetings are composed in Outlook or Teams as ordinary Exchange meetings with live room availability in the compose window — the room books itself when the invite is sent, is released when the meeting is cancelled, and door or app bookings mirror back into the organiser's Outlook or Google calendar. What retires is only the room resource mailbox itself: the room's calendar becomes the booking system's — which, for these three problems, is the point.
Sources
- Microsoft Learn — Set-CalendarProcessing reference
- Microsoft Learn — Manage resource mailboxes in Exchange Online
- Microsoft Learn — booking attendant permission tiers
- Microsoft Q&A, 2025 — "How to stop double bookings in room resources"
- Microsoft Q&A, 2022 — BookInPolicy replace-only
- Spiceworks, 2020 — booking without delegate approval
- Spiceworks, 2024 — external users booking rooms (37 posts)
- Spiceworks, 2025 — the cross-tenant read-only ceiling