Jump to content

Outlook funktioniert außerhalb des Internen Netzwerks bei manchen nicht mehr (Exchange on prem 2019)


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Moin zusammen,

bei manchen Leuten funktioniert Outlook von außerhalb des internen Netzes nicht mehr. Manche können keine Verbindung zum Exchange herstellen wenn Sie ihr Notebook mit bereits eingerichtetem Outlook ins HO nehmen. Manche können in anderen Netzwerken keine neuen Postfächer einbinden, ebenfalls keine Verbindung zum Exchange möglich.

Ich konnte das Problem noch nicht reproduzieren und bin leider auch recht unerfahren mit Outlook Troubleshooting außerhalb des Netzwerkes.

Was ich mal gemacht habe ist einen Test bei:
https://testconnectivity.microsoft.com

Dabei kam das raus:

 

Es wird versucht, dem AutoErmittlungsdienst eine POST-Anforderung zu senden, damit er URLs ggf. automatisch erkennen kann.
Beim Senden der POST-Anforderungen für die AutoErmittlung konnten keine AutoErmittlungseinstellungen abgerufen werden.
 
 
Testschritte
Die Microsoft-Verbindungsuntersuchung versucht, eine XML-Antwort des AutoErmittlungsdiensts von URL https://XXXXX:443/Autodiscover/Autodiscover.xml für Benutzer XXXXX@XXXXX abzurufen.
Die Microsoft-Verbindungsuntersuchung konnte keine XML-Antwort von der AutoErmittlung abrufen.
 
 
Weitere Details
Ausnahmedetails:
Nachricht:
The request was aborted:
The connection was closed unexpectedly. Typ: System.Net.WebException
Stapelüberwachung:
at System.Net.HttpWebRequest.GetResponse() at Microsoft.M365.RCA.Services.RcaHttpRequest.GetResponse()


Woran kann es liegen dass die AutoErmittlung problem bekommt?

Kleine Ergänzung von dem Test:
Es wird versucht, die mögliche AutoErmittlungs-URL https://autodiscover.XXXX.de:443/Autodiscover/Autodiscover.xml zu testen.
URL der AutoErmittlung erfolgreich getestet.
 
 
Testschritte
Es wird versucht, den Hostnamen autodiscover.XXXX.de im DNS aufzulösen.
Der Hostname wurde erfolgreich aufgelöst.
 
 
Weitere Details
Es wird getestet, ob TCP-Port 443 auf Host autodiscover.XXXX.de ü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
Die IIS-Konfiguration wird im Hinblick auf die Clientzertifikatsauthentifizierung überprüft.
Keine Clientzertifikatsauthentifizierung erkannt.
 
 
Weitere Details
Es wird versucht, dem AutoErmittlungsdienst eine POST-Anforderung zu senden, damit er URLs ggf. automatisch erkennen kann.
Die Microsoft-Verbindungsuntersuchung hat die AutoErmittlung-Einstellungen erfolgreich durch das Senden von AutoErmittlung-POST-Daten abgerufen.
 
 

LG und vielen Dank
Lukas
bearbeitet von Lukikum
Link zu diesem Kommentar

Sorry, ganz vergessen zu erwähnen. Wir benutzen bei Windows Clients Outlook 2016 und bei Mac 2016/2019. Ich würde mich aber erstmal auf 2016 konzentrieren, da ich noch keine Zeit hatte den Mac genauer anzuschauen.

vor 1 Minute schrieb teletubbieland:

Moin,

 

hast Du O365 im Einsatz?

Bzw. welches Outlook verwenden die User bei denen es nicht funktioniert?

 

 

bearbeitet von Lukikum
Link zu diesem Kommentar

Hi,

 

der Autodiscover A-Record zeigt auf eure Firewall / ReverseProxy / Exchange? 

vor 56 Minuten schrieb Lukikum:
The connection was closed unexpectedly. Typ: System.Net.WebException

Ich würde tippen, dass da irgendetwas à la Web Application Firewall / Antivirus / SSL Scanner / ReverseProxy die Verbindung unterbricht.

 

Gruß

Jan

Link zu diesem Kommentar
vor 5 Minuten schrieb teletubbieland:

Es unterbindet den Versuch, dass die Outlook mit O365 verbinden will.

Das passiert vor Allem wenn ein connect mit AzureAD statt gefunden hat.

Da Du in der Fehlerbeschreibung relativ wenig von Eurer Umgebung preisgegeben hast, was das ein guess.

 

AzureAD benutzen wir noch nicht. Die Umgebung läuft komplett on prem.

Link zu diesem Kommentar
vor 12 Minuten schrieb Lukikum:

AzureAD benutzen wir noch nicht. Die Umgebung läuft komplett on prem.

Hat doch nichts damit zu tun

Alles ab OL 2016 geht primär auf O365, daher der link

Du kannst es ja mal selber testen

https://testconnectivity.microsoft.com/tests/exchange

:-)

Und bescheibe mal bitte so genau wie möglich was zwischen der Welt und dem Exchange ist, danke

Link zu diesem Kommentar
vor 22 Minuten schrieb Nobbyaushb:

Du kannst es ja mal selber testen

https://testconnectivity.microsoft.com/tests/exchange

Ich habe es jetzt nach einer halben Stunde erneut probiert und dieses mal zeigt der Test mir auch tatsächlich an, dass die Verbindung nicht möglich. Es scheint so als wenn er die Methoden des AutoDsicovers durchgeht und dann gelingt. Also ist das wohl doch nicht das Problem. Wo er dann einen terminierenden Fehler bekommt, ist bei MAPI over HTTP, bei dem Punkt wo er das Adressbuch testet:
 

Die MAPI-über-HTTP-Verbindung mit Server "XX.XX.de" wird getestet.
Fehler bei der MAPI-über-HTTP-Verbindung.
 
 
Testschritte
Es wird versucht, den Hostnamen XX.XX.de im DNS aufzulösen.
Der Hostname wurde erfolgreich aufgelöst.
 
 
Weitere Details
Es wird getestet, ob TCP-Port 443 auf Host XX.XX.de ü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 XXXX 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 XXX anhand von Server "XX.XX.de" getestet.
Beim Versuch, den Namen aufzulösen, ist ein Fehler aufgetreten.
 
 
Weitere Details
Fehler in der Protokollschicht. HttpStatusCode: 401 Fehler-LID: 47372 Fehlerinformationen: ###### REQUEST [2023-02-13T10:46:22.3468449Z] [ResolvedIPs: XXXXXXXXX] ###### POST /XXXXXXXXXXXXXXXXXX HTTP/1.1 Content-Type: application/octet-stream User-Agent: MapiHttpClient X-RequestId: df305a3f-04fd-4a3d-8ac7-c2836f248a63:1 X-ClientInfo: 5a63d204-0c30-4c2d-a85c-fabe47b53422:1 client-request-id: 2e988979-5ef2-4cc7-8651-642ed73a804d X-ClientApplication: MapiHttpClient/15.20.5791.1 X-RequestType: Bind Authorization: Negotiate [truncated] Host: XX.XX.de Content-Length: 45 --- REQUEST BODY [+0.246] --- ..[BODY SIZE: 45] --- REQUEST SENT [+0.247] --- ###### RESPONSE [+0.499] ###### HTTP/1.1 401 Unauthorized request-id: 49326cee-aad3-4a14-86d4-d87874eac02d x-owa-version: 15.2.1118.21 x-failurecontext: FrontEnd;401;VW5hdXRob3JpemVk;;;; Server: Microsoft-IIS/10.0 WWW-Authenticate: Negotiate,NTLM x-powered-by: ASP.NET x-feserver: XX-MAIL date: Mon, 13 Feb 2023 10:46:22 GMT content-length: 0 --- RESPONSE BODY [+0.500] --- --- RESPONSE DONE [+0.500] --- ###### EXCEPTION THROWN [+0.500] ###### HTTP-Antwortkopfzeilen: request-id: 49326cee-aad3-4a14-86d4-d87874eac02d x-owa-version: 15.2.1118.21 x-failurecontext: FrontEnd;401;VW5hdXRob3JpemVk;;;; Server: Microsoft-IIS/10.0 WWW-Authenticate: Negotiate,NTLM x-powered-by: ASP.NET x-feserver: XX-MAIL date: Mon, 13 Feb 2023 10:46:22 GMT content-length: 0 HTTP-Statuscode: 401 Unauthorized

 
Zwischen Exchange und Client haben wir einen Smarthost und einen ReverseProxy, welche die Anfragen an die Exchange weiterleiten.

Ich kann mir vorstellen dass es ein Serverspezifisches Problem ist, da der Fehler nicht immer bei den Tests Auftritt. Ich überprüfe das mal weiter in den nächsten Stunden.
Link zu diesem Kommentar
vor 42 Minuten schrieb Nobbyaushb:

Was für ein Reverse-Proxy ist das?

Intern gibt es keine Probleme?

Wenn nein, kein Exchange-Problem, ich tippe auf den Reverse

Der Smarthost macht ja nur Port 25 Mailtraffic - eigentlich…

Wir benutzen HAProxy. Ob da ein Fehler auftritt ist schwierig einzuschätzen, kann aber sein. Wie troubleshootet man so etwas denn?

Intern sind mir bis jetzt keine derartigen Probleme bekannt.

Jetzt habe ich den Test erneut ausgeführt und die Rückmeldung bekommen dass die Verbindung "Erfolgreich mit Warnungen" ist.

Zur Info, ich habe einen Beitrag im Netz zu was ähnlichem gefunden, mit ähnlichen Voraussetzungen, den schau ich mir mal an:

https://github.com/haproxy/haproxy/issues/1828

Okay also es scheint wohl etwas mit SSL Bridging und verschiedenen Zertifikatspaaren zu tun haben:
 

What mamama1 is doing is SSL bridging but not SSL offloading. SSL bridging is supported. reference

The missing piece here is that the reverse proxy must use the exact same certificate-key pair as the backend for the Extended Protection to work (explained in the refence link above). As of the latest Exchange 2016 CU, the MAPI over HTTP does not require session affiliation, so you don't need to set up any affiliation in the haproxy setting.'


Ich habe tatsächlich vor kurzem erst die extended Protection aktiviert, ähnlich wie im anderen Beitrag. Ich denke da werde ich mir erstmal ein paar Basics für aneignen müssen..

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...