18
Outlook verliert Verbindung
Moin moin zusammen,
bei einigen Exchange Servern der Reihe 2016 und 2019 tritt in Verbindung mit Outlook 2016 und 2019, welche im Online Modus (nicht im Cache-Modus) arbeiten das Problem auf, das sich Outlook immer wieder trennt. Es erscheint dann die Meldung, Outlook versucht eine Verbindung zum Exchange Server xyz.de aufzubauen. Kurz darauf ist es wieder verbunden. ein oder auch zwei Stunden, manchmal aber auch ein paar Minuten später das gleiche.
Es tritt bei völlig unterschiedlichen Domänen, Netzwerken und Internetanschlüssen vermehrt seit dem 27.02.2023 abends auf.
Hat jemand von euch auch schon so etwas beobachtet?
Gruß HeinrichM
bei einigen Exchange Servern der Reihe 2016 und 2019 tritt in Verbindung mit Outlook 2016 und 2019, welche im Online Modus (nicht im Cache-Modus) arbeiten das Problem auf, das sich Outlook immer wieder trennt. Es erscheint dann die Meldung, Outlook versucht eine Verbindung zum Exchange Server xyz.de aufzubauen. Kurz darauf ist es wieder verbunden. ein oder auch zwei Stunden, manchmal aber auch ein paar Minuten später das gleiche.
Es tritt bei völlig unterschiedlichen Domänen, Netzwerken und Internetanschlüssen vermehrt seit dem 27.02.2023 abends auf.
Hat jemand von euch auch schon so etwas beobachtet?
Gruß HeinrichM
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 6165305899
Url: https://administrator.de/contentid/6165305899
Printed on: April 28, 2024 at 17:04 o'clock
18 Comments
Latest comment
Das kann "alles" sein. Broadcast Sturm, schlechter Switch oder Port, Treiber, Kabel... Du musst eines nach dem anderen prüfen.
Ja muss mir das mal genauer ansehen. Ist halt nur auffällig, dass es in verschiedenen Netzten zum gleichen Zeitpunkt auftritt.
Das ist es nicht auf der Benutzerseite zu suchen sondern in den zentralen Funktionen bzw in der zentralen Architektur ;)
Zitat von @NordicMike:
Das ist es nicht auf der Benutzerseite zu suchen sondern in den zentralen Funktionen bzw in der zentralen Architektur ;)
Das ist es nicht auf der Benutzerseite zu suchen sondern in den zentralen Funktionen bzw in der zentralen Architektur ;)
🤔
Also Netzwerkverbindung Richtung Exchange Server, Router, interne DNS und externe DNS Einstellungen, die für Autodiscover wichtig sind... Zugriff bis zum DC.
ja die internen dinge sind, so meine Meinung, alle in Ordnung. Funktioniert ja auch schon seit Jahren ohne Probleme, wenn wir mal von den Updates absehen, die dann schon ab und zu mal ein nachjustieren verlange. Aber in Grunde sitzen die Einstellungen und auch die Hardware ist auf einem aktuellen Stand. Eben so sind alle Systeme immer auf dem neusten Stand.
Ich kann mir auch nicht vorstellen, dass an verschiedenen nicht mit einander verbundenen (außer Internet, kein VPN) Orten gleichzeitig alle Router, Switche oder gar Kabel einen weg haben. Ebenso wurde auch intern und extern nichts am DNS verändert.
Habe hier einen Anhaltspunkt gefunden, der in die Richtung zeigt.
https://www.frankysweb.de/outlook-autodiscover-fuer-office-365-deaktivie ...]
Muss es mal beobachten, ob es jetzt besser wird.
Ich kann mir auch nicht vorstellen, dass an verschiedenen nicht mit einander verbundenen (außer Internet, kein VPN) Orten gleichzeitig alle Router, Switche oder gar Kabel einen weg haben. Ebenso wurde auch intern und extern nichts am DNS verändert.
Habe hier einen Anhaltspunkt gefunden, der in die Richtung zeigt.
https://www.frankysweb.de/outlook-autodiscover-fuer-office-365-deaktivie ...]
Muss es mal beobachten, ob es jetzt besser wird.
gleichzeitig alle Router, Switche oder gar Kabel einen weg haben
Warum gleichzeitig? Es reicht, wenn ein Kabel alleine spinnt.Hast du schon auf einen Broadcast Sturm geprüft?
Falsche Autodiscover Einstellungen führen dazu, dass Outlook bei der Einrichtung Probleme macht oder nach der Einrichtung 1x seine Einstellungen verliert und sich nicht mehr von selbst wieder verbindet. Also sollte der Link nicht wirklich helfen. Weil es ja nach der Vindungsverlust irgendwann wieder funktioniert.
Das Problem tritt an verschiedenen Orten und Netzwerken auf, die nicht mir einander verbunden sind und auch nichts mit einander zu tun haben. Daher kann es nicht an einem Kabel liegen.
Also verschiedene Exchange Server, verschiedene Netzwerke, verschiedene Clients. Dann wirds schwierig 
so ist es... 😒
Gibt es irgendwo gemeinsame Nenner?
Microsoft Server 2016 Standard, Exchange Server 2016 und 2019 und Outlook in den Versionen 2016 und 2019
Mehr leider nicht wirklich.
Was mir aufgefallen ist, ist dass im Pfand:
C:\Users\Michael Schaal\AppData\Local\Microsoft\Outlook
bei einigen die .xml Datei fehlt.
Mehr leider nicht wirklich.
Was mir aufgefallen ist, ist dass im Pfand:
C:\Users\Michael Schaal\AppData\Local\Microsoft\Outlook
bei einigen die .xml Datei fehlt.
Die *-Autodiscover.xml?
Mach mal über die Outlook GUI den Autodiscover Test.
https://www.msxfaq.de/exchange/autodiscover/autodiscover_testen.htm
zweiter Punkt
Mach mal über die Outlook GUI den Autodiscover Test.
https://www.msxfaq.de/exchange/autodiscover/autodiscover_testen.htm
zweiter Punkt
Ja den Test habe ich auch schon gemacht, keine Auffälligkeiten.
immer wenn die Verbindung (aktuell für ca. 10-15 Sec.) verloren geht, bekomme ich in der Ereignisanzeige mehrere Fehler:
1. unter Anwendung:
Watson report about to be sent for process id: 39516, with parameters: E12IIS, c-RTL-AMD64, 15.02.1118.021, w3wp#MSExchangeServicesAppPool, M.Exchange.Services, M.E.S.C.T.ServiceResult`1.ProcessServiceResults, System.ArgumentNullException, feb4-dumptidset, 15.02.1118.021.
ErrorReportingEnabled: False
2. unter System
Schwerwiegender Kommunikationsfehler im Windows-Prozessaktivierungsdienst bei einem Prozess für den Anwendungspool "MSExchangeMapiMailboxAppPool". Die Prozess-ID ist "33512". Das Datenfeld enthält die Fehlernummer.
und
Schwerwiegender Kommunikationsfehler im Windows-Prozessaktivierungsdienst bei einem Prozess für den Anwendungspool "MSExchangeMapiMailboxAppPool". Die Prozess-ID ist "24164". Das Datenfeld enthält die Fehlernummer.
MS hatte diese Woche die Ausschlüsse für Dateipfade für den Virenscanner angepasst. Dies hatten wir auch so umgesetzt.
Ausschlüsse beim Virenschutz auf Exchange Servern
Sehr verdächtig. Ich mache die Ausschlüsse mal wieder rückgängig.
1. unter Anwendung:
Watson report about to be sent for process id: 39516, with parameters: E12IIS, c-RTL-AMD64, 15.02.1118.021, w3wp#MSExchangeServicesAppPool, M.Exchange.Services, M.E.S.C.T.ServiceResult`1.ProcessServiceResults, System.ArgumentNullException, feb4-dumptidset, 15.02.1118.021.
ErrorReportingEnabled: False
2. unter System
Schwerwiegender Kommunikationsfehler im Windows-Prozessaktivierungsdienst bei einem Prozess für den Anwendungspool "MSExchangeMapiMailboxAppPool". Die Prozess-ID ist "33512". Das Datenfeld enthält die Fehlernummer.
und
Schwerwiegender Kommunikationsfehler im Windows-Prozessaktivierungsdienst bei einem Prozess für den Anwendungspool "MSExchangeMapiMailboxAppPool". Die Prozess-ID ist "24164". Das Datenfeld enthält die Fehlernummer.
MS hatte diese Woche die Ausschlüsse für Dateipfade für den Virenscanner angepasst. Dies hatten wir auch so umgesetzt.
Ausschlüsse beim Virenschutz auf Exchange Servern
Sehr verdächtig. Ich mache die Ausschlüsse mal wieder rückgängig.
Kleine Rückmeldung an dieser Stelle:
Das Problem ist behoben.
Nach dem entgegen der Empfehlung von MS nun wieder die Ausschlüsse eingetragen wurden laufen alle Server wieder Stabil und die Outlooks machen keine Probleme mehr.
Hier noch einmal die Dateien:
%SystemRoot%\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files
%SystemRoot%\System32\Inetsrv
%SystemRoot%\System32\WindowsPowerShell\v1.0\PowerShell.exe
%SystemRoot%\System32\inetsrv\w3wp.exe
Das Problem ist behoben.
Nach dem entgegen der Empfehlung von MS nun wieder die Ausschlüsse eingetragen wurden laufen alle Server wieder Stabil und die Outlooks machen keine Probleme mehr.
Hier noch einmal die Dateien:
%SystemRoot%\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files
%SystemRoot%\System32\Inetsrv
%SystemRoot%\System32\WindowsPowerShell\v1.0\PowerShell.exe
%SystemRoot%\System32\inetsrv\w3wp.exe
Benutzt du einen Kaspersky? Er ist bekannt dafür mal die Netzwerkkommunikation zu scharf zuzusperren.
nein, hier ist Panda Adaptive Defense 360 verantwortlich gewesen.
