Architecture
Why some booking tools create a mailbox for every page
Microsoft Bookings provisions a real mailbox per booking page. That buys real things — and it also puts objects in your GAL and your attack surface.
· 5 min read
There is a design decision inside Microsoft Bookings that most people never notice and every Exchange administrator eventually meets: a booking page is a mailbox. Creating one provisions a real object in your tenant — with an address, a calendar, and a presence in the global address list.
That is a defensible choice with real advantages, and this post is not an argument that it is wrong. It is an explanation of what follows from it, because what follows is not obvious at the moment somebody in marketing creates a page for a webinar.
What the architecture buys
Start with the case for it, because it is strong and it is why the design exists.
- It is a first-class calendar object. A mailbox has a real calendar, so permissions, delegation and sharing all work the way they already work everywhere else in Exchange. No new permission model to learn.
- No third party gets calendar access at all.The booking data never leaves the tenant. For an organisation whose answer to “can we connect an outside scheduler” is a flat no, that is the whole argument and it is a good one.
- It is discoverable. Being in the GAL means people can find it, book it, and see it as a resource alongside rooms and equipment.
- It inherits your compliance posture. Retention, eDiscovery and legal hold apply to it because it is a mailbox like any other.
If those matter more than what follows, Bookings is the right tool and you should use it. We are genuinely not competing for that organisation.
What follows from it
Every page is an object, and objects accumulate
A booking page created for a one-off event does not stop existing when the event does. It stays a mailbox, in the address list, indistinguishable at a glance from a person. Administrators describe finding these by the thousand — one reported purging roughly four thousand inactive Bookings accounts — because nothing about creating a page suggests you have created something that needs a lifecycle.
The clutter is the visible symptom. The real cost is that a directory people use to find colleagues fills with objects that are not colleagues, and the signal-to-noise of your GAL is something you only notice after it is gone.
A provisioned mailbox may not inherit your mail security
This is the one worth knowing about, and it was reported by an administrator who lived through it: a Bookings-provisioned mailbox in their tenant did not carry the licence their email security depended on. Mail addressed to it therefore did not traverse the protections every other mailbox sat behind. A phishing message reached a user through it, and the incident ended in a full account takeover.
The shape of the problem, stated generally
Automatic provisioning creates objects that a human never enrolled. Any control you apply by assignment — a licence, a policy, a group membership, a security baseline — is a control the new object may not have. The gap is not that the mailbox is insecure by design; it is that it appeared without passing through the process that makes your other mailboxes secure.
That failure mode is not unique to Bookings, and it is not evidence that Microsoft built something careless. It is what auto-provisioning costs, everywhere it is used, and it is worth pricing in before you have four thousand of them.
What we do instead, and what that means for you
Neos Meet never provisions a mailbox or a user account — not per host, not per event type, not per booking page. A host is an OAuth-connected calendar and nothing else. There is no object created in your tenant, so there is nothing to appear in the GAL, nothing to license, nothing to enrol in a security baseline, and nothing to purge in two years.
| Per-page mailbox model | Neos Meet | |
|---|---|---|
| Objects created in your tenant | One mailbox per booking page | None |
| Appears in the GAL | Yes | N/A — nothing is created |
| Needs licensing / policy assignment | Yes, and may be missed | N/A |
| Lifecycle to manage | Yes — orphaned pages persist | Revoke the OAuth grant |
| Calendar data leaves the tenant | No | Yes — free/busy to us |
| Works with no external vendor | Yes | No |
Read the last two rows carefully, because they are the trade and they run against us. Our model removes an object-lifecycle problem by moving the integration outside your tenant, which means an external service holds a calendar grant. If your position is that no outside product touches the calendar, that trade is a bad one and Bookings wins on the criterion you actually care about.
What we can say precisely is how narrow the grant is: on Google, the scope we hold is one the API will not answer with event titles, guests or descriptions, whatever we send it. On Microsoft there is no equivalent scope, so the narrowing is our own code asking for four fields — start, end, busy/free, and whether the event was cancelled — which is a promise rather than a wall, and we say so on the page about it.
If you are the admin who inherited four thousand of these
- Enumerate them before deleting anything — a Bookings mailbox that is still in use looks identical to one that is not.
- Check licence and policy assignment on every provisioned mailbox, not just the ones you recognise. That is the gap the phishing case went through.
- Decide who is allowed to create booking pages. Auto-provisioning plus unrestricted creation is the combination that produces the number.
- Hide unused ones from the address list before removing them, so you find out who was relying on one without breaking their week.
Does Neos Meet create anything in my Microsoft tenant?
No. There is no mailbox, no user object, no service principal per host or per booking page. What exists is an OAuth grant against the account that connected, and revoking that grant in Microsoft's own admin surface removes our access entirely without leaving anything behind to clean up.
So this post is telling me not to use Microsoft Bookings?
No. If keeping calendar data inside the tenant is a hard requirement, Bookings answers that and we do not — that is a real criterion and it beats everything else here. The post exists because per-page mailbox provisioning is a consequential design decision that is invisible at the moment someone creates a page, and it is worth knowing about before it becomes four thousand objects.
Where do these incidents come from?
Administrators describing them in public technical forums — the GAL clutter and the mass purge, and separately the licensing gap that let a phishing message bypass an organisation's mail security. We have summarised what was reported rather than quoting individuals, and we have not independently reproduced either case.
Why does this post not compare prices?
Because we could not read Microsoft's pricing page programmatically, and this site does not publish competitor figures it has not read. Bookings is recorded in our figures file as unverified for exactly that reason. The architectural claim here does not need a price to be true, which is why it could be written while a price comparison could not.