This blog is about an issue where the classic version of Outlook stopped signing in, throwing CAA2000B and 4usqa errors. The funny thing is that the new “modern” Outlook worked fine, though, which made things even more confusing. We looked at the sign-in logs, tested new accounts, and eventually found what was really going on.
The Outlook Error CAA2000B
Outlook sign-in failures started appearing in multiple tenants without any obvious cause. Users who had been working normally suddenly received the CAA2000B error / AADSTS500014 (after the token expired).
In other cases, new accounts failed to sign in entirely. Initial checks showed no service issues from Microsoft. Licensing and profiles were fine, and this time, SSL inspection or a proxy wasn’t the culprit. The usual fixes like resetting credentials, reinstalling Office, and clearing cached profiles had no effect.
At that point, the focus shifted to what was happening during authentication. The answer came from a closer look at the Microsoft Entra sign-in logs and a hidden dependency that I wasn’t aware of.
Creating a New Account ended up with error: 4usqa
To rule out user-specific or profile-based problems, we created a new test account and tried signing in from scratch. The result was different, but not better. Instead of CAA2000B, we were hit with a less familiar message: 4usqa
We also tested both versions of Outlook. The classic Outlook consistently failed with CAA2000B or 4usqa, depending on the account state. However, when signing in using the new Outlook app, everything worked.
Which is pretty weird… is this how Microsoft wants to promote to start using the modern Outlook version? (just joking, of course)
Checking the Sign-In Logs in Microsoft Entra
From there on, we turned to Microsoft Entra to see what was going on under the hood. Looking at the sign-in logs, we found failure entries with the familiar user and timestamp. The sign-in error code was 500014.
When combining the sign-in log with the error code CAA2000B when opening Outlook, it became clear. Error 500014 means that the service principal for a required application is disabled. The failure reason stated:
“The service principal for resource ‘{identifier}’ is disabled. This indicates that a subscription within the tenant has lapsed, or that the administrator for this tenant has disabled the application, preventing tokens from being issued for it.”
This pointed to a disabled service principal, but which one?
The Clue Hidden in Plain Sight
One of the failed sign-in windows showed a long string under a field labeled Microsoft Information Protection API. Embedded in that string was a GUID. Running that value through the Entra admin portal revealed what we needed.
The App ID 40775b29-2688-46b6-a3b5-b256bd04df9f was linked to the Microsoft Information Protection API. And in affected tenants, this service principal was disabled.
How This Broke Outlook with CAA2000B and 4usqa
The Microsoft Information Protection API (MIP) is responsible for policy enforcement related to sensitivity labels, content classification, and encryption. It seems that the legacy version of Outlook silently contacts the MIP API Enterprise Application at startup, even if your tenant isn’t actively using classification features.
If the MIP API enterprise application is disabled, Outlook fails when trying to request the associated token. For previously signed-in users, this manifests as CAA2000B during token refresh. For brand new accounts, the result is 4usqa during the initial sign-in.
In both cases, Outlook authentication is broken, and there’s no visible link to Microsoft Information Protection API unless you go digging.
Why Only Some Tenants Were Hit by CAA2000B
Not all tenants experienced the issue. In those that did, the MIP API Enterprise Application had been disabled for some vague reason. I guess Microsoft is going to owe us a good explanation.
How to Fix the Problem
Once we knew the App ID, the fix was simple. Re-enable the sign-in of the Microsoft Information Protection API Enterprise Application.
From Microsoft Entra:
- Go to Enterprise applications in the Entra Portal
- Remove filters to view all Enterprise Applications (disabled apps don’t show up by default)
- Search for App ID
40775b29-2688-46b6-a3b5-b256bd04df9f(Or Microsoft Information Protection) - Open the Microsoft Information Protection API
- Under Properties, set Enabled for users to sign-in? to Yes
Or use PowerShell:
Update-MgServicePrincipalByAppId -AppId 40775b29-2688-46b6-a3b5-b256bd04df9f -AccountEnabled:$true
Once re-enabled, Outlook sign-ins started working again (takes about 5 cloud minutes)…. so have some patience. But… please be aware of the fact that until Microsoft fixes this issue, you need to perform these steps a couple of times during the day to keep it enabled. As shown below, Microsoft tries to disable the account for this enterprise app, each couple of hours
Microsoft’s Incident Report Timeline for ex1072812
While analyzing these Outlook sign-in issues, Microsoft also acknowledged a broader service disruption that matches the behavior we saw.
Issue summary:
Recent updates to Exchange Online, aimed at improving how the classic Outlook desktop app operates, ended up consuming more processing power than expected. This caused backend resource allocation issues and led to performance degradation for some users.
Due to the large number of affected users, the automated fix took time to apply. Microsoft advised using a manual workaround to restore access more quickly. A notification will be sent once the incident is fully resolved.
Lessons Learned
This wasn’t an Outlook bug or a Microsoft outage. It was a disabled piece of the identity puzzle that most tenants don’t even know exists. If Outlook starts throwing CAA2000B or if new users are blocked by strange errors like 4usqa, check your sign-in logs in Entra. Look for error code 500014 and trace the App ID. You may find that a hidden dependency was turned off.