Bookings admin force-signs-out the user, while Outlook Web in the same session stays signed in

Question

Bookings admin force-signs-out the user, while Outlook Web in the same session stays signed in

dr. PiBì Omniology Research Center 20

Environment

Microsoft 365 corporate tenant (federated SSO, MFA satisfied).
Reproduced on Chrome/macOS and Chrome/Windows 11 — different machines, different profiles, same user.
No tenant admin rights on my side.

Symptom

Opening either of

https://outlook.office.com/bookings/homepage
https://bookings.cloud.microsoft/bookings/homepage

immediately redirects to

https://login.microsoftonline.com/common/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Fwww.microsoft.com&client-request-id=<guid>&state=<...>

and lands on the tenant-branded page "Your account has been signed out — try closing all browser windows."

On some attempts the logout URL also carries logout_hint=<my UPN>.

No AADSTS error code is ever displayed. Signing in again and retrying reproduces it every time — about half a dozen attempts over four days.

What still works, in the very same browser session

Outlook on the web (outlook.office.com/mail) stays signed in and fully usable.
Our corporate SSO web portal stays signed in.
The public Bookings pages (/book/...) load fine.

So only the Bookings admin app triggers the sign-out.

What makes me doubt the obvious explanation

My first guess was Conditional Access / device compliance. But two details argue against it:

The logout is issued against /common/, not against the tenant — which reads like the Bookings app itself calling the logout endpoint, not the tenant evicting the session.
If it were a device-level CA policy, Outlook Web in the same session and the same browser should fall too. It does not.

Questions

Is it known behaviour for the Bookings admin app to call /common/oauth2/v2.0/logout instead of surfacing an AADSTS error — for example when the user has no Bookings license, no Exchange Online mailbox backing the booking calendar, or when Bookings is switched off at tenant level (Set-OwaMailboxPolicy -BookingsEnabled, or the org-level Bookings toggle in the M365 admin center)?
Where would this surface on the admin side: Entra sign-in logs (interactive vs non-interactive), a Conditional Access "sign-in frequency" / "persistent browser session" policy, or the Exchange Online side?
Given only the client-request-id, is there any way for a non-admin user to obtain the actual failure reason?

I would like to bring our IT a specific thing to check rather than a generic "Bookings doesn't work". Any pointer on which layer to look at first — license, mailbox policy, or Conditional Access — would be very helpful.

dr. PiBì Omniology Research Center 20 Reputation points

2026-08-23T10:56:22.2433333+00:00

Thanks — but an update from my side changes the picture. Clearing all browser cookies fixed it: the Bookings admin now opens normally. That rules out tenant-level BookingsEnabled, licensing and mailbox provisioning, since none of those change when you clear a browser. It points at the browser session instead. A detail I should have included: this Chrome profile had TWO Microsoft accounts signed in at once, the work account and a personal MSA. That would explain why the logout is issued against /common/ rather than the tenant, and why only Bookings fell while Outlook Web, already bound to one account, kept working. So the real question is: is the Bookings admin app known to mis-resolve the account in a multi-account browser session and react with a forced global sign-out instead of showing an account picker? And is there a supported way to pin it to one account, short of keeping a separate browser profile? Clearing all cookies every morning is not a workable routine.
Hani-Ng 1,130 Reputation points Independent Advisor

2026-08-23T11:25:55.56+00:00

Hi dr. PiBì Omniology Research Center

Thanks for the update. Since clearing cookies resolved the issue, that points away from tenant-side causes such as Bookings configuration, licensing, or mailbox provisioning.

The detail about having both a work account and a personal Microsoft account signed in to the same Chrome profile is particularly relevant. The use of the /common endpoint is consistent with an account-selection flow that has not yet been resolved to a specific tenant, and stale cookies or cached authentication tokens can sometimes result in unexpected sign-in behavior.

Given that Bookings is now opening normally, the evidence points more toward a browser-side account resolution or cached authentication issue than a service or tenant configuration problem.

For ongoing use, separate browser profiles for work and personal accounts tend to be the most reliable approach. Using an InPrivate/Incognito window for one of the accounts is another option if maintaining separate profiles is not practical.

Answer accepted by question author

0 additional answers

Your answer

dr. PiBì Omniology Research Center 20 Reputation points

2026-08-23T10:56:22.2433333+00:00

Thanks — but an update from my side changes the picture. Clearing all browser cookies fixed it: the Bookings admin now opens normally. That rules out tenant-level BookingsEnabled, licensing and mailbox provisioning, since none of those change when you clear a browser. It points at the browser session instead. A detail I should have included: this Chrome profile had TWO Microsoft accounts signed in at once, the work account and a personal MSA. That would explain why the logout is issued against /common/ rather than the tenant, and why only Bookings fell while Outlook Web, already bound to one account, kept working. So the real question is: is the Bookings admin app known to mis-resolve the account in a multi-account browser session and react with a forced global sign-out instead of showing an account picker? And is there a supported way to pin it to one account, short of keeping a separate browser profile? Clearing all cookies every morning is not a workable routine.
Hani-Ng 1,130 Reputation points Independent Advisor

2026-08-23T11:25:55.56+00:00

Hi dr. PiBì Omniology Research Center

Thanks for the update. Since clearing cookies resolved the issue, that points away from tenant-side causes such as Bookings configuration, licensing, or mailbox provisioning.

The detail about having both a work account and a personal Microsoft account signed in to the same Chrome profile is particularly relevant. The use of the /common endpoint is consistent with an account-selection flow that has not yet been resolved to a specific tenant, and stale cookies or cached authentication tokens can sometimes result in unexpected sign-in behavior.

Given that Bookings is now opening normally, the evidence points more toward a browser-side account resolution or cached authentication issue than a service or tenant configuration problem.

For ongoing use, separate browser profiles for work and personal accounts tend to be the most reliable approach. Using an InPrivate/Incognito window for one of the accounts is another option if maintaining separate profiles is not practical.

Answer 1

Hi dr. PiBì Omniology Research Center

According to my research based on your description, Outlook on the web remains signed in and fully functional in the same browser session suggests that the user's Entra ID session, MFA state, and SSO flow are all still valid. If this were a general authentication or device-compliance issue, I would normally expect other Microsoft 365 workloads to be impacted as well.

My first recommendation would be for the IT team to check the Bookings-specific configuration:

Whether Shared Bookings has been disabled at the organization level. Microsoft documents that admins can disable the service using Set-OrganizationConfig -BookingsEnabled $false or through Microsoft 365 Admin Center > Settings > Org settings. If Bookings has been disabled for the organization, users won't be able to access the management experience (Turn on or off Shared Bookings for organization | Microsoft Learn)
Whether the affected user has a license that includes Microsoft Bookings, and whether the Bookings service plan is enabled
Whether the user has a properly provisioned Exchange Online mailbox
Whether any Outlook Web App mailbox policy restrictions have been applied that could affect Bookings access

The redirect to /common/oauth2/v2.0/logout does not provide enough information by itself to determine the underlying cause. Several factors could potentially lead to this behavior, including Bookings licensing, Exchange Online mailbox configuration, Bookings service settings, or access policies. The most reliable way to identify the actual trigger is to review the corresponding Entra ID sign-in logs and any Conditional Access results recorded at the time of the attempt.

For troubleshooting, you would ask your administrators to review:

Entra ID sign-in logs (both Interactive and Non-Interactive entries)
Conditional Access results for the timestamp of the failure
Bookings tenant settings (BookingsEnabled)
Licensing for the affected user
Exchange mailbox status and applicable OWA mailbox policies.

Regarding the client-request-id, this value is primarily a correlation identifier. A non-admin user typically cannot use it to determine the root cause directly. However, administrators or Microsoft Support can use it together with the timestamp to locate the corresponding backend events.

A practical troubleshooting approach would be to verify the Bookings tenant settings and user licensing first, followed by Exchange Online mailbox and policy configuration. If those appear correct, reviewing the Entra ID sign-in logs and Conditional Access results would be the next logical step.

I hope this informatrion helps.

If the answer is helpful, please click "Yes". If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in the forum documentation to enable e-mail notifications if you want to receive the related email notification for this thread.