
{/* banner prompt: A clean isometric technical illustration of a Windows laptop caught between two tall cloud-office towers in different colors. A jammed identity turnstile made of key cards and token rings blocks the direct path from the laptop to the second tower. A confident blue mail bird carrying a sealed envelope flies around the turnstile through a separate glowing OAuth gateway. Light gray background, restrained blue, teal and amber palette, crisp editorial infographic style, no company logos, no readable text, no error-code typography. */}

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.

<Table data={
    {
        headers: ['Client or test', 'Visible symptom', 'What it actually told us'],
        rows: [
            ['New and classic Outlook', 'Add account operation is blocked because account limit is reached', 'Windows WAM believed the user had exhausted its Entra account slots'],
            ['New Outlook after reset', 'Your account is not supported', 'The mailbox could not license new Outlook as its first account'],
            ['Classic Outlook', 'An unexpected error occurred, tag 7anyj', 'The Windows identity broker could not match Outlook\'s login hint to a cached WebAccount'],
            ['Manual IMAP in Outlook', 'A plain username and password prompt', 'Outlook had selected basic authentication, which Exchange Online no longer accepts'],
        ]
    }
} />

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](https://learn.microsoft.com/en-ca/entra/identity/devices/faq).

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

```powershell
dsregcmd /listaccounts
```

The giveaway was immediate:

```text
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:

```text
User accounts: 1
Application accounts: 0
Default account: tenant-a-user@example.com
```

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](https://learn.microsoft.com/en-us/previous-versions/troubleshoot/microsoft-365/microsoft-365-apps/activation/reset-office-365-proplus-activation-state) 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](https://learn.microsoft.com/en-us/microsoft-365-apps/outlook/get-started/licensing-options).

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:

```text
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:

```text
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](https://support.mozilla.org/en-US/kb/thunderbird-and-exchange) 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](https://blog.thunderbird.net/2026/07/thunderbird-153-meadow-is-out-now/).

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:

<Table data={
    {
        headers: ['Purpose', 'Server', 'Port and transport', 'Authentication'],
        rows: [
            ['Incoming mail', 'outlook.office365.com', '993, SSL/TLS', 'OAuth2'],
            ['Outgoing mail', 'smtp.office365.com', '587, STARTTLS', 'OAuth2'],
        ]
    }
} />

Microsoft explicitly lists Thunderbird as an Exchange Online IMAP client in its [POP3 and IMAP4 documentation](https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/pop3-and-imap4/pop3-and-imap4). Mozilla's [Microsoft OAuth guide for Thunderbird](https://support.mozilla.org/en-US/kb/microsoft-oauth-authentication-and-thunderbird-202) 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](https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-ews-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.


d4865dc4478d5cfb1d2de86f68bf0b7b5045bccc1845fc647fc0ccc3643698b6

A practical investigation of cross-tenant Outlook failures on an Entra-joined Windows PC, including WAM diagnostics, misleading fixes, and the Thunderbird alternative.

A Microsoft Entra-joined PC could open a second tenant's mailbox everywhere except Outlook. WAM limits, PRT routing, licensing checks, and a silent cleanup script eventually pointed us to the simpler answer: Thunderbird with OAuth.

Tag: Identity

Tag: Identity

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