schmitzp1978 0 Geschrieben 13. Juli 2018 Melden Teilen Geschrieben 13. Juli 2018 Liebe Freunde des Exchange, ich benötige bitte euer Schwarmwissen. Folgendes Problem stellt sich dar: Im Einsatz ein Exchange 2016 CU11 auf Server 2016. Die AD hat die Gesamtstrukturfunktionsebene Server 2016. Der Exchange ist von außen erreichbar zwecks OWA und ActiveSync mit der URL https://outlook.contoso.de. Alle externen Pfade zeigen auf diese URL. Alle internen Pfade zeigen auf die URL https://exchange.contoso.local Da wir nun aber ein Letsencrypt-Zertifikat nutzen, bekommen alle Outlook 2016-Clients eine Zertifikatwarnung. Das liegt natürlich daran, dass .local - Adressen nicht in das Zertifikat mit aufgenommen werden können. Ich habe nun folgenden Lösungsansatz durchgeführt: Im internen DNS habe ich eine neue Forward-Zone mit dem Namen exchange.contoso.de erstellt und dort einen A-Eintrag auf die interne IP des Exchange gesetzt (der Name des Host-A-Eintrages ist identisch mit übergeordnetem Ordner). Danach habe ich die internen Pfade per GUI und Powershell im Exchange angepasst mit Set-ClientAccessServer -Identity "EX01" -AutodiscoverServiceInternalURI "https://exchange.contoso.de/Autodiscover/Autodiscover.xml" und Set-AutodiscoverVirtualDirectory -Identity "EX01\Autodiscover (Default Web Site)" -Interna lUrl "https://EX01.contoso.de/Autodiscover/Autodiscover.xml" -ExternalUrl "https://outlook.contoso.de/Autodisco ver/Autodiscover.xml" Die restlichen Pfade wie MAPI, OWA, EWS, ECP, ActiveSync usw. habe ich per GUI geändert. Ein nslookup und ping im internen Netz auf exchange.contoso.de funktioniert auf den Clients einwandfrei (DNS funktioniert also). Ein ipconfig /flushdns wurde von mir durchgeführt (auch auf den Servern). Trotzdem verbinden die Outlook-Clients sich nicht mit exchange.contoso.de. Eine Verbindung wird überhaupt nicht mehr aufgebaut. Wenn ich am Client eine E-Mail-AutoKonfiguration durchführe, zeigt er mir an, dass nach wie vor noch alle internen URLS auf exchange.contoso.local zeigen. Habt ihr noch eine Idee, warum meine Konfiguration nicht funktioniert? PS: Die Domäne heißt natürlich nicht contoso, ich habe hier einfach einen anderen Namen zu Veranschaulichung genommen. Vielen Dank und ein schönes WE euch! Zitieren Link zu diesem Kommentar
TheCracked 13 Geschrieben 13. Juli 2018 Melden Teilen Geschrieben 13. Juli 2018 Funktioniert denn intern owa mit "exchange.contoso.de" ? Zitieren Link zu diesem Kommentar
testperson 1.680 Geschrieben 13. Juli 2018 Melden Teilen Geschrieben 13. Juli 2018 (bearbeitet) Hi, wenn du unbedingt intern exchange.<domain>.<tld> und extern outlook.<domain>.<tld> willst, dann stelle sicher, dass die internen und externen virtuellen Verzeichnisse auch wirklich korrekt konfiguriert sind boote den Exchange einmal durch und dann die Clients. Alternativ habe Geduld. Das Zertifikat passt und hat beide FQDNs sowie autodiscover.<domain>.<tld> bzw. autodiscover.<aller Domains der primären SMTP Adressen> als SAN? Gruß Jan P.S.: Der Einfachheit halber würde ich intern und extern outlook.<domain>.<tld> nutzen. bearbeitet 13. Juli 2018 von testperson Zitieren Link zu diesem Kommentar
Nobbyaushb 1.471 Geschrieben 13. Juli 2018 Melden Teilen Geschrieben 13. Juli 2018 ^^Moin, nur ganz kurz und ergänzend - warum so kompliziert? Das Geheimnis lautet Split-DNS, so heißen die internen und externen URL gleich und man braucht nur ein Zertifikat. Ich kann zwar verschiedene Zertifikate an den Exchange binden, (wird intern ja auch gemacht...) aber der IIS kann halkt nur eines - und das brauchst du für die Kommunikation vom Exchange mit den Clients, egal ob Outlook, EAS, OWA oder was auch immer. :) Zitieren Link zu diesem Kommentar
schmitzp1978 0 Geschrieben 31. Juli 2018 Autor Melden Teilen Geschrieben 31. Juli 2018 Entschuldigt die späte Antwort, ich bin jetzt erst dazu gekommen, das Thema erneut anzugehen. Die Lösung war: Neustart des IIS. Danach verbinden sich die Clients, wenn auch sehr zögerlich. Leider hat das zu einem Problem geführt: Bei jedem Neustart der Exchange-Server, z.B. bei Windows-Updates, muss ich im IIS das Zertifikat neu an den Port binden (im Exchange Backend, Port 444). Er verliert es leider nach jedem Reboot. Zitieren Link zu diesem Kommentar
Nobbyaushb 1.471 Geschrieben 31. Juli 2018 Melden Teilen Geschrieben 31. Juli 2018 Was bindest du denn wo? Zertifikate werden immer über den Exchange verwaltet, nie im IIS. NIEMALS die Internen Zertifikate anfassen - warum Bindung auf Backend? Da ist gehörig was schräg, das sollte sich meiner Meinung nach jemand mit Erfahrung ansehen - das geht nicht in einem Forum Zitieren Link zu diesem Kommentar
schmitzp1978 0 Geschrieben 31. Juli 2018 Autor Melden Teilen Geschrieben 31. Juli 2018 Logisch werden die Zertifikate über den Exchange verwaltet und nicht über den IIS. Habe ich auch so nie gemacht. Seit dem umstellen der Pfade, verliert er aber die Zertifikatsbindung nach jedem reboot. Ohne ein manuelles einbinden funktioniert da nichts. Die internen Zertifikate wurden auch nicht angefasst. Es sind auf jedem Exchange 3 Zertifikate vorhanden: Externes Zertifikat WMSVC-SHA2 Microsoft Exchange Server Auth Certificate Zitieren Link zu diesem Kommentar
andreas.l 0 Geschrieben 31. Juli 2018 Melden Teilen Geschrieben 31. Juli 2018 Hab gerade keinen Exchange 2016 zur Hand, daher konnte ich nur auf einem 2013er nachsehen: Du hast das Zertifikat "Microsoft Exchange" nicht mehr im ECP drin? Das wir ja standardmäßig vom Exchange auf den Hostnamen erstellt. Dieses ist bei mir im Backend auf den Port 444 gebunden. Ist das beim 2016er anders? Dachte, das wäre dort gleich geblieben. Bitte korrigieren, wenn das falsch ist. Evtl. kannst du das Zertifikat mit dem Anzeigenamen neu erstellen und dann dieses an den Backend Port binden? der CN ist bei mir der Hostname des Exchange Servers und als SAN (Subject Alternative Names) ist dort noch der FQDN mit drin. Zitieren Link zu diesem Kommentar
schmitzp1978 0 Geschrieben 1. August 2018 Autor Melden Teilen Geschrieben 1. August 2018 Genauso muss das sein. Ist beim Exchange 2016 genauso. Ich habe aber das externe Zertifikat dort gebunden. Vielleicht habe ich einfach das falsche Zertifikat ausgewählt und muss das interne vom Exchange ausgestellte verwenden. Das könnte der Grund sein. Ich werde das heute Abend testen. Danke für die Info. Zitieren Link zu diesem Kommentar
Nobbyaushb 1.471 Geschrieben 1. August 2018 Melden Teilen Geschrieben 1. August 2018 (bearbeitet) vor 52 Minuten schrieb schmitzp1978: Genauso muss das sein. Ist beim Exchange 2016 genauso. Ich habe aber das externe Zertifikat dort gebunden. Vielleicht habe ich einfach das falsche Zertifikat ausgewählt und muss das interne vom Exchange ausgestellte verwenden. Das könnte der Grund sein. Ich werde das heute Abend testen. Danke für die Info. Das externe Zert kannst du nicht an den Backend binden. Dann kommen Lustige Effekte - wie man sieht... bearbeitet 1. August 2018 von Nobbyaushb Zitieren Link zu diesem Kommentar
schmitzp1978 0 Geschrieben 1. August 2018 Autor Melden Teilen Geschrieben 1. August 2018 Ja das habe ich leider nun erfahren müssen. Danke euch Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.