Analyse von Outlook-Exchange-Kommunikationsproblemen mit Reverse Proxy
Hallo Community,
in einer Umgebung mit Exchange 2019 on-premise habe ich sporadisch Probleme bei der Kommunikation zwischen Outlook (Version 2019) und dem Exchange Server. In unregelmäßigen Abständen wird beim Start von Outlook die Fehlermeldung ausgegeben, dass der Server nicht gefunden werden kann. Das Problem lässt sich entweder "beheben" indem der Anwender einige Minuten wartet und im schlimmsten Fall seinen PC neu startet. Der Fehler tritt nicht so häufig auf um das Arbeiten unmöglich zu machen, aber doch so häufig um den Mitarbeitern stark auf die Nerven zu gehen.
Die Namensauflösung im Netzwerk funktioniert, das Zertifikat auf dem Exchange ist korrekt zugewiesen, der SCP stimmt auch. Be der Ausführung des Exchange Health-Checker Scripts werden keine Fehler protokolliert. Auf den Clients habe ich das Outlook-Profil neu erstellt und die Antiviren-Software (Avast) deinstalliert.
Das Problem besteht jedoch weiterhin.
Als Möglichkeit dem Fehler doch noch auf die Spur zu kommen wollte ich die Outlook-Kommunikation mittels eines Reverse-Proxy belauschen und habe mich deshalb mit Fiddler und dem Charles Web Debuggung Proxy versucht.
Bei Fiddler lande ich leider trotz importiertem Zertifikat in einer Endlosschleife bei Outlook immer wieder nach Anmeldenamen fragt, beim Charles Proxy habe ich die Outlook-Konfiguration so gründlich zerschossen, dass nur die Neu-Einrichtung des Profils überhaupt wieder eine Verbindung zum Exchange ermöglichte.
Mit den bisher von mir gefundenen Anleitung konnte bisher keinen weiteren Ansatz finde um eine Analyse mittels Reverse-Proxy zum Laufen zu bringen. Kennt jemand von Euch eine Anleitung a la Reverse Proxy für Dummies zur Analyse von HTTPS-Traffic?
Grüße
Tobias
in einer Umgebung mit Exchange 2019 on-premise habe ich sporadisch Probleme bei der Kommunikation zwischen Outlook (Version 2019) und dem Exchange Server. In unregelmäßigen Abständen wird beim Start von Outlook die Fehlermeldung ausgegeben, dass der Server nicht gefunden werden kann. Das Problem lässt sich entweder "beheben" indem der Anwender einige Minuten wartet und im schlimmsten Fall seinen PC neu startet. Der Fehler tritt nicht so häufig auf um das Arbeiten unmöglich zu machen, aber doch so häufig um den Mitarbeitern stark auf die Nerven zu gehen.
Die Namensauflösung im Netzwerk funktioniert, das Zertifikat auf dem Exchange ist korrekt zugewiesen, der SCP stimmt auch. Be der Ausführung des Exchange Health-Checker Scripts werden keine Fehler protokolliert. Auf den Clients habe ich das Outlook-Profil neu erstellt und die Antiviren-Software (Avast) deinstalliert.
Das Problem besteht jedoch weiterhin.
Als Möglichkeit dem Fehler doch noch auf die Spur zu kommen wollte ich die Outlook-Kommunikation mittels eines Reverse-Proxy belauschen und habe mich deshalb mit Fiddler und dem Charles Web Debuggung Proxy versucht.
Bei Fiddler lande ich leider trotz importiertem Zertifikat in einer Endlosschleife bei Outlook immer wieder nach Anmeldenamen fragt, beim Charles Proxy habe ich die Outlook-Konfiguration so gründlich zerschossen, dass nur die Neu-Einrichtung des Profils überhaupt wieder eine Verbindung zum Exchange ermöglichte.
Mit den bisher von mir gefundenen Anleitung konnte bisher keinen weiteren Ansatz finde um eine Analyse mittels Reverse-Proxy zum Laufen zu bringen. Kennt jemand von Euch eine Anleitung a la Reverse Proxy für Dummies zur Analyse von HTTPS-Traffic?
Grüße
Tobias
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 669750
Url: https://administrator.de/contentid/669750
Ausgedruckt am: 25.11.2024 um 17:11 Uhr
3 Kommentare
Neuester Kommentar