Exchange Online/ Outlook 365 in Terminal Server Farm Abbrüche

[Candy 27]

Hallo Community,

 

ich hoffe ich schreibe das hier im richtigen Abschnitt. :)
Optisch hat sich hier wirklich viel verändert. Sieht sehr gut aus!
Ich muss in Zukunft mal wieder regelmäßig hier vorbei schauen. :)

 

Folgende Ausgangslage:

1. Neue Microsoft Domain aufgesetzt
2. Neue Microsoft Terminal Server Farm mit Hilfe von Microsoft Server 2019 aufgesetzt, als Benutzer Profilspeicher FS Logix im Einsatz.
3. Alle Windows RD Benutzer besitzen eine Microsoft 365 Business Premium Lizenz(gesamt 51stk).
4. Microsoft 365 Anwendungen wurden auf allen Windows Terminal Servern 2019 mit Hilfe des Microsoft Deployment Tool vorschriftsmäßig installiert. Die Lizenz ist auf allen Terminal Servern als „Mehrbenutzer fähige Lizenz“ hinterlegt u. registriert
5. Beim ersten Start von Outlook 365 im Benutzer Kontext kommt ordentlich die Microsoft Benutzeranmeldung und das Postfach wird ohne Outlook Cache Mode dargestellt.

 

Technisches Problem:

Aus für uns noch unerklärlichen Gründen, bricht Microsoft Outlook 365, sporadisch bei unterschiedlichen Benutzern, täglich die Verbindung ab.
Fehlermeldung:
„Outlook kann nicht gestartet werden. Das Outlook Fenster kann nicht geöffnet werden. Diese Ordnergruppe kann nicht geöffnet werden. Der Informationsspeicher steht nicht zur Verfügung.“

 

Was haben wir zur Behebung versucht?

Wir haben danach keinerlei Möglichkeit mehr, die Microsoft 365 Benutzer Anmeldung nochmals durchzuführen. Wir bekommen den Benutzer, den es betrifft, auf keiner uns technisch bekannten Weise wieder bei M365 angemeldet. Fehlermeldung bei Outlook 365 " Da hat etwas nicht geklappt"

Auch das Löschen vom Outlook Profil mit wiederholten anlegen eines neuen Outlook Profils bringt die gleiche Fehlermeldung.
Wir müssen das gesamte Microsoft Benutzerprofil löschen und wieder neu anlegen. Das funktioniert wenige Tage und wir stehen vor dem gleichen Problem.

An allen Standorten haben wir sehr gute Internetanbindungen( 1GB/s up, wie down). Die gesamte DNS, Autodiscover usw. Konfigurationen sind alle grün und zeigen von Microsoft keinerlei Fehler an(online Test durchgeführt). Auch der lokale DNS Server löst alles ordnungsgemäß auf.

Das Problem tritt bei den Benutzer nur auf der Terminal Server Farm auf. Nicht lokal in der Outlook 365 Installation.

 

Die Migration vom on premise Microsoft Exchange Server wurde aus "politischen Gründen" komplett händisch u. mit Hilfe von Mail Store umgesetzt.

 

Kennt vielleicht jemand diesen Fehler?
Vielleicht Fehlerhafte Lizenz Abfragen von Microsoft?

 

Vielen Dank für eure Unterstützung!

 

[testperson 1.677]

Hi,

 

wieso ohne Cache Mode? Ich würde mit Exchange online definitiv cachen lassen und den Cache irgendwo - je nach Akzeptanz der User - auf einen Monat bis ein Jahr festlegen.

 

Eine eher kosmetische Frage wäre, warum kein SSOn für die User?

 

Gruß

Jan

[mwiederkehr 373]

Das sieht exakt nach dem Problem aus, mit dem ich diese Woche zu tun hatte: Server 2019, Office 365, bei gewissen Benutzern öffnet sich Outlook nicht mehr, "E-Mail-Autokonfiguration testen..." liefert unendlich viele Fehler 401, Teams geht nicht mehr. In Word und Excel ist die Lizenz aber noch aktiviert und OWA geht auch. In der Ereignisanzeige hatte es die Events 1097 und 1098 vom AAD.

 

Wenn ich es richtig verstanden habe, ist das Problem das Token des Benutzers. Modern Authentication basiert auf Azure Active Directory Authentication Library (ADAL). In neueren Versionen verwenden die Anwendungen den Web Account Manager (WAM) für die Verwaltung der Tokens. Das ist die App, die man im Profil unter Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy findet. Löscht man dieses Verzeichnis (der Benutzer darf dabei nicht angemeldet sein), funktioniert die Anmeldung wieder. Das Problem tritt nur in RDS-Farmen auf, wo die Benutzer nicht immer auf dem gleichen Server arbeiten. Das Token wandert mit dem Benutzer mit, ist aber vom Server abhängig. Deshalb kann es nicht gelesen (genauer gesagt entschlüsselt) werden. Anstatt eine Anmeldung anzuzeigen, stellt Outlook einfach keine Verbindung her.

 

In meinem Fall hat es geholfen, per Registry die bisherige Token-Verwaltung zu aktivieren:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity]
"EnableADAL"=dword:00000001
"DisableAADWAM"=dword:00000001
"DisableADALatopWAMOverride"=dword:00000001

 

Benutzer neu anmelden, funktioniert.

 

Man findet viel im Internet darüber, aber ich habe nirgends eine Erklärung der genauen Ursache gefunden. Das ist ja von Anfang bis Ende Software von Microsoft und ein unterstütztes Szenario, das sollte nicht "mal eben" nicht mehr gehen und Microsoft sagt nichts dazu. Falls jemand mehr Informationen hat, bin ich sehr interessiert.

[Candy 27]

vor einer Stunde schrieb mwiederkehr:

Das ist die App, die man im Profil unter Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy findet. Löscht man dieses Verzeichnis (der Benutzer darf dabei nicht angemeldet sein), funktioniert die Anmeldung wieder. 

Hallo mwiederkehr. Danke für deine Antwort! Was meinst du mit dem oberen Satz? Das Verzeichnis konnte ich so nicht finden.

vor einer Stunde schrieb mwiederkehr:

 

In meinem Fall hat es geholfen, per Registry die bisherige Token-Verwaltung zu aktivieren:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity]
"EnableADAL"=dword:00000001
"DisableAADWAM"=dword:00000001
"DisableADALatopWAMOverride"=dword:00000001

 

 

Diese Einträge habe ich gesetzt u. getestet. Nehme ich danach einen betroffenen Benutzer, kann ich diesen leider immer noch nicht anmelden.

[mwiederkehr 373]

Das Verzeichnis befindet sich im Benutzerprofil unter „\AppData\Local\Packages“.

 

Du hast die Registry-Keys schon unter dem entsprechenden Benutzerkonto gesetzt?

 

Bei mir hat das Setzen der Keys gereicht, ich musste danach das Verzeichnis nicht löschen.

[Candy 27]

vor 23 Minuten schrieb Candy:

Hallo mwiederkehr. Danke für deine Antwort! Was meinst du mit dem oberen Satz? Das Verzeichnis konnte ich so nicht finden.

Diese Einträge habe ich gesetzt u. getestet. Nehme ich danach einen betroffenen Benutzer, kann ich diesen leider immer noch nicht anmelden.

 

P.S. Ich habe nun einen betroffenen Benutzer, der kein Outlook mehr nutzen konnte, in WORD bei M365 abgemeldet. Danach wieder erfolgreich angemeldet und Outlook konnte auch wieder gestartet werden.

vor 5 Minuten schrieb mwiederkehr:

Das Verzeichnis befindet sich im Benutzerprofil unter „\AppData\Local\Packages“.

 

Du hast die Registry-Keys schon unter dem entsprechenden Benutzerkonto gesetzt?

 

Bei mir hat das Setzen der Keys gereicht, ich musste danach das Verzeichnis nicht löschen.

 

Gefunden, wird Zeit für Feierabend! Ich Danke dir für die Hilfe. Somit haben wir erst einmal eine Option um zu reagieren, ohne das gesamte Profil neu zu erstellen.

bearbeitet 2. Dezember 2022 von Candy

[testperson 1.677]

Hi,

 

siehe: Disabling ADAL or WAM to fix Office sign-in or activation issues not recommended - Office 365 | Microsoft Learn

Zitat

Disabling ADAL or WAM authentication as a solution to fix sign-in or activation issues can have adverse effects in your environment and is not recommended.

 

Sind die RDSHs Azure AD joined?

 

Gruß

Jan

[Candy 27]

Hallo Jan,

 

nein, sind sie nicht.

[testperson 1.677]

Dann wäre der AAD join noch ein Ansatz.

[mwiederkehr 373]

Was wäre der Vorteil eines AAD Join? Kann der Server gleichzeitig in einer "legacy" und einer Azure-Domain sein, wenn diese nicht synchronisiert werden (kein AAD Connect)?

 

Im verlinkten Artikel wird unser Problem leider nicht behandelt. Es äussert sich in folgenden Fehlern:

 

AAD, Event 1097:

Error: 0x80090011 Das Objekt wurde nicht gefunden.

Das Objekt wurde nicht gefunden.

Exception of type 'class WinRTException' at oauthtokenrequestbase.cpp, line: 733, method: OAuthTokenRequestBase::QueryTokenBindingKeyId::<lambda_384ba4be0f1ddecb55f87844038ccea6>::operator ().

Log: 0x8aa5007f Unable to create a Token Binding Key.
Logged at oauthtokenrequestbase.cpp, line: 733, method: OAuthTokenRequestBase::QueryTokenBindingKeyId::<lambda_384ba4be0f1ddecb55f87844038ccea6>::operator ().

Request: authority: https://login.microsoftonline.com/common, client: d3590ed7-52b2-4103-aeff-aad2292ab01c, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed7-52b2-4103-aeff-aad2292ab01c, resource: https://outlook.office365.com/, correlation ID (request): dbbb91f4-5d17-447e-85ed-16deceeeea2a

Error: 0x8AA9004C Acquire token by refresh token failed, trying PRT.
Logged at refreshtokenrequest.cpp, line: 79, method: RefreshTokenRequest::AcquireToken.

Request: authority: https://login.microsoftonline.com/common, client: d3590ed7-52b2-4103-aeff-aad2292ab01c, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed7-52b2-4103-aeff-aad2292ab01c, resource: https://outlook.office365.com/, correlation ID (request): dbbb91f4-5d17-447e-85ed-16deceeeea2a

 

AAD, Event 1098:

Error: 0x80070003 Das System kann den angegebenen Pfad nicht finden.

Das System kann den angegebenen Pfad nicht finden.

Exception of type 'class WinRTException' at webaccountprocessor.cpp, line: 280, method: AAD::Core::WebAccountProcessor::ProcessBrokerBackgroundRequest::<lambda_c59055bd9d9c85aff79a2f7420694224>::operator ().

Log: 0xcaa5001c Token broker operation failed.
Operation name: GetTokenSilently
Logged at webaccountprocessor.cpp, line: 545, method: AAD::Core::WebAccountProcessor::ReportException.

Error: 0x80070003 Das System kann den angegebenen Pfad nicht finden.
Exception of type 'class NGCException' at ngchelper.cpp, line: 42, method: NgcHelper::SignWithSymmetricPopKey.

Log: 0xcaa10083 Exception in WinRT wrapper.
Logged at authorizationclient.cpp, line: 224, method: ADALRT::AuthorizationClient::AcquireToken.

Request: authority: https://login.microsoftonline.com/common, client: d3590ed6-52b3-4102-aeff-aad2292ab01c, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c

Error: 0x80070003 Das System kann den angegebenen Pfad nicht finden.
Exception of type 'class NGCException' at ngchelper.cpp, line: 42, method: NgcHelper::SignWithSymmetricPopKey.

Log: 0xcaa1007b Acquire token failed.
Logged at authenticationcontext.cpp, line: 404, method: AuthenticationContext::AcquireTokenInternal.

Request: authority: https://login.microsoftonline.com/common, client: d3590ed7-52b2-4103-aeff-aad2292ab01c, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c

Error: 0x80070003 Das System kann den angegebenen Pfad nicht finden.
Exception of type 'class NGCException' at ngchelper.cpp, line: 42, method: NgcHelper::SignWithSymmetricPopKey.

Log: 0xcaa1007b Acquire token failed.
Logged at aggregatedtokenrequest.cpp, line: 69, method: AggregatedTokenRequest::AcquireToken.

Request: authority: https://login.microsoftonline.com/common, client: d3590ed7-52b2-4103-aeff-aad2292ab01c, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed7-52b2-4103-aeff-aad2292ab01c, resource: https://outlook.office365.com/, correlation ID (request): dbbb91f4-5d17-447e-85ed-16deceeeea2a

 

Falls Du mehr weisst, bin ich dankbar für einen Tipp, da ja anscheinend die Deaktivierung von WAM nicht der Weisheit letzter Schluss ist.

[Candy 27]

vor 18 Minuten schrieb mwiederkehr:

Was wäre der Vorteil eines AAD Join? Kann der Server gleichzeitig in einer "legacy" und einer Azure-Domain sein, wenn diese nicht synchronisiert werden (kein AAD Connect)?

 

Im verlinkten Artikel wird unser Problem leider nicht behandelt. Es äussert sich in folgenden Fehlern:

 

AAD, Event 1097:

Error: 0x80090011 Das Objekt wurde nicht gefunden.

Das Objekt wurde nicht gefunden.

Exception of type 'class WinRTException' at oauthtokenrequestbase.cpp, line: 733, method: OAuthTokenRequestBase::QueryTokenBindingKeyId::<lambda_384ba4be0f1ddecb55f87844038ccea6>::operator ().

Log: 0x8aa5007f Unable to create a Token Binding Key.
Logged at oauthtokenrequestbase.cpp, line: 733, method: OAuthTokenRequestBase::QueryTokenBindingKeyId::<lambda_384ba4be0f1ddecb55f87844038ccea6>::operator ().

Request: authority: https://login.microsoftonline.com/common, client: d3590ed7-52b2-4103-aeff-aad2292ab01c, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed7-52b2-4103-aeff-aad2292ab01c, resource: https://outlook.office365.com/, correlation ID (request): dbbb91f4-5d17-447e-85ed-16deceeeea2a

Error: 0x8AA9004C Acquire token by refresh token failed, trying PRT.
Logged at refreshtokenrequest.cpp, line: 79, method: RefreshTokenRequest::AcquireToken.

Request: authority: https://login.microsoftonline.com/common, client: d3590ed7-52b2-4103-aeff-aad2292ab01c, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed7-52b2-4103-aeff-aad2292ab01c, resource: https://outlook.office365.com/, correlation ID (request): dbbb91f4-5d17-447e-85ed-16deceeeea2a

 

AAD, Event 1098:

Error: 0x80070003 Das System kann den angegebenen Pfad nicht finden.

Das System kann den angegebenen Pfad nicht finden.

Exception of type 'class WinRTException' at webaccountprocessor.cpp, line: 280, method: AAD::Core::WebAccountProcessor::ProcessBrokerBackgroundRequest::<lambda_c59055bd9d9c85aff79a2f7420694224>::operator ().

Log: 0xcaa5001c Token broker operation failed.
Operation name: GetTokenSilently
Logged at webaccountprocessor.cpp, line: 545, method: AAD::Core::WebAccountProcessor::ReportException.

Error: 0x80070003 Das System kann den angegebenen Pfad nicht finden.
Exception of type 'class NGCException' at ngchelper.cpp, line: 42, method: NgcHelper::SignWithSymmetricPopKey.

Log: 0xcaa10083 Exception in WinRT wrapper.
Logged at authorizationclient.cpp, line: 224, method: ADALRT::AuthorizationClient::AcquireToken.

Request: authority: https://login.microsoftonline.com/common, client: d3590ed6-52b3-4102-aeff-aad2292ab01c, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c

Error: 0x80070003 Das System kann den angegebenen Pfad nicht finden.
Exception of type 'class NGCException' at ngchelper.cpp, line: 42, method: NgcHelper::SignWithSymmetricPopKey.

Log: 0xcaa1007b Acquire token failed.
Logged at authenticationcontext.cpp, line: 404, method: AuthenticationContext::AcquireTokenInternal.

Request: authority: https://login.microsoftonline.com/common, client: d3590ed7-52b2-4103-aeff-aad2292ab01c, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c

Error: 0x80070003 Das System kann den angegebenen Pfad nicht finden.
Exception of type 'class NGCException' at ngchelper.cpp, line: 42, method: NgcHelper::SignWithSymmetricPopKey.

Log: 0xcaa1007b Acquire token failed.
Logged at aggregatedtokenrequest.cpp, line: 69, method: AggregatedTokenRequest::AcquireToken.

Request: authority: https://login.microsoftonline.com/common, client: d3590ed7-52b2-4103-aeff-aad2292ab01c, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed7-52b2-4103-aeff-aad2292ab01c, resource: https://outlook.office365.com/, correlation ID (request): dbbb91f4-5d17-447e-85ed-16deceeeea2a

 

Falls Du mehr weisst, bin ich dankbar für einen Tipp, da ja anscheinend die Deaktivierung von WAM nicht der Weisheit letzter Schluss ist.

Moin,

 

ich hatte parallel ein Support Ticket bei Microsoft eröffnet. Dort habe ich diesen Link zur Umsetzung erhalten.
Für mich auf dem ersten Blick, aber auch der falsche Ansatz, da wir nicht mit diesen Office Versionen arbeiten, sondern mit Microsoft 365.
Mit den Vorschlag von Microsoft bin ich auch nicht ganz glücklich/ unsicher und habe es noch nicht umgesetzt.

 

How modern authentication works for Office 2013 and Office 2016 client apps - Microsoft 365 Enterprise | Microsoft Learn

 

 

bearbeitet 5. Dezember 2022 von Candy

[ollivetti41 0]

Hallo gibt es hierzu eine offizielle von Microsoft unterstützte Lösung? Das Deaktivieren von WAM ist ja nicht wirklich supported.

Schöne Grüße

[ollivetti41 0]

Hallo gibt es hierzu eine offizielle von Microsoft unterstützte Lösung? Das Deaktivieren von WAM ist ja nicht wirklich supported.

Schöne Grüße

[testperson 1.677]

Moin,

 

ich würde die User mit AAD Connect und auch die Devices per Hybrid AAD Join syncen. Damit fahren wir bei unseren Kunden (gefühlt) am besten. Wenn die Devices auch im AAD sind, bekommt man AFAIK das Anmeldetoken bereits bei der Anmeldung des User am Device und nicht erst beim Start der Anwendung.

 

Ansonsten ein Ticket aufmachen und solange "nerven" bis man eine Lösung hat. ;)

 

Gruß

Jan

[ollivetti41 0]

Danke Jan.

Also unsere Server sind  AzureAdJoined : YES und DomainJoined: YES, dennoch haben wir das Problem, dass nach jeder Anmeldung beim Start von Outlook das PW abgefragt wird. Erst seit Server 2019 und Office 2019. 

 

Grüße