Why it takes days, not hours

The configuration above is perhaps ninety minutes of work. Everything beyond that is waiting on Microsoft's Places index, which lags mailbox creation by hours — in our case the room was still absent after twelve, and Get-Place -Type Room returned nothing at all.

What makes this expensive is that the waiting state looks exactly like a broken configuration. A room can be entirely functional and simultaneously invisible to discovery:

Call	Result during the lag	What it means
/places/microsoft.graph.room	empty	Discovery sees no rooms
/users/{room}/calendar	200	The mailbox exists and is reachable
/users/{room}/calendar/events	200, writable	Bookings can be created today
/users/{room}	403	Unrelated — needs User.Read.All, which the adapter does not have

That 403 is a particular trap. It appears alongside the empty discovery result and sends you looking at permissions, when the calendar call beside it is working perfectly.

The practical consequence: only discovery depends on /places. Creating, reading, updating and deleting events are all addressed by mailbox address and work from the moment the room exists. The room is invisible only to the one step that enumerates rooms.

Nothing accelerates the index. Set-Place, Set-CalendarProcessing, re-running consent, restarting the adapter — none of them help. Google Workspace behaves the same way: a newly created resource is visible in the admin console and selectable in the Rooms tab, yet refuses to auto-accept until its own provisioning catches up, typically within 24 hours.

So the operational rule for both providers is simply: create rooms the day before they are needed. A room built during a customer demo will not work during that demo, and nobody will be at fault.