MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Fehler 4usqa Code 3399614475

Im Mai 2025 haben sich in Foren Meldungen zu einem Fehler "4usqa" mit Outlook und Exchange gehäuft. Microsoft ist aber nur teilweise Schuld, wie ich in einem anderen Fall feststellen musste.

Fehlerbild

Ein Anwender startet Outlook und wird mit folgender Fehlermeldung konfrontiert:

Der erfahrene Administrator sieht sofort, dass es sich vermutlich um ein Entra ID Anmeldefenster handelt, welches auf einen Fehler gelaufen ist.

Entra ID Logging

Den Fehler können Sie über die Entra ID SignIn analysieren.

Hinweis:
Ich habe die Anmeldefehler unter "User sign-ins (non-interactive) gefunden.

Die Meldung lautet auf:

"The resource principal named (name) was not found in the tenant named (tenant). This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant."

Der Hilfelink verweist auf:

Der Artikel beschreibt aber auch nicht mehr, als die Fehlermeldung liefert und bietet in Entra ID nach der Application zu suchen. Leider hat weder die Fehlermeldung auf dem Client noch im Entra SignIn-Log einen Hinweis darauf. welche Application oder welcher ServicePrincipal gesucht wird.

Microsoft Information Protection API

Mit der Nummer kann ich aber natürlich das Internet befragen und ich habe einige Treffer bekommt, die alle auf Probleme mit Outlook und Exchange Online ab ca. 7. Mai 2025 zusammenhängen. Angeblich hat "etwas" die Anmeldung von Benutzern an der Application "Microsoft Information Protection API" (GUID:40775b29-2688-46b6-a3b5-b256bd04df9f) blockiert und das müsste ein Administrator nur wieder einschalten.

Angeblich hat Microsoft diese Deaktivierung bis zum 15.Mai 2025 bei allen Kunden wieder rückgängig gemacht.

Exchange Hybrid Modern Auth

In meinem Fall war es aber etwas trickreicher, denn es ja ja schon Spätsommer 2025 und eigentlich wollten wir nur eine Exchange 2016 Umgebung auf Exchange SE aktualisieren. Wir haben einen neuen Exchange SE-Server in die Umgebung installiert und noch ehe wir die "Internal/External-URLs" entsprechend anpassen konnten, haben Anwender die oben abgebildete Meldung bekommen. Ich weiß natürlich um die Besonderheiten bei der Installation eines neuen Exchange Servers. Er hat erst einmal seinen FQDN als InternalURL/ExternalURL bei den virtuellen Verzeichnissen und im Service Connection Point hinterlegt. Wir haben auch gleich nach der Installation diese Werte angepasst aber waren dann wohl doch nicht schnell genug.

Die Fehlermeldung hat uns natürlich erst an eine Fehlkonfiguration in Entra ID glauben lassen aber es wurde dann doch schnell sichtbar, dass nur Outlook Clients betroffen waren, die noch Inhalte von den OnPremises-Servern abrufen wollten. Allerdings gibt es nur einen Fall, bei dem ein OnPremises-Server etwas mit OAUTH, SAML und Entra ID zu tun hat: Hybrid Modern Authentication (HMA) mit Exchange OnPremises.

Durch die Installation des neuen Exchange SE-Servers gab es nun für einige Minuten eine neue URL, die aber in der Entra ID-App noch nicht als Service Principal Name hinterlegt war. Wenn Sie Hybrid Modern Auth nutzen, dann können Sie mit folgenden Befehlen kontrollieren, welche lokale Servernamen in Entra ID hinterlegt sind:

Install-Module Microsoft.Graph -Scope AllUsers 
Connect-MgGraph -Scopes Application.Read.All, Application.ReadWrite.All 

Get-MgServicePrincipal `
   -Filter "AppId eq '00000002-0000-0ff1-ce00-000000000000'" `
| select -ExpandProperty ServicePrincipalNames

Bei Bedarf können Sie dann die Liste entsprechend erweitern:

$HMAApp = Get-MgServicePrincipal -Filter "AppId eq '00000002-0000-0ff1-ce00-000000000000'"
$HMAApp.ServicePrincipalNames += "https://ex01.msxfaq.de/"
$HMAApp.ServicePrincipalNames += "https://autodiscover.mxsfaq.de/"
Update-MgServicePrincipal `
   -ServicePrincipalId    $HMAApp.Id `
   -ServicePrincipalNames $HMAApp.ServicePrincipalNames

Das ist natürlich nicht erforderlich, wenn Sie auf die Server nicht mit ihrem FQDN zugreifen, sondern einem generischen Namen, der dann über einen Loadbalancer auf die verschiedenen lokalen Servern verteilt wird. Dazu ist es dann natürlich auch erforderlich, dass Sie die virtuellen Verzeichnisse des neuen Servers auf die gleichen virtuellen Namen setzen.

Interessant: Microsoft führt Hybrid Modern Auth in der "Whats new in Exchange SE"-Beschreibung auf

Modern authentication support for pure on-premises environments: Exchange Server SE supports OAuth 2.0 (aka Modern authentication) for pure on-premises environments using Active Directory Federation Services (ADFS) as a security token service (STS). 
Quelle: What's new in Exchange Server Subscription Edition (SE) | Microsoft Learn 
https://learn.microsoft.com/en-us/exchange/new-features/new-features#whats-new-when-upgrading-from-exchange-2016-to-exchange-se

Das ist aber schon mit aktuellen Versionen von Exchange 2016/2019 möglich gewesen

IRM, HMA und andere

Für den Fehler "4usqa" kann es natürlich noch jede Menge andere Gründe geben. Sie haben aber nach meiner Einschätzung immer etwas damit zu tun, dass ein Client auf einen lokalen Service zugreift, der dann den Client zu Entra ID umleitet. Dabei sendet der Client den ServicePrincipalName des angesprochenen Diensts mit zu Entra ID und der Authentifizierungsdienst in Entra ID muss in ihrem Tenant die passende Application finden, um ein SAML-Token auszustellen und ihren Client zurück zu verweisen.

Es könnte also sein, dass zukünftig auch noch andere Systeme solche Fehler generieren. Und zwar immer dann, wenn sie lokal weitere Server installieren oder zusätzliche ServicePrincipalNamen verwenden, die sie in der Definition der Enterprise Application in ihrem Entra ID Tenant noch nicht ergänzt haben.

Leider ist die Fehlermeldung im Entra ID Logging und die Anzeige auf dem Client überhaupt nicht hilfreich, denn sie zeigen weder den AppNamen noch den ServicePrincipalNamen an, so dass Sie als Administrator erst einmal fragend dastehen. Ich habe nur den Weg gefunden, auf dem Client die Zugriffe mit zu analysieren, z.B. indem ich die HTTP-Requests mittels Fiddler o.ä. mitschneide und dort den OAUTH-Request an EntraID samt dem SPN finde.

Weitere Links