Calendar Connections for Room Displays
Every calendar-connected display reads and writes the same events your employees see in Outlook, Google Calendar, or Exchange. When someone books from the tablet, the reservation appears on the room calendar immediately — and vice versa.
Two deployment paths — both production-ready; pick based on operational preference and how far you want to minimize cloud touchpoints:
| Path | How it works | Typical use |
|---|---|---|
| Admin connection (standard) | Room mailbox connected in Admin; meetings fetched when needed — calendar content is not stored on Meeting Room 365 servers | Most rollouts — central service user, application RBAC, or direct sign-in |
| Calendar on the device (native app) | Service user on the tablet; sync via OS calendar APIs — meeting content stays on the device | Smallest cloud footprint; see Native apps and privacy by design |
Supported calendar platforms
| Platform | Room display support | Notes |
|---|---|---|
| Microsoft 365 | Yes | Direct per-mailbox sign-in, service user, or application RBAC / client credentials |
| Google Workspace | Yes | Room calendars shared with a dedicated service user (custom admin role) |
| Microsoft Exchange (EWS) | Yes | On-premises Exchange via the EWS SOAP API |
| None (Dibs) | Yes | Walk-up reservations stored by Meeting Room 365 — no external calendar |
Microsoft 365
What you need
- A room mailbox (or equipment mailbox) in Microsoft 365 for each space you want on a display
- A connection method that fits your size and security policies (below)
When a connection error appears, use Fix Connection in the display's Calendar Connection panel to re-authenticate.
Connection methods
| Method | Best for | Summary |
|---|---|---|
| Direct sign-in | Small pilots | Each display signs in to its own room mailbox |
| Service user | Many rooms, centralized IT | One account accesses many room mailboxes (delegate or shared access) |
| Application RBAC / client credentials | Scale without per-room interactive auth | Microsoft Entra app registration + PowerShell RBAC scoped to resource mailboxes — no service user password to rotate |
Meeting Room 365 supports client credential / application RBAC connections as Microsoft's recommended pattern for connecting many resource mailboxes without signing in to each one individually. See Microsoft's application RBAC for Exchange Online and our RBAC setup guide.
Help articles:
- What permissions does Meeting Room 365 need for Office 365? — minimal scopes (profile, calendar read/write for the linked mailbox, offline access)
- Use a service user instead of direct sign-in
- Configure RBAC via PowerShell
Even with a service account or application connection, Meeting Room 365 is designed to request minimal permissions — only what room displays need to read schedules and perform walk-up booking actions.
Direct sign-in and MFA (important)
Direct connection to a room mailbox is supported and has been convenient for small deployments. Microsoft now requires a uniform MFA policy for every user in the tenant, and that includes resource mailbox accounts.
In practice, that means:
- Each room mailbox used for direct sign-in must satisfy your tenant's MFA requirements — not just people accounts.
- If you connect ten displays via ten separate room mailboxes, you need an MFA strategy for ten resource accounts — for example Microsoft Authenticator approvals tied to those mailboxes, a shared operational phone, or another approach your security team accepts.
- Many customers find this manageable for a handful of rooms but impractical at scale — which is why service users and application RBAC / client credentials are the usual path for larger rollouts.
Microsoft documents conditional access and MFA requirements in Entra ID documentation. Plan MFA for resource mailboxes before committing to direct sign-in across many rooms.
Google Workspace
What you need
- A room resource calendar in Google Workspace for each space
- A dedicated service user that can access those room calendars
- Each room calendar shared with that service user with appropriate permissions for read/write booking actions
Google Workspace does not offer a simpler third-party integration model than a limited service user with admin privileges scoped to what you need. The good news: Google now supports creating a custom admin role for the service user — for example scoped to calendar access — rather than requiring full super-admin in all cases.
Typical setup:
- Create a service user in Google Admin
- Assign a custom admin role with the permissions needed for calendar operations (see Google's admin role docs and our guides below)
- Share each room resource calendar with the service user
Requiring a service user and calendar sharing is a Google platform constraint, not a Meeting Room 365 choice. Customers comfortable with that model get reliable instant reserve, extend, and end early on the display.
Help articles:
- Assigning admin rights to a service account in Google Workspace
- Sharing resource calendars with your service user
- Getting started guide for Google Workspace
Microsoft Exchange (EWS)
What you need
- The EWS SOAP API available on your Exchange server — Meeting Room 365 connects through Exchange Web Services, not a proprietary shim
- If a gateway or proxy sits in front of Exchange, EWS must still be exposed to Meeting Room 365 in a form we can authenticate against
- Resource mailbox credentials (username format varies by Exchange version), password, EWS hostname, and Exchange version (2010 through 2019 supported in the credential form)
Support may recommend an API version override if you hit compatibility issues with a specific Exchange build.
Securing EWS access
Customers often restrict who can call EWS:
- Fixed IP allowlisting — Meeting Room 365 can connect from known IP addresses; contact support for the IPs to allow on your firewall. See Firewall settings.
- User-agent / application allowlisting — Exchange supports
EwsApplicationAccessPolicywithEnforceAllowList/EnforceBlockListto permit only approved application identities. This is a common hardening step for on-prem Exchange.
Help articles:
Dibs (no calendar)
- No mailbox or OAuth setup
- Configure a default reservation length (in seconds) for walk-up grabs — 900 seconds (15 minutes) is the default
- Supports room finder and issue reporting; calendar-specific actions (extend, end early, force check-in, private mode) are not available
See Creating a Dibs room.
Connection methods at a glance
| Method | Best for | How it works (plain language) |
|---|---|---|
| Direct (per room) | Few rooms, MFA plan in place | Each display authenticates to its own room mailbox |
| Service user (M365 / Google) | Centralized IT | One trusted account accesses many room calendars |
| Application RBAC / client credentials (M365) | Many rooms without interactive MFA per mailbox | Entra app + RBAC scoped to resource mailboxes |
| EWS credentials | On-prem Exchange | Room resource credentials against the EWS SOAP API |
| Dibs | Informal or uncalendared spaces | No external calendar — reservations local to Meeting Room 365 |
Securing displays after calendar setup
Calendar connection gets data flowing; these options lock down access once tablets are deployed:
| Option | What it does |
|---|---|
| Display key | Default — the key identifies the display; do not publish it |
| IP filtering | Restricts access to all web-based resources for that display — including calendar and display APIs — to requests from your office public IP address or range expression. Meeting titles stay off the open internet even if a display key leaks |
| Display lock | After setup, lock the display so a stored secret is required for all calendar/API access from that tablet — unlock from Admin when you need to re-provision |
See Securing your displays and IP filtering.
Supported / not supported
| Supported | Not supported |
|---|---|
| Read upcoming meetings and show live occupied/available state | Personal employee calendars on room displays (use a room resource) |
| Create, extend, and end meetings on the room calendar from the display | Calendar types outside the platforms listed above |
| M365 direct, service user, or application RBAC / client credentials | |
| Google Workspace via service user + shared room calendars | |
| Exchange 2007–2019 via EWS SOAP (with IP / user-agent hardening options) | EWS hidden behind an opaque proxy that does not expose SOAP |
| Dibs rooms without any calendar | |
| IP filtering and display lock for deployed tablets |
Best fit for
- Microsoft 365 shops — service user or application RBAC for campuses; direct sign-in only where MFA for resource mailboxes is already solved
- Google Workspace customers who can assign a scoped service user and share room calendars
- Hybrid or legacy Exchange environments with EWS exposed and firewall policies in place
- Phone booths and huddle spaces where a formal room mailbox is not worth the overhead — use Dibs instead
Need something configured?
Advanced calendar setup, RBAC scripts, EWS allowlisting, fixed IPs, or edge cases — contact support. Meeting Room 365 typically enables custom configuration the same business day.
Related help
Support articles live at www.meetingroom365.com/en/ (URLs are assigned per article). The guides linked above are the canonical references for permissions, RBAC, EWS, Google service users, and display security.