LOBBY
setup guides· 9 min read

Room Lists in Exchange Online: Why Room Finder Needs Them and How to Build Them

Room Finder will not show a room that is not in a room list, and a room list is just a distribution group with a flag set. Here is what that flag does, how to build the lists properly, and the audit script that finds every orphaned room.

The ticket always reads the same way. "Room Finder is empty." The rooms exist. You can see them in the Exchange admin center. You can book them by typing the address into the To field. They just do not appear in the panel that Outlook shows when someone clicks Room Finder, and no amount of restarting Outlook changes that.

The cause is almost always a room list, or the absence of one. This post is the dedicated treatment of that object: what a room list actually is under the hood, why Room Finder depends on it absolutely, how to create and populate one correctly, the propagation delay that makes people think their fix did not work, the size limits that matter, how room lists interact with Places metadata, and an audit script that lists every room mailbox in the tenant alongside the room lists it belongs to (including the ones that belong to none).

A room list is a distribution group with a flag

There is no separate object type. A room list is a normal distribution group with the RoomList switch set on it, and Exchange treats it specially only because that switch declares that every member is a room mailbox. Microsoft's own wording is direct: the RoomList switch specifies that all members of this distribution group are room mailboxes, and you do not specify a value with it.

Two consequences follow immediately and both surprise people:

  • You can only create room lists in PowerShell. They are not available in the Exchange admin center. You can add members through the EAC once the list exists, but the list itself has to be created in the shell.
  • Room lists are not containers for other room lists. The flag asserts that the members are room mailboxes. Do not build a hierarchy by nesting one room list inside another. If you need structure, create several sibling lists (one per building, or per floor range) rather than a tree.

Why Room Finder needs one

Room Finder is not an address book browser. It is a filtered search over a set of buildings, and it derives that set of buildings from your room lists. Microsoft's troubleshooting article for the empty Room Finder says it plainly: the issue occurs if the user does not select a room list, and a room list must be selected before available rooms are displayed.

The subtlety that trips up experienced admins: Room Finder displays room lists as the values for the Building filter. It does not use the Building property on the room. You can set -Building "Copenhagen HQ" on all eleven of your rooms with Set-Place, verify it reads back correctly, and still see nothing in Room Finder, because that property is not what populates the dropdown. Microsoft recommends populating Building anyway for forward compatibility, but it will not fix your Room Finder today.

Room Finder also needs three pieces of metadata configured on each room to be useful: City, Floor and Capacity. Without those, the room may appear but the filters have nothing to filter on.

Creating a room list

Connect first:

Connect-ExchangeOnline -UserPrincipalName admin@contoso.com

Then the syntax. Everything in brackets is optional and derived from -Name if you leave it out:

New-DistributionGroup -RoomList -Name <Name> [-Alias <Alias>] `
  [-DisplayName "<DisplayName>"] [-PrimarySmtpAddress <EmailAddress>]

A concrete example:

New-DistributionGroup -RoomList -Name "Copenhagen HQ"

Because Alias, DisplayName and PrimarySmtpAddress were not specified, they are derived from the Name: the alias becomes CopenhagenHQ, the display name becomes Copenhagen HQ, and the primary SMTP address comes from the email address policy, falling back to CopenhagenHQ as the local part if the policy does not specify an alias.

Be deliberate about the Name, because it is what users see as the Building value in Room Finder. Name it after the building, not after a team, a project, or a floor unless the list really is a floor.

Adding rooms

Add-DistributionGroupMember -Identity "Copenhagen HQ" -Member cph-02-amsterdam@contoso.com

To add every room mailbox whose address matches a pattern, which is where a good naming convention pays for itself:

Get-Mailbox -RecipientTypeDetails RoomMailbox -ResultSize Unlimited |
  Where-Object { $_.PrimarySmtpAddress -like "cph-*" } |
  ForEach-Object {
    Add-DistributionGroupMember -Identity "Copenhagen HQ" -Member $_.PrimarySmtpAddress
  }

If that -like filter does not select cleanly against your addresses, your naming is the underlying problem. See meeting room naming conventions before you script anything at scale.

The propagation delay that makes people think it failed

This is the single most common reason an admin concludes room lists do not work.

Microsoft states that after you create, delete or modify a room list, or add or remove a member, you should allow 24 to 48 hours for the change to appear in Room Finder. The same window applies to City, Floor, Capacity and the other Place properties. During that period Room Finder may not show the expected results.

So: make the change, verify it in PowerShell immediately (which will show the correct state right away), and then do not test in Outlook until tomorrow. Do not make a second change on the theory that the first one did not take. Compounding changes during the propagation window is how people end up with duplicate lists.

Converting an existing distribution group

Plenty of tenants already have a group called something like "Meeting Rooms" that contains all the room mailboxes and was never flagged. You do not need to recreate it. Set the flag:

Set-DistributionGroup -Identity "Meeting Rooms" -RoomList

This conversion is PowerShell only as well. Before you run it, verify that every member is actually a room mailbox, because the flag is an assertion about the membership and a group containing user mailboxes will behave oddly.

Size limits and how to structure lists

There is no hard cap on how many rooms you can put in a room list, but there are two operational numbers you should design around:

  • 100 is the maximum number of rooms and workspaces that Room Finder will return in a search.
  • 50 is Microsoft's recommended maximum per room list, for performance.

Room lists can be organised by buildings, by floor ranges within a building, by wings within a building, or by groups of similar rooms. For most offices with 20 to 100 people the answer is one list per building and nothing more. Once a building exceeds about 50 bookable spaces, split it by floor range:

New-DistributionGroup -RoomList -Name "Copenhagen HQ Floors 1 to 3"
New-DistributionGroup -RoomList -Name "Copenhagen HQ Floors 4 to 6"

One more rule that is easy to violate accidentally: keep one city per room list. If a list contains rooms in two cities, it will only appear when a user filters for the city where the majority of its rooms are located. The minority rooms become effectively invisible in Room Finder even though they are correctly configured.

Places metadata: Set-Place

The room list gets the room into Room Finder. Set-Place makes the filters work.

Set-Place -Identity cph-02-amsterdam@contoso.com `
  -CountryOrRegion DK `
  -State "Hovedstaden" `
  -City "Copenhagen" `
  -Building "Copenhagen HQ" `
  -Floor 2 `
  -FloorLabel "Second" `
  -Capacity 8 `
  -Tags "Whiteboard","VC"

City, Floor and Capacity are the three Microsoft calls out as required for Room Finder to work effectively. FloorLabel is optional and gives a friendly name such as Ground, Basement or Lobby. Tags populates the Features filter dropdown, so use it for the things people actually search on (video conferencing, whiteboard, accessibility) rather than for internal asset codes.

If a room is a workspace rather than a meeting room, it is a different mailbox type and gets capacity enforcement separately:

New-Mailbox -Name workspace1 -DisplayName "Workspace 1" -Room | Set-Mailbox -Type Workspace

Set-CalendarProcessing workspace1@contoso.com -EnforceCapacity $true

Verifying a room list

Microsoft's own verification sequence, which is worth running verbatim because the Localities check is not obvious:

$FormatEnumerationLimit = -1

Get-DistributionGroup -Identity CopenhagenHQ@contoso.com

Get-DistributionGroupMember -Identity CopenhagenHQ@contoso.com

$members = Get-DistributionGroupMember -Identity CopenhagenHQ@contoso.com |
  Select-Object Name |
  ForEach-Object { Get-Place -Identity $_.Name | Format-List }

$members

The room is set up correctly when two things are true in that output. First, for every room, the part of the SMTP address after the @ matches the SMTP address listed for the room list in its Localities property. Second, every room in the list has the same value for City.

To list every room list in the tenant with its members:

$RL = Get-DistributionGroup -ResultSize Unlimited -RecipientTypeDetails RoomList

$RL | ForEach-Object {
  Get-DistributionGroup -Identity $_.Identity |
    Format-Table Name, DisplayName, PrimarySmtpAddress
  Get-DistributionGroupMember -Identity $_.Identity
}

The audit: which rooms are in no list at all

This is the script worth keeping. It walks every room list, builds a reverse index of room to list, then reports every room mailbox in the tenant with the lists it belongs to. Rooms in no list come back as NONE, and those are the ones your users cannot find.

$map = @{}

Get-DistributionGroup -ResultSize Unlimited -RecipientTypeDetails RoomList |
  ForEach-Object {
    $listName = $_.DisplayName
    Get-DistributionGroupMember -Identity $_.Identity -ResultSize Unlimited |
      ForEach-Object {
        $addr = $_.PrimarySmtpAddress.ToString()
        if (-not $map.ContainsKey($addr)) { $map[$addr] = @() }
        $map[$addr] += $listName
      }
  }

Get-Mailbox -RecipientTypeDetails RoomMailbox -ResultSize Unlimited |
  ForEach-Object {
    $addr = $_.PrimarySmtpAddress.ToString()
    [PSCustomObject]@{
      Room          = $_.DisplayName
      Address       = $addr
      RoomLists     = if ($map.ContainsKey($addr)) { $map[$addr] -join "; " } else { "NONE" }
      HiddenFromGAL = $_.HiddenFromAddressListsEnabled
    }
  } |
  Sort-Object RoomLists, Room |
  Export-Csv .\room-list-audit.csv -NoTypeInformation

Open the CSV and sort by RoomLists. Every row reading NONE is a room that will never appear in Room Finder. Every row where HiddenFromGAL is True is a room that will not appear even if it is in a list, because a room hidden from the global address list is hidden from Room Finder too.

Hybrid environments

If you run Exchange Server on-premises alongside Exchange Online, the room list lives on-premises and syncs to the cloud. Microsoft's sequence:

  1. Create the room list on an on-premises server and sync it to the cloud.
  2. Create on-premises room mailboxes and sync them.
  3. Create cloud room mailboxes as remote synced mailboxes using New-RemoteMailbox with the -Room switch in the Exchange Management Shell.
  4. Add both the on-premises and remote synced room mailboxes to the on-premises room list with Add-DistributionGroupMember.
  5. Configure the properties on both room mailboxes using Set-User in the Exchange Management Shell.

Doing this the other way round (creating the list in Exchange Online while mailboxes live on-premises) is the usual source of hybrid room list mysteries.

The short failure checklist

  1. Is the room in a room list? Run the audit above.
  2. Is the room hidden from the GAL? Get-Mailbox <room> and check HiddenFromAddressListsEnabled is False.
  3. Did you change something in the last 48 hours? Wait.
  4. Does the room have City, Floor and Capacity set? Get-Place.
  5. Does the room list mix cities? Split it.
  6. Is the list over 50 rooms? Split it.
  7. Is the room actually a room mailbox? Get-Mailbox <room> | Select RecipientTypeDetails should say RoomMailbox.

If all seven pass and Room Finder is still empty, the problem is on the client side rather than in the directory, and Outlook Room Finder not showing rooms covers the rest of that path.

The buy side of this decision

Room lists are free and take about twenty minutes for a single-building office. There is no product to buy here, and anyone selling you one for this specific problem is selling you a wrapper around New-DistributionGroup.

The related thing you might buy is the display layer. Lobby reads Microsoft 365 room resources and Google Calendar and shows room state outside the room: a physical e-ink display on 7.5-inch e-ink hardware from USD 69 per room that you buy once direct from the manufacturer and own (less at volume, USD 62.99 each at 10 or more), a virtual display that is just a URL in any browser tab, or a room overview board for a reception. Pricing is on our pricing page: free forever for up to 3 displays with 15 minute e-ink refresh and no credit card, then USD 30 per month billed yearly (USD 360 a year, or USD 50 month to month) for unlimited displays, and USD 60 per month billed yearly (USD 720 a year, or USD 100 month to month) for Pro Unlimited with 5 minute refresh, Lobby-hosted e-ink screens, custom templates and branding, and Slack booking. Yearly billing saves 40% against the month-to-month rate. Setup is self-serve and takes under 10 minutes.

What it does not do, relevant here: it does not create or maintain room lists, and it does not depend on them either, so a correctly configured display can quietly mask a Room Finder problem that still bites everyone booking from Outlook. Fix the lists regardless. The rooms product also does not do desk booking, visitor management, room automation or AV control, or enterprise SSO and SCIM at scale, there is no MDM on the e-ink hardware, and on-premises Exchange requires hybrid.

If the lists are correct and the next thing you want is that state on the wall, our Microsoft 365 meeting room displays page covers what the display layer reads from Exchange and what it does not.

TL;DR

  • A room list is a distribution group with the RoomList switch set. It can only be created (or converted) in PowerShell, not the EAC.
  • Room Finder derives its Building filter from room lists, not from the Building property on the room. No list means no rooms.
  • New-DistributionGroup -RoomList -Name "Building" then Add-DistributionGroupMember. Do not nest room lists.
  • Allow 24 to 48 hours for any room list or Place change to appear in Room Finder. Verify in PowerShell immediately, test in Outlook tomorrow.
  • Cap lists at about 50 rooms (Room Finder returns at most 100 in a search) and keep one city per list.
  • Set-Place with City, Floor and Capacity is what makes the filters work once the room is visible.
  • Run the audit script periodically. Rooms drift out of lists when they are recreated, and nobody notices until a ticket arrives.

Related reading

Sources

Try Lobby — free forever up to 3 displays

Room booking that just works.

Get started →