Exchange Meeting Room Display: The Setup Guide (2026) · L...

If you run Exchange, you already have everything a meeting room display needs, just not in a shape you can hang on a wall. Every room is a room mailbox. That mailbox has a calendar. That calendar is the single, authoritative answer to "is this room booked right now." A room display is really just a screen that reads one room mailbox and shows the next few hours of it. The work is in the reading, and the reading depends heavily on one question: are you on Exchange Online or Exchange Server on-premises?

This post covers both, because "Exchange" has quietly meant two different things since Microsoft 365 took over the name. We will go through where the room data lives, how a display gets at it in each setup, the calendar settings that decide whether the whole thing behaves, and the honest build-versus-buy line.

First, sort out which Exchange you mean

"Exchange meeting room display" gets searched by two different people with two different problems.

Exchange Online. Part of Microsoft 365. Your room mailboxes live in Microsoft's cloud. This is the common case in 2026, and it has the most options.
Exchange Server on-premises. You run your own Exchange boxes. Room mailboxes live on your hardware. Fewer options, older protocols, and the cloud APIs do not see your mailboxes unless you run hybrid.

Both store a room as a room mailbox with a calendar, so the concept is identical. The pipe you use to read that calendar is what differs, and getting that wrong is the most common reason a "simple" display project stalls.

Reading a room mailbox on Exchange Online

If your rooms are in Exchange Online, the modern path is the Microsoft Graph API, and it is genuinely clean. Two endpoints carry the load. You list rooms with the Places API and you check availability with getSchedule:

POST https://graph.microsoft.com/v1.0/me/calendar/getSchedule
{
  "schedules": ["boardroom@yourdomain.com"],
  "startTime": { "dateTime": "2026-06-30T08:00:00", "timeZone": "Europe/Copenhagen" },
  "endTime":   { "dateTime": "2026-06-30T18:00:00", "timeZone": "Europe/Copenhagen" },
  "availabilityViewInterval": 15
}

Grant Calendars.Read app-only so the display authenticates as itself, not as a person who has to stay signed in. We go through the full build, including the parts that are harder than they look, in building a meeting room display with Microsoft Graph. There is also the older EWS path (below), which still works against Exchange Online, but for anything new on the cloud, Graph is the right tool.

Reading a room mailbox on Exchange Server (on-prem)

This is where people get caught. The Graph API does not reach mailboxes that live on your own Exchange Server. If you are fully on-premises, the supported route is Exchange Web Services (EWS), the SOAP API that has been the workhorse for room and calendar access for years. A display talks to EWS through your server's Autodiscover endpoint, authenticates with a service account, and reads the room's free or busy times with a GetUserAvailability request.

A few things to plan for on the on-prem route:

A service account with impersonation. You want the display to read room calendars without a real user logged in. EWS Impersonation, scoped to the room mailboxes, is the usual way to do that.
Autodiscover and certificates. The display needs to find your EWS endpoint and trust its certificate. Internal-only certificates are a frequent snag.
EWS is in maintenance, not development. Microsoft has steered new cloud work to Graph, but EWS remains the supported way in for on-prem Exchange. If you are hybrid, you have a choice: read cloud-homed rooms via Graph and on-prem rooms via EWS, or move the room mailboxes to the cloud and standardise on Graph.

The settings that make or break it, on either

However you read the calendar, the room mailbox has to be configured to keep that calendar accurate, or your beautiful display just shows wrong information faster. The key one is calendar processing. A room mailbox should automatically accept and decline booking requests so its calendar reflects reality without a human approving each one:

Set-CalendarProcessing -Identity "boardroom@yourdomain.com" -AutomateProcessing AutoAccept

This command exists in both Exchange Online PowerShell and on-prem Exchange Management Shell. Get it wrong and rooms either never show as booked (because requests sit pending) or show conflicting double-bookings. We dug into the specific switches that matter, and the ones that look important but are not, in room mailbox auto-accept in Microsoft 365, and the broader hygiene checklist lives in Microsoft 365 room mailboxes. If your room mailbox is set up right, putting it on a wall is the easy part. If it is not, no display will save you.

The part a calendar read does not solve: ghost meetings

Reading the calendar tells you the room is booked. It does not tell you whether anyone actually walked in. The single biggest reason rooms get displays is the ghost meeting: booked, nobody turns up, room sits locked for an hour while three people stand in the corridor. Fixing that needs a check-in button at the door and an auto-release when nobody checks in, which means writing back to the room mailbox, not just reading it. That write-back is the same job whether the mailbox is in the cloud or on-prem, and it is covered in releasing a meeting room automatically.

The hardware, briefly

Reading Exchange is one layer. A display is also a physical screen that has to boot, render, and survive on a wall without a babysitter. That is its own decision, and the trade-offs between e-ink, a tablet, and a TV are laid out in e-ink vs tablet vs TV. Exchange has no opinion on which you pick. It just hands over the calendar.

Build or buy

Building your own Exchange room display is realistic, especially on Exchange Online where Graph does most of the heavy lifting. The cost is rarely the licence. It is the engineering tail: app auth that renews itself, throttle-aware polling, the check-in and release write-back, the hardware, and a way to update screens you cannot easily reach. For on-prem via EWS, add the service account, impersonation, and certificate work on top. Under roughly 30 rooms, a finished product is almost always cheaper once you count that tail.

Lobby is the buy side here. It connects to Exchange Online room calendars through Graph, handles the auth, the polling, and the check-in and release loop, and runs on a low-power e-ink display. For pure on-premises Exchange with no hybrid, you would still be looking at an EWS build of your own, so it is worth knowing which Exchange you actually run before you spec anything. If your rooms are in Microsoft 365, the path from "room mailbox" to "screen on the wall" is short.

TL;DR

An Exchange meeting room display reads one room mailbox calendar and shows it at the door. On Exchange Online, use the Microsoft Graph API (getSchedule, app-only Calendars.Read). On Exchange Server on-prem, use EWS with a service account and impersonation, because Graph cannot see on-prem mailboxes. Either way, set the room mailbox to auto-accept with Set-CalendarProcessing or the calendar will be wrong. Add a check-in and auto-release loop to kill ghost meetings. Under about 30 rooms, buying beats building once you count auth, throttling, hardware, and updates.

Exchange Meeting Room Display: How to Put a Room Calendar on the Wall (Online and On-Prem)