M365 Room Mailbox Auto-Accept: Best Practices (2026) · Lobby

Room mailbox auto-accept is one of those Microsoft 365 features that mostly works on day one, then quietly drifts into being slightly wrong over the next two years. People book the wrong rooms. Some rooms accept everything. Some require a delegate to approve. Nobody can quite remember which setting flips which behaviour.

This is the cleanup post. The PowerShell. The eight knobs that actually matter. The five settings people change first that almost never need to change. And a copy-paste configuration that works for most offices under 150 people.

If you have not done the broader room mailbox cleanup, start with the M365 Room Mailboxes IT Manager's Checklist. This post is the auto-accept deep dive that sits inside it.

The mental model: two layers

Microsoft 365 room mailboxes have two layers of behaviour. People mix them up.

Layer one: who can book at all. Controlled by AllBookInPolicy, BookInPolicy, RequestInPolicy, and RequestOutOfPolicy. This is the "is this user even allowed to book this room" gate.
Layer two: should the booking be auto-accepted. Controlled by AutomateProcessing, plus the supporting settings like AllowConflicts and MaximumDurationInMinutes. This is the "if they are allowed, do we accept it automatically or wait for a human".

If you have a single phrase to remember, it is this: most rooms should be AutomateProcessing = AutoAccept and AllBookInPolicy = true. That is the friendly, low-friction setup. Most teams quietly want this and have not been told it is one PowerShell line away.

The eight knobs that matter

These are the ones to actually think about. Everything else can stay at default.

AutomateProcessing. Options: AutoAccept, AutoUpdate, None. Almost always AutoAccept. AutoUpdate is the special case where a delegate approves bookings; we will come back to that.
AllBookInPolicy. True means anyone in the tenant can book the room. False means only users on the BookInPolicy list. For most internal rooms, true.
BookingWindowInDays. How far in advance you can book. Default is 180. Lower it to 60 or 90 for shared rooms if recurring meetings are clogging the calendar. We have written about this in the show free when not post.
MaximumDurationInMinutes. Default is 1440 (24 hours). Drop to 480 (8 hours) unless you genuinely have all-day events. Stops the accidental 14-hour block.
AllowConflicts. Default false. Keep it false. If you allow conflicts, the room is basically a free-for-all.
AllowRecurringMeetings. Default true. Keep it true for most rooms; recurring is genuinely useful. Set false on rooms that are heavily contested (the boardroom).
RemovePrivateProperty. Default true. Strips the "private" flag from meetings booked in the room so other people can see the busy block. Almost always what you want.
DeleteComments / DeleteSubject / AddOrganizerToSubject. Cosmetic but worth setting consistently. Default behaviour leaves the room calendar showing "Q4 budget review" rather than "Booked by Alex Chen". For most teams the organiser-only display is cleaner.

The PowerShell, copy-paste

If you have Exchange Online PowerShell installed and you are connected to your tenant, this is a sane default configuration for an internal meeting room.

Set-CalendarProcessing -Identity "boardroom@yourdomain.com" `
  -AutomateProcessing AutoAccept `
  -AllBookInPolicy $true `
  -BookingWindowInDays 90 `
  -MaximumDurationInMinutes 480 `
  -AllowConflicts $false `
  -AllowRecurringMeetings $true `
  -RemovePrivateProperty $true `
  -DeleteComments $true `
  -DeleteSubject $false `
  -AddOrganizerToSubject $true

Run that against every internal room mailbox. For shared rooms with restricted access (executive boardrooms, client meeting rooms), swap AllBookInPolicy to $false and populate BookInPolicy with the allowed user list.

To verify, run:

Get-CalendarProcessing -Identity "boardroom@yourdomain.com" | Format-List

The output should match. If it does not, you have a delegate or a tenant-level policy override; check the ResourceDelegates property.

The five settings that look important but usually are not

When something is misbehaving, people tend to start changing settings that have a confident name. These five almost never need to move.

EnforceCapacity. Sounds great. Almost no one fills it in correctly because capacity is on the Place metadata, not the calendar processing record. Set capacity properly with Set-Place and leave EnforceCapacity at default.
ForwardRequestsToDelegates. Only relevant if you have a human delegate. For an auto-accept room, irrelevant.
ScheduleOnlyDuringWorkHours. Tempting if you want to stop after-hours bookings. In practice it confuses people who book a 6pm meeting two weeks in advance. Easier to leave at default and rely on common sense plus signage.
ConflictPercentageAllowed. Only matters if AllowConflicts is true, which it should not be. Leave it.
MinimumDurationInMinutes. Sounds reasonable, almost never set in practice.

When you do want a delegate (AutoUpdate)

Some rooms genuinely need a human in the loop. The pattern: client-facing meeting rooms with limited access, the boardroom, anything with AV that needs to be checked.

For these, switch to AutoUpdate and assign delegates. The room will hold the booking, the delegate gets the request, they accept or decline, and the organiser is notified.

Set-CalendarProcessing -Identity "boardroom@yourdomain.com" `
  -AutomateProcessing AutoUpdate `
  -ResourceDelegates "alex@yourdomain.com","sam@yourdomain.com" `
  -ForwardRequestsToDelegates $true `
  -AddNewRequestsTentatively $true

Two delegates is the safe minimum. One is fine until they go on holiday. Three or more usually means nobody owns it.

Two real failure modes, and how to spot them

Two patterns we see often enough to warn about.

Auto-accept stops working after a tenant migration. Symptom: invites bounce around as tentative. Cause: AutomateProcessing got reset to None during the migration. Fix: re-run the Set-CalendarProcessing block.
Delegate gets every invite even though room is AutoAccept. Symptom: every booking generates an email. Cause: ForwardRequestsToDelegates was left true and a delegate was set by accident. Fix: clear the delegates with -ResourceDelegates @().

The Outlook side of the equation

One thing worth knowing: the Outlook Room Finder uses the Place metadata (Set-Place), not the calendar processing record. If you have lovely auto-accept rules but Room Finder shows nothing, the problem is upstream. The Outlook Room Finder fix post covers the eight causes.

TL;DR

The default Microsoft 365 room mailbox auto-accept setup is almost right, but five of the eight knobs are misleading. Set AutomateProcessing AutoAccept, AllBookInPolicy true, BookingWindowInDays 90, MaximumDurationInMinutes 480, AllowConflicts false. Verify with Get-CalendarProcessing. Switch to AutoUpdate with two delegates only for rooms that genuinely need a human in the loop. Skip EnforceCapacity, ConflictPercentageAllowed and ScheduleOnlyDuringWorkHours, they sound important and almost never need to change. If Room Finder is broken, that is a Set-Place problem, not a Set-CalendarProcessing one.

Room Mailbox Auto-Accept in Microsoft 365: The Settings That Matter (and the Ones That Look Like They Do but Don't)