Two Microsoft 365 Tenants, One Windows Session: Why We Chose Thunderbirderic

The mailbox was healthy. Outlook on the web worked. The same account worked on other computers. Only one Windows PC refused to add it — and that PC happened to be Microsoft Entra joined to a different tenant.

That distinction sent us through three separate identity systems wearing one Outlook-shaped trench coat: Windows Web Account Manager (WAM), Microsoft 365 desktop licensing, and Outlook's own profile state. We cleared caches, counted accounts, reset applications, tested both Outlook clients, and captured the exact broker errors. Each step explained a symptom. None produced a dependable mailbox.

Our final answer was not another registry key. It was use Thunderbird instead.

This is what we learned, including how to configure Thunderbird without falling back to the basic-authentication password prompt that Microsoft 365 has already retired.

The setup that triggered it

The Windows user signed in with an account from Tenant A. The device was fully Entra joined to Tenant A and held a Primary Refresh Token (PRT) for that identity. The user also needed a normal Exchange Online mailbox from Tenant B.

The Tenant B mailbox was not broken:

• Outlook on the web worked.
• The credentials and MFA worked.
• The mailbox worked on computers that were not joined to Tenant A.
• Autodiscover and Exchange Online were reachable.

That left the local identity context as the meaningful difference.

Four errors, four different layers

The failure changed as we removed stale state. That was useful: each new message exposed the next layer underneath.

Treating all four as "Outlook cannot sign in" would have produced an endless loop of reinstalls. They came from different components and needed different evidence.

The account-limit detour

Windows 10 and 11 limit a user session to three Microsoft Entra accounts. Microsoft documents the exact resulting message: "Add account operation is blocked because account limit is reached." The limit exists to control token-request size and keep single sign-on reliable. See the Microsoft Entra device management FAQ.

The important words are user session. Our remote management shell ran as SYSTEM, so this command initially inspected the wrong profile:

Copy dsregcmd /listaccounts

The giveaway was immediate:

Copy USERPROFILE=C:\Windows\System32\config\systemprofile

WAM is per-user state. An elevated shell, service, RMM agent, or SSH daemon commonly runs under a service account and can return an empty list or a meaningless error even while the interactive user has a broken account store.

We used a temporary scheduled task with LogonType=Interactive to execute dsregcmd /listaccounts inside the signed-in user's session. After backing up and rebuilding the TokenBroker account directory, the real result was clean:

Copy User accounts: 1
Application accounts: 0
Default account: [email protected]

The count was no longer the blocker. Outlook still failed.

The silent cleanup script trap

Microsoft provides signoutofwamaccounts.ps1 for removing Office-associated WAM tokens on managed devices. It is a legitimate tool, but it has two operational surprises:

1. It is deliberately silent. Its asynchronous results are piped to Out-Null, so no output can mean success, failure before useful work, or simply no matching Office accounts.
2. It works on the current user's WAM store. Running it from an RMM shell as SYSTEM, or as a different administrator, does not clean the affected desktop user's account store.

Microsoft's activation reset guidance correctly says the script removes Office tokens without unjoining an Entra-joined device. What it cannot do is make a service-context PowerShell session become the interactive user.

The reusable rule is simple: when troubleshooting WAM, always record whoami, $env:USERPROFILE, and the session ID beside every result.

New Outlook exposed a licensing problem

Resetting the new Outlook package did not clear all of its data. Its packaged LocalState and LocalCache were empty, while %LOCALAPPDATA%\Microsoft\Olk still contained the account state. Renaming Olk to a timestamped backup finally produced a genuine first-run experience.

The next message was "Your account is not supported."

That was progress, not regression. New Outlook reads the licence attached to its accounts. Microsoft says a work or school account needs a plan that includes desktop applications to license Outlook as the initial account. Once a qualifying account is present, Business Basic or E1 mailboxes can be added as secondary accounts. The details are in Microsoft's new Outlook licensing guide.

In this case the second tenant's mailbox was not a suitable first account. Adding the Tenant A account first was theoretically valid, but it pulled us straight back into the cross-tenant WAM path we were trying to escape.

Classic Outlook gave us the decisive evidence

Classic Outlook replaced the licensing message with a generic page:

Copy Message: An unexpected error occurred.
Tag: 7anyj
Code:

The page itself was nearly useless. The timestamp was not.

We queried Microsoft-Windows-AAD/Operational for the surrounding twelve minutes. At the same second as the Outlook error, Windows logged an application-specific account warning. Before and after it, Event ID 1098 repeated this error:

Copy 0xCAA100D8
A login hint was sent that doesn't match any WebAccount in the system.

That closed the loop. Outlook was asking WAM silently for Tenant B, but WAM contained only Tenant A. The browser credentials were fine. The Exchange mailbox was fine. The tenant was fine. The local broker could not map the requested identity to an account in its store.

We tried seeding the second Office identity through another desktop Office application. That also failed. At that point we could keep editing identity stores and registry associations, or we could choose a mail client that did not inherit the Windows session's PRT and Office WAM state.

Why guest accounts and cross-tenant settings were not the first fix

Inviting the user as a guest into Tenant B sounds attractive, but a B2B guest object does not turn an existing mailbox login into a healthy Outlook desktop identity. Cross-tenant access settings can control trust, MFA claims, device claims, and inbound or outbound B2B access. They do not repair a local WAM account mapping.

Those settings matter when the Tenant B sign-in logs show a Conditional Access or cross-tenant policy denial. Our evidence stopped earlier: Windows could not even match the login hint to a local WebAccount.

Fix the layer that failed. Do not redesign tenant trust because a local token broker returned 0xCAA100D8.

Why Thunderbird was the practical answer

Thunderbird runs its own Microsoft OAuth flow and maintains its own account state. It does not need Outlook to reconcile Tenant A's Windows PRT with Tenant B's mailbox identity. That makes it a clean isolation boundary: the user signs directly into the mailbox's home tenant, completes MFA, and Thunderbird stores the resulting OAuth tokens in its own profile.

As of Thunderbird 153, native Exchange email over EWS is available without an add-on. Mozilla's Thunderbird and Exchange guide recommends version 145 or later and explains the Microsoft-hosted OAuth prompt. Thunderbird 153 made that support prominent in the new Account Hub; see the Thunderbird 153 release announcement.

For this kind of case, the immediate setup is:

1. Install Thunderbird 153 or newer.
2. Select New Account → Email.
3. Enter the Tenant B mailbox address.
4. Let Account Hub detect Exchange, or select Manual Configuration → EWS.
5. Complete the branded Microsoft OAuth and MFA flow for Tenant B.

Do not type the mailbox password into a "Normal password" IMAP configuration. Microsoft removed basic authentication from Exchange Online. OAuth is the difference between "IMAP is obsolete" and "IMAP works securely with Microsoft 365."

If EWS is unavailable, use IMAP and SMTP with OAuth2:

Microsoft explicitly lists Thunderbird as an Exchange Online IMAP client in its POP3 and IMAP4 documentation. Mozilla's Microsoft OAuth guide for Thunderbird also notes two tenant-side caveats: an administrator may need to approve Thunderbird once, and SMTP AUTH may need to be enabled for sending.

The EWS warning in August 2026

Native EWS is a good immediate bridge, not a forever architecture for Exchange Online. Microsoft begins phased EWS disablement on October 1, 2026 and plans full retirement on April 1, 2027. Administrators can temporarily allow approved EWS applications during the transition. Microsoft's current timeline is in Deprecation of Exchange Web Services in Exchange Online.

Thunderbird's Graph implementation was approaching feature parity in June 2026, but Thunderbird 153 still shipped it behind a preference while the project completed the work. For a deployment made today:

• Use native EWS if it works and the tenant is prepared to allow it during the transition.
• Use IMAP/SMTP with OAuth2 for basic mail when EWS is blocked.
• Track Thunderbird's Graph rollout for the long-term Exchange path.
• Expect email first; Exchange calendar and address-book parity is still catching up.

What we would do first next time

1. Prove the mailbox independently. Test OWA and a non-joined device before touching the tenant.
2. Map the identity contexts. Record Windows sign-in tenant, device join tenant, mailbox tenant, Office licensing account, and the user context of every shell.
3. Run WAM diagnostics as the interactive user. Never trust dsregcmd /listaccounts from SYSTEM for a desktop-user problem.
4. Use the error timestamp as a join key. A generic Outlook page becomes actionable when matched to Microsoft-Windows-AAD/Operational.
5. Separate authentication from licensing. "Account not supported" in new Outlook can be a licence decision even when OAuth and Exchange are healthy.
6. Stop when the architecture is fighting the requirement. A second mail client is cheaper and safer than repeatedly rewriting a joined user's identity stores.

The technical lesson is not that Outlook is bad or Thunderbird is magic. It is that coupling matters. Outlook integrates deeply with Windows and Microsoft 365, which is excellent when the device, user, licence, and mailbox all belong to one identity story. In a two-tenant edge case, the integration itself can become the failure domain.

Thunderbird gave the second mailbox its own OAuth boundary. That was the feature we actually needed.