What it does

The resource account is the room's identity — an Exchange room mailbox plus an Entra ID account that the Teams Rooms console signs in with, reads its calendar through, and carries the room licence. Get it right and the device mostly looks after itself; get it wrong and you'll be chasing sign-outs and missing join buttons for months.

Key facts

• Every Teams Rooms device needs its own unique resource account and one Teams Rooms licence (Basic or Pro) assigned to it. Teams panels outside the same room sign in with the same account as the in-room device.
• Supported creation routes: Microsoft 365 admin center, Exchange Online PowerShell, Exchange Server PowerShell, or converting an existing room mailbox.
• Password expiry must be disabled: Update-MgUser -UserId <upn> -PasswordPolicies DisablePasswordExpiration. If the password expires, the device signs out and needs someone on site.
• The UPN must match the primary SMTP address.
• New room mailboxes default to Pacific Standard Time. Change the mailbox time zone to the room's real location — check-in and auto-release on panels depend on it too.
• Recommended Set-CalendarProcessing values: AutomateProcessing AutoAccept, AddOrganizerToSubject $false, AllowRecurringMeetings $true, DeleteAttachments $true, DeleteComments $false, DeleteSubject $false, ProcessExternalMeetingMessages $true, RemovePrivateProperty $false, plus an optional AdditionalResponse (HTML allowed).
• Microsoft 365 admin center defaults: repeat meetings allowed, auto-accept on, 180-day booking window, 24-hour maximum duration.
• Teams shared devices don't support Entra ID Security defaults — you have to secure resource accounts with Conditional Access instead.
• Cloud-only accounts (Entra ID plus Exchange Online) are the recommended pattern. Exchange on-premises works only in a hybrid configuration.
• For Room Finder, set place attributes (building, city, capacity, accessibility, features) with Set-Place. A room without them won't show as bookable even if it's in a room list.
• Microsoft's Teams Rooms Sign-In Test at testconnectivity.microsoft.com validates the account before the engineer arrives.

When to use / skip

You don't get a choice about whether to have one — every Teams Rooms, Surface Hub and panel deployment needs it. The decision is how you build them. For anything above a handful of rooms, script it: a CSV of rooms, one PowerShell run that creates the mailbox, sets calendar processing, time zone, place attributes, password policy and licence. Hand-building through the admin center is fine for a pilot and a liability for a rollout.

If the client already has room mailboxes in Outlook that people book today, convert those rather than creating new ones. Users keep their room names and existing bookings, and you avoid two "Boardroom 3" entries in the address book.

Configuration decisions

• Naming convention. A fixed prefix (Microsoft suggests mtr-) makes dynamic groups for licensing, Conditional Access exclusions and Intune targeting trivial. Agree it before the first account is created.
• Display name format for the GAL — building, floor, room, capacity is the usual pattern. This is what users search for in Outlook.
• Whether to keep DeleteComments $false (needed if you want third-party join buttons for Zoom/Webex/Meet) versus a security team preference to strip invite bodies.
• ProcessExternalMeetingMessages — on if partners book the room directly or you want external invites forwarded in to join.
• Booking window and maximum duration per room type; boardrooms often get tighter rules or delegate approval.
• Conditional Access approach: location-based or compliant-device policies for the room accounts, kept separate from user MFA policies.
• Basic vs Pro licence per room — decided commercially elsewhere, but it has to be assigned here.

Gotchas

• The PST default catches nearly everyone. A London room set to Pacific time shows the wrong meetings and auto-releases rooms at odd hours.
• Security defaults on the tenant will block device sign-in. If the client hasn't moved to Conditional Access yet, that's a dependency on someone else's project.
• Blanket "MFA for all users" CA policies hit the room accounts too. Exclude them by group and apply a device-appropriate policy instead.
• Rooms without Set-Place attributes vanish from Room Finder. People blame the device; it's the mailbox.
• Password rotation policies from a security baseline will quietly break rooms 90 days after go-live. Get the exception signed off in writing.
• DeleteAttachments $true means presenters can't rely on attachments on the room calendar — the room can't open them anyway, but expect the question.

Consultant notes

• Build a room data sheet early: room name, mailbox, display name, building, floor, capacity, licence, device model, panel yes/no. It becomes the source for the creation script and the Pro Management Portal inventory.
• Run the Sign-In Test against a sample of accounts before shipping devices to site. It saves a wasted engineer visit.
• Allow propagation time between creating accounts and signing in devices. Creating accounts the night before install is asking for trouble.
• Set a minimum 10 Mbps bandwidth policy and turn on PowerPoint Live, Whiteboard and shared notes in the meeting policy assigned to room accounts, as Microsoft recommends.
• Keep the creation script in the client's repo. Room moves and refreshes are the same script with different rows.

---

Recheck the calendar processing recommendations if Microsoft changes how the room reads third-party join links, or if the client moves room bookings to Microsoft Places