Room Shows Tentative Instead of Accepted: How to Fix It in Exchange Online
Someone books a room, gets a tentative reply, and the room now looks half-booked to everyone else. Here is every cause in diagnostic order, with the exact PowerShell to find it and fix it.
At 15:52 on a Tuesday someone in sales books the boardroom for tomorrow morning. Outlook sends the request. Forty seconds later a reply lands: Tentative. Not accepted, not declined. The meeting sits in the room calendar in a state that no human in the building can interpret. Someone else opens Scheduling Assistant, sees a stripey block instead of a solid one, decides it is probably nothing, and books over the top. Now two teams show up at 09:00.
Tentative is the worst answer a room mailbox can give, because it is the one that looks like a soft yes and behaves like a hard maybe. This post walks through every cause of it in Exchange Online, in the order you should actually check them, with the diagnostic command and the fix for each. At the end there is a tenant-wide audit that finds every room in your organisation that is not set to auto-accept, plus a note on why this specific failure is so destructive once you put a display on the wall.
What tentative actually means here
A room mailbox in Exchange Online is processed by two components. The Calendar Attendant writes the item into the calendar. The Resource Booking Attendant decides whether to accept or decline it. Which of those run is controlled by one parameter, AutomateProcessing, which has three values:
- None: both attendants are off. Nothing is processed.
- AutoUpdate: only the Calendar Attendant runs. Meeting requests are written to the calendar as tentative and stay that way until a delegate approves them.
- AutoAccept: both attendants run. The item is written, then accepted or declined according to the booking policy.
So a tentative response is not a bug. It is Exchange telling you, correctly, that something in the configuration says a human is supposed to make the final call. Your job is to find out which setting said that.
Get the full picture first
Do not fix anything until you have read the whole configuration. Connect and dump every relevant property in one shot:
Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
Get-CalendarProcessing -Identity boardroom@contoso.com | Format-List `
AutomateProcessing, ResourceDelegates, ForwardRequestsToDelegates, `
AllBookInPolicy, BookInPolicy, AllRequestInPolicy, RequestInPolicy, `
RequestOutOfPolicy, TentativePendingApproval, BookingWindowInDays, `
MaximumDurationInMinutes, AllowRecurringMeetings, AllowConflicts, `
MaximumConflictInstances, ConflictPercentageAllowed, `
ProcessExternalMeetingMessages, ScheduleOnlyDuringWorkHours
Keep that output on screen. Almost every cause below is visible in it.
Cause 1: AutomateProcessing is AutoUpdate
This is the answer most of the time. Rooms created a long time ago, rooms created by a script that did not set the value, and rooms converted from user mailboxes all tend to land on AutoUpdate.
Set-CalendarProcessing -Identity boardroom@contoso.com -AutomateProcessing AutoAccept
Test with a real booking from a normal user account, not from the admin account, because admin accounts sometimes have delegate rights that change the path the request takes.
Cause 2: the mailbox has delegates
If ResourceDelegates is populated, requests get routed to those people for a decision. Combined with ForwardRequestsToDelegates set to $true, the room will happily sit on tentative forever while the delegate ignores the email.
This is often a leftover. An office manager was made a delegate two years ago so they could tidy up bookings, then left. The delegate list still points at a disabled account.
Set-CalendarProcessing -Identity boardroom@contoso.com `
-ResourceDelegates @() `
-ForwardRequestsToDelegates $false
If you genuinely want a delegate but only for exceptions, keep the delegate and make sure the in-policy path is still automatic. That is the next cause.
Cause 3: AllBookInPolicy is false
AllBookInPolicy controls whether in-policy requests from all users are approved automatically. The default is $true. When it is $false, only the users and groups listed in BookInPolicy get an automatic accept. Everyone else gets routed for approval, which surfaces as tentative.
This one bites hard when BookInPolicy contains a group that has since been emptied or renamed.
Set-CalendarProcessing -Identity boardroom@contoso.com `
-AllBookInPolicy $true `
-AllRequestInPolicy $false
If you want to keep a restricted room, leave AllBookInPolicy at $false and put a group in BookInPolicy instead of individuals, so leavers do not silently break it:
Set-CalendarProcessing -Identity boardroom@contoso.com `
-AllBookInPolicy $false `
-BookInPolicy "leadership@contoso.com"
Cause 4: the booking window was exceeded
BookingWindowInDays accepts an integer from 0 through 1080 and defaults to 180 days. A request for a date beyond that window is out of policy. Depending on how RequestOutOfPolicy is configured, the organiser gets either a decline or a tentative pending approval.
The classic version of this is the annual all-hands booked 14 months ahead. Check the requested date against the window before you go looking for anything more exotic:
Get-CalendarProcessing -Identity boardroom@contoso.com |
Select-Object Identity, BookingWindowInDays, MaximumDurationInMinutes
Set-CalendarProcessing -Identity boardroom@contoso.com -BookingWindowInDays 365
MaximumDurationInMinutes is the same trap in the time dimension. The room mailbox default is 1440 minutes, a 24 hour maximum, so a two day offsite booked as a single item is out of policy.
Cause 5: recurring meetings are disallowed
AllowRecurringMeetings defaults to on, but plenty of organisations turned it off in a fit of tidiness and forgot. When it is $false, every series request goes out of policy. Single instances of the same meeting will accept fine, which makes the symptom look random until you notice it is only the weekly stand-ups failing.
Set-CalendarProcessing -Identity boardroom@contoso.com -AllowRecurringMeetings $true
Cause 6: conflicts, and the conflict allowances
AllowConflicts is $false by default, which is what you want for a physical room. The two tolerance settings, MaximumConflictInstances and ConflictPercentageAllowed, apply to new recurring requests and only take effect while AllowConflicts is $false. Microsoft is explicit that setting AllowConflicts to $true makes both of them ignored entirely, because the series is then accepted regardless of how many occurrences clash.
Both tolerances default to 0, which means a whole series is rejected if any single instance conflicts with an existing reservation. That is the reason a weekly stand-up booked for a year gets a hard decline over one clash in November. Set a tolerance if you want long series to survive that, and leave conflicts themselves switched off:
Set-CalendarProcessing -Identity boardroom@contoso.com `
-AllowConflicts $false `
-ConflictPercentageAllowed 10 `
-MaximumConflictInstances 5
The clashing occurrences still get declined individually. The series survives.
Cause 7: the organiser is external
ProcessExternalMeetingMessages controls whether the room processes requests that originate outside your Exchange organisation. When it is off, a request from a partner, a contractor on their own tenant, or a booking sent through a third party scheduling service is not auto-processed. The item may still land on the calendar and read as tentative.
Set-CalendarProcessing -Identity boardroom@contoso.com -ProcessExternalMeetingMessages $true
Turn this on deliberately, not reflexively. It means anyone who knows the room address can put things in your calendar.
Cause 8: TentativePendingApproval is making it look worse
TentativePendingApproval controls whether pending requests are marked tentative on the calendar at all. If you have a legitimate approval workflow and you want the room to read as free until a delegate actually approves, set it to $false. That does not fix the approval delay, but it stops the room from advertising a booking that may never happen.
Set-CalendarProcessing -Identity boardroom@contoso.com -TentativePendingApproval $false
Cause 9: a migrated mailbox that kept legacy settings
Mailboxes moved from on-premises Exchange carry their old calendar processing with them. A room that was configured in 2014 under a different admin will arrive in Exchange Online with whatever it had. Migration does not normalise these values.
The tell is a room whose settings do not match any of your current defaults: an odd BookingWindowInDays, a delegate who was never in the tenant, or AutomateProcessing set to None. Do not fix these one at a time. Audit the lot.
The tenant-wide audit
This finds every room mailbox that is not set to auto-accept, and shows the two settings most likely to explain why:
Get-Mailbox -RecipientTypeDetails RoomMailbox -ResultSize Unlimited |
Get-CalendarProcessing |
Where-Object { $_.AutomateProcessing -ne "AutoAccept" } |
Format-Table Identity, AutomateProcessing, AllBookInPolicy, ResourceDelegates -AutoSize
A wider report, useful before a display rollout, dumps the full policy shape of every room to CSV so you can eyeball the outliers:
Get-Mailbox -RecipientTypeDetails RoomMailbox -ResultSize Unlimited |
Get-CalendarProcessing |
Select-Object Identity, AutomateProcessing, AllBookInPolicy, AllRequestInPolicy,
BookingWindowInDays, MaximumDurationInMinutes, AllowRecurringMeetings,
AllowConflicts, ProcessExternalMeetingMessages,
@{n="Delegates";e={$_.ResourceDelegates -join ";"}} |
Export-Csv -Path .\room-calendar-processing.csv -NoTypeInformation
And the blunt instrument, once you have read the CSV and are sure you want uniform behaviour:
Get-Mailbox -RecipientTypeDetails RoomMailbox -ResultSize Unlimited |
Set-CalendarProcessing -AutomateProcessing AutoAccept -AllBookInPolicy $true
Run the audit again afterwards. It should return nothing.
Why this matters once there is a screen on the wall
In Outlook, a tentative block at least renders differently from a busy one. On a room display it usually does not. Most display software reads free/busy or the event list and shows one of two states: available or booked. A tentative item is an event with a start time and an end time, so it renders as booked. Or the software filters tentative items out, and it renders as free. Either behaviour is defensible and both are wrong for the person standing in the corridor, because the truth is neither.
The result is the failure mode people describe as the display lying. The display is not lying. It is faithfully rendering a calendar state that has no honest visual representation. This is why the calendar hygiene work comes before the hardware, not after it. A room set to AutoAccept with a sane policy produces only two states, and two states are what a screen can show.
The buy side of this decision
Everything above is free. It is PowerShell against a tenant you already pay for, and if you have fewer than about 20 rooms you can finish the whole audit in an afternoon. Do that first regardless of what you buy.
Where a product helps is the part after the fix: keeping the rooms visible so bad states get noticed within a day rather than a quarter. Lobby is a meeting room display that syncs with Microsoft 365 room resources and Google Calendar. It comes in three forms with the same dashboard: a physical e-ink screen on 7.5-inch e-ink hardware, a virtual display that is just a URL in any browser tab, and a room overview board for a reception area.
The hardware is bought direct from the manufacturer and we take no markup on it. E-ink displays start at USD 69 per device, dropping to USD 62.99 at 10 or more, before tax, duties and shipping. You buy it once and own it.
On the software side, Free is free forever for up to 3 active displays with 15-minute e-ink updates and no credit card. It is not a trial. Unlimited is USD 30 per month billed yearly, which is USD 360 a year, or USD 50 per month if you pay month to month, for unlimited rooms and displays. Pro Unlimited is USD 60 per month billed yearly, USD 720 a year, or USD 100 per month month to month, and adds 5-minute e-ink updates, custom templates, your own logo with Lobby branding removed, room feedback with free QR stickers, a Slack /book command, priority support, Lobby-hosted e-ink screens rendered and served in the EU, Active hours and Smart Updates. Yearly billing saves 40 percent and there is no annual contract lock-in. Setup takes under 10 minutes with no sales call.
What it does not do, and this is relevant to the problem in this post: it does not manage your room mailboxes for you. It will not set AutomateProcessing, it will not clean up your delegates, and it will not rescue a room whose booking policy is wrong. The rooms product also does not do desk booking or visitor management, and there is no AV control, no occupancy sensing, and no enterprise SSO or SCIM at scale, there is no MDM on the e-ink hardware, and on-premises Exchange needs hybrid. The calendar has to be correct first. The display just makes it obvious when it is not. Lobby is made by Vikba ApS in Denmark and is not affiliated with Microsoft or Google.
TL;DR
- Tentative means the Resource Booking Attendant did not run, or ran and routed the request for human approval.
- Check
AutomateProcessingfirst. If it isAutoUpdateorNone, that is your answer most of the time. - Next check
ResourceDelegatesandForwardRequestsToDelegates, thenAllBookInPolicyandBookInPolicy. - If only some requests fail, the cause is policy-shaped: booking window (default 180 days), duration (default 1440 minutes), recurrence, conflicts, or external senders.
- Leave
AllowConflicts $falseand useConflictPercentageAllowedandMaximumConflictInstancesfor tolerance. SettingAllowConflicts $truemakes both of those ignored. - Migrated mailboxes keep their old settings. Audit the whole tenant rather than fixing rooms one by one.
- Tentative renders ambiguously on any room display, because the underlying state has no honest two-state representation. Fix the calendar before you hang the screen.
Related reading
- Set-CalendarProcessing for room mailboxes
- Microsoft 365 room mailbox auto-accept best practices
- Why meeting rooms show free when they are not
- Exchange meeting room display
Sources
- Set-CalendarProcessing (ExchangePowerShell), Microsoft Learn, for the AutomateProcessing values, the parameter defaults cited above, and the note that ConflictPercentageAllowed and MaximumConflictInstances are ignored when AllowConflicts is $true
- Get-CalendarProcessing (ExchangePowerShell), Microsoft Learn
- Create and manage room mailboxes, Microsoft Learn, for default booking behaviour and the pipeline patterns used in the audit scripts
- Manage resource mailboxes in Exchange Online, Microsoft Learn
- Room mailbox can't automatically accept or decline meeting requests, Microsoft Learn
- Connect to Exchange Online PowerShell, Microsoft Learn
- Lobby plan and hardware prices were verified on usethelobby.com/pricing and usethelobby.com/hardware on 5 August 2026. Confirm the current figures there before you budget.