Mir liegt der Bericht eines Blog-Lesers vor, der sporadische Probleme beim Zugriff auf Exchange Online-Postfächer aus Microsoft Outlook beklagt. Manches löst sich wie "Voodoo" von selbst auf, bei manchen Nutzern musste er manuell eingreifen. Ich stelle die Beobachtungen mal hier im Blog ein, vielleicht gibt es mehr Betroffene.
Anzeige
Eine Lesermeldung zum Problem
Blog-Leser Hans betreut bei seinem Unternehmen Nutzer mit Microsoft Outlook, deren Postfächer auf einem Exchange Online-Tenant liegen. Was ihn nervt, sind sporadische Zugriffsprobleme in Microsoft Outlook. Der Leser fragte vor einigen Tagen in einer E-Mail, ob ich in letzter Zeit auch von anderen Lesern Hinweise auf dieses (alte) Problem bekommen habe.
Das alte Problem ist vereinfacht mit "Es ist kein Zugriff von Outlook auf das Exchange Online Postfach möglich" umschrieben. Die Fehleranalyse erfolgte durch den Leser mit dem Microsoft Remote Connectivity Analyzer. Wenn das Problem auftritt, werden immer wieder folgende Fehler ausgegeben:
Outlook Connectivity
Testdetails:
Die Outlook-Verbindung wird getestet.
Fehler beim Test der Outlook-Verbindung.Testschritte
Die Microsoft-Verbindungsuntersuchung versucht, die AutoErmittlungsfunktion für abc@abc.de zu testen.
AutoErmittlung erfolgreich getestet.Testschritte
Die AutoErmittlungseinstellungen für die Outlook-Verbindung werden überprüft.Die Microsoft-Verbindungsuntersuchung hat die AutoErmittlungseinstellungen von Outlook überprüft.
Die MAPI-über-HTTP-Verbindung mit Server "outlook.office365.com" wird getestet.
Fehler bei der MAPI-über-HTTP-Verbindung.Testschritte
Es wird versucht, den Hostnamen outlook.office365.com im DNS aufzulösen.
Der Hostname wurde erfolgreich aufgelöst.Weitere Details
Es wird getestet, ob TCP-Port 443 auf Host outlook.office365.com überwacht wird/geöffnet ist.
Der Port wurde erfolgreich geöffnet.Die Gültigkeit des SSL-Zertifikats wird überprüft.
Das Zertifikat hat alle Überprüfungsanforderungen bestanden.Testschritte
HTTP-Authentifizierungsmethoden für URL https://outlook.office365.com/mapi/emsmdb/?MailboxId=abcdef@abc.de werden getestet
Die HTTP-Authentifizierungsmethoden sind richtig.Weitere Details
Der MAPI-Adressbuch-Endpunkt auf dem Exchange-Server wird getestet.
Fehler beim Test des Adressbuch-Endpunkts.Testschritte
Der Vorgang "Namen überprüfen" des Adressbuchs wird für Benutzer abc@abc.de anhand von Server "outlook.office365.com" getestet.
Beim Versuch, den Namen aufzulösen, ist ein Fehler aufgetreten.Weitere Details
Ausnahmedetails:
Nachricht: The request was aborted: The request was canceled.
Typ: System.Net.WebException
Stapelüberwachung:
at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at Microsoft.Exchange.MapiHttp.ClientAsyncOperation.<>c__DisplayClass58_0.b__0()
at Microsoft.Exchange.MapiHttp.ClientAsyncOperation.Execute(Action Action
Der Leser schrieb dazu: "Bei einem Postfach funktionierte der Zugriff am nächsten Tag, bei zwei anderen Postfächern hat das Verschieben einen Erfolg gebracht. Vielleicht hätte es am nächsten Tag auch wieder funktioniert, es musste aber vorher wieder funktionieren.
Der Zugriff über office.com funktionierte immer."
Sind ziemlich krude Fehler, vor allem, wenn es sporadisch auftritt. Ist das von weiteren Lesern beobachtet worden? Gibt es eine Erklärung für den sporadischen Fehler bei der Namensauflösung oder gar Abhilfe?
Anzeige
Anzeige
kann ich leider bestätigen.
Bei golem war zu lesen, dass ein großes Botnetz verteilte Angriffe auf Microsoft-Konten fährt. Könnte es sein, dass Microsoft irgendwelche Gegenmaßnahmen ergreift, die sich für Teile der Konten in solchen sporadischen und temporären Aussetzern äußern?
Den Fall hatte ich gestern auch, welchen ich mir nicht erklären konnte.
Ein Kollege hatte Probleme beim Erstellen von Terminen und Outlook war recht träge.
Ich wollte dann das Mail Profil neu machen, aber das schlug permanent fehlt und ich konnte explizit sein Profil nicht mehr einrichten. Der Zugang über den Outlook Web ging problemlos aber Das Konto konnte ich nicht mehr einrichtet. Habe dann testweise mal mein Profil gelöscht und das konnte ich sofort wieder einbinden und Outlook nutzen.
Heute kam der Kollege wieder mit seinem Laptop an und das Outlook Profil lies sich ohne weiteres einrichten und funktionierte sofort.
Auch wir haben weiterhin vereinzelt Probleme. Diese scheinen aber eher auf SMBs zuzutreffen. Wenn einzelne Nutzer bestimmte SMBs eingebunden haben, öffnet sich Outlook nur sehr zäh und arbeitet dann extrem langsam bzw. gar nicht. Bei manchen Usern hängt Outlook dann auch im Offline Mode fest. Entfernt man die SMB wieder, läuft es einwandfrei. Gestern hatte ich einen User, bei welchem dann gar nichts mehr ging: Es war mir weder möglich die SMB per Systemsteuerung zu entfernen, noch ein neues Outlook-Profil anzulegen, weil sich die Systemsteuerung beim Öffnen der Menüs jedes Mal aufhängte.
Komischerweise verschwinden die Probleme dann plötzlich wieder und treten bei anderen neu auf. Aktuell ist es wirklich sehr frustrierend, da es keinen richtigen Lösungsansatz gibt.
Über OWA funktioniert der Zugriff auf die SMBs permanent ohne Probleme.
SMBs sind shared mailboxes?
Ja genau
Wir haben bei einzelnen Benutzern bei diversen Kunden ein ähnliches Verhalten festgestellt.
– Outlook öffnet sich nicht mehr mit Meldung "Diese Ordnergruppe kann nicht geöffnet werden…."
– Outlook öffnet sich nach 10-15 Minuten warten (Das Profil wird geladen) und ist extrem langsam
– Manchmal hilft es ein neues Profil einrichten
– Outlook Web / office.com funktioniert ohne Probleme
– Das Problem tritt wie "Anonym" geschrieben hat, eher bei Postfächern auf, welche mehrere andere Shared Mailboxen eingebunden haben
Der Microsoft Support sagt, es gibt von vor zwei Wochen einen erledigten Incident und wir sollen 24 Stunden warten
das problem hatte ich auch. was bei mir geholfen hat, war die outlook-ordner unter appdata zu löschen (local und roaming). hab dann sicherheitshalber auch ein neues Outlook-Profil gestartet. dann lief alles wieder.
Der Exchange-Cache-Modus könnte dir da weiterhelfen.
Ich bin der, der Herrn Born das Problem zugeschickt hat. Meine Frage ist diesbezüglich, ob es wirklich nur zu lösen ist, indem ich das Postfach verschiebe, oder warte, bis sich das Problem wieder von "alleine" gelöst hat.
Wobei das Verschieben anscheinend nur noch durch MS erfolgen sollte:
Note: After April 15, 2020, you shouldn't use this cmdlet to manually move mailboxes within an Exchange Online organization. You can only use this cmdlet for migrating to and from Exchange Online.
If you have issues with a mailbox and want to fix it by moving the mailbox within your Exchange Online organization, please open a Microsoft Support request instead.
Ich habe das trotzdem über die Exchange Online PS gemacht, und es funktioniert auch soweit.
Hat jemand noch eine andere Lösung gefunden?
Hier https://www.borncity.com/blog/2025/02/07/derzeit-massive-outlook-exchange-online-probleme-feb-2025/ ging es wahrscheinlich größtenteils um das gleiche Problem.
Habe das Problem jetzt auch schon mehrfach mit Microsoft 365 Mailkonten gehabt. Fehlermeldung ist eigentlich immer, nach ewig langem warten beim Start von Outlook, dass der Informationsspeicher zur Zeit nicht zur Verfügung stünde. Gemeinsam hatten die Konten immer, dass diese den Cache Modus nicht verwenden. Ein neues Outlook Profil anlegen scheiterte dann meistens auch. Am nächsten Tag, in einem Fall sogar am gleichen Abend, klappte der Zugriff wieder problemlos. Jedes andere Mailkonto vom gleichen Tenant im gleichen Netz (sogar vom gleichen Server, da TS) funktionierte immer problemlos. Auch der Zugriff über das Webinterface auf die Mailadresse war Problemlos möglich. Bei einem Account war auch der parallel auf dem Mobiltelefon eingerichtete Zugriff immer möglich.
Einer der wenigen Sachen die seit Jahren stabil laufen.
Tennent 6000 Lizenzen
Wurde heute auch mit diesem Problem bei einem Kunden konfrontiert. Kleine Umgebung mit 10 lizenzierten EXO Postfächern und ein paar shared mailboxen.
Ein User war betroffen, dass das Outlook nicht mehr starten konnte. Ich wollte schnell ein neues Profil einrichten und das hat selbst gar nicht funktioniert. Bei der Profilerzeugung hat sich der ganze Prozess aufgehangen.
Neuinstallation Outlook, Bereinigung Registry und so weiter hat alles nicht geholfen.
Dann bin ich hierauf gestoßen und wollte gucken, ob ich dem User seine SMB entziehen kann und es dann läuft, aber inzwischen hatte sich dann ein Outlook Profil erzeugt, welches man auch starten konnte.
Das Outlook ist langsam aber bedienbar.
Die shared mailboxen hingegen kann man nicht ansteuern, obwohl sie im Outlook angezeigt werden.
Der betroffene User arbeitet erstmal über das OWA.
Im Admincenter unter den Incidents wird mir jedoch keine Störung in dem Bereich bzw. der Beschreibung angezeigt.
Klingt genau nach dem gleichen Problem, was ich bei einem User bei mir seit gestern habe
Wir haben genau die gleichen Probleme, angefangen haben die Probleme seit ca. Anfang Februar. Haben 500+ Tenant mit ca. insgesamt 4000 Postfächern, pro Tag 2-5 Postfächer mit dem Problem, nächsten Tag ist das Problem im Regelfall wieder behoben.
Bisher haben wir auch keine Lösung gefunden, Microsoft Support gibt nur Standard Antworten.
Interessant ist auch, dass die Überprüfung der Outlook-Verbindung im "Microsoft Remote Connectivity Analyzer" (https://testconnectivity.microsoft.com/tests/O365Ola/input) immer sehr lange dauert. Es fühlt sich so an, als ob die Abfrage am Ende in einen Timeout läuft. Sind die Systeme, auf dem das Postfach liegt, einfach überlastet?
Moin
Das Problem kenne ich zu gut, lustig wird's immer, wenn der Zugriff über Web/Smartphone App oder Outlook NEW läuft, aber mal wieder nicht über Outlook Classic.
Da half auch kein Neustart oder neues Outlook Profil mit E-Mail/Useranmeldung und MFA.
Was mir aber öfters geholfen hat, war einfach im Userordner den AAD-Identitätsordner aufzuräumen.
Im Ordner
c:\users\username\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Settings\
c:\users\username\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\TokenBroker\Account
einfach die Settings.dat löschen oder den kompletten Ordner leeren und das ohne Neustart auf einem RDS/Terminal Server.
Hat mir gerade eben mal wieder geholfen, mein Verdacht ist, dass mit dem gesetzten Token was nicht stimmt oder der alte nicht korrekt ersetzt wird.
Hallo Adrian,
gerade einen neuen Fall reinbekommen:
Bei der Userin gab es nur unter: \users\username\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_xyc\Settings\
eine Settings.dat. Das Löschen hat in meinem Fall keine Besserung gebracht.
Noch was lustiges: zur Zeit werden mir im "Exchange Admin Center" unter Postfächer nur 40 angezeigt. Filter sind alle gelöscht. Das Problem-Postfach ist nicht darunter. Wenn ich es suche, wird es aber gefunden. Mh…
Wir hatten exakt das gleiche Problem. Einer User konnte sich selbst auf einem frischen PC nicht an Outlook classic anmelden. OWA ging. Der Microsoft Remote Connectivity Analyzer gab den gleichen MAPI Adress Book Fehler aus, wie oben im Post. Haben das Postfach einmal nach On-Prem und wieder zurück nach EXO verschoben. Ob es das geholfen hat oder die 2-3 Tage die dazwischen lagen, weiß ich nicht. Wir haben keine Anpassen an SMB Berechtigungen gemacht.
Seit gestern wieder ein neuer Fall..