Why Your Microsoft Bookings Page Suddenly Has No Owner and How to Fix It with PowerShell

Microsoft Bookings is convenient, but the way it handles Scheduling Mailboxes occasionally creates problems for administrators – especially when the original creator of a booking page leaves the company.

Here’s the scenario many admins eventually face:

• A user creates a Bookings page.
• That user leaves the company.
• After 30 days, the deleted account is permanently removed.
• The Bookings SchedulingMailbox remains alive… but with no owner and no permissions assigned.
• No one can manage the calendar, edit services, or update availability.

And because Scheduling Mailboxes aren’t visible like standard shared mailboxes, finding out who has access (or confirming that nobody does) isn’t obvious.

This PowerShell snippet solves that problem by generating a full permissions report for all SchedulingMailbox objects in Exchange Online – including those that have no delegated users at all.

Why this matters

Orphaned Booking pages cause operational issues:

• Employees cannot modify booking rules.
• Admins cannot sign in to the calendar to troubleshoot issues.
• Front-desk staff cannot change working hours or assign staff.
• In extreme cases, customers can book appointments that no one sees.

But before you fix the problem, you need to detect it and ideally, know which mailboxes are inactive or missing owners.

Detecting orphaned Scheduling Mailboxes

I created a small PowerShell script that scans all SchedulingMailbox objects in your tenant and shows:

• When each mailbox was created
• Whether it’s inactive
• Who (if anyone) has permissions
• Which mailboxes are completely ownerless — the “orphaned” ones causing all the problems

This gives you a clear, simple dataset telling you exactly which Booking pages are unmanaged.

Interpreting the results

Once you run the script, each row in the output represents either:

A delegated user

If a user has FullAccess (or other rights) assigned, the script shows:

• User – who has access
• AccessRights – usually FullAccess
• WhenCreated – useful for tracing legacy pages
• IsInactiveMailbox – in case the SchedulingMailbox itself is disabled

These Booking pages are managed and healthy.

A mailbox with no permissions at all

If both User and AccessRights are NULL, you’ve found a problem:

This Booking page has no owner.
No one can manage it.
It was likely created by a user who has since been permanently deleted.

These are the Booking pages you want to fix immediately.

Assigning a new administrator to the orphaned Booking page

After identifying the SchedulingMailbox that needs attention, assign a new owner using:

Within seconds, the new owner will be able to:

• Open the Bookings page
• Modify services and availability
• Manage staff
• Update scheduling rules
• Disable or delete the Bookings site if needed

This is often all that’s required to bring a broken Bookings process back to life.

Final thoughts

Orphaned Booking pages are incredibly easy to miss and extremely disruptive when left unresolved.
Running this report periodically ensures you always know:

• which pages are active,
• which are abandoned,
• and who actually owns them.

You can even integrate this into a monthly audit to prevent unexpected scheduling issues.

Script Source

The complete script is available on the Azure365GitHub.

Feel free to adapt it, expand it, or integrate it into your internal housekeeping routines.

Happy scripting!