kurze Rückmeldung, falls zukünftige auf diesen Thread stoßen und genauso 'unsicher' sind.
Die Installation verlief ohne große Probleme und Störungen der Anwender. Habe direkt nach der Installation die URLs sowie das Zertifikat angepasst, also Vorschlag #3 aus Franky's Guide.
bekomme o.g. Fehlermeldung bei einem frisch installierten Exchange 2016 CU22 auf Windows Server 2016.
Habe bereits das System durchgestartet, ein neues Zertifikat wie im Internet beschrieben erstellt und eine Stunde abgewartet. Allerdings keine Veränderung - auch nach einem iisreset nichts.
Das Zertifikat ist dem SMTP zugeordnet. Mein öffentliches Zertifikat, welches den internen/externen URLs entspricht, ist IMAP + POP + IIS zugeordnet. Spricht da was gegen?
die Installation von einem neuen Exchange steht an. Jedoch möchte ich vorher noch Split-DNS einführen,
da aus der Vergangenheit heraus das Thema versäumt wurde. Aktuell ist der Exchange-Server mit der internen URL auf servername.domäne.tld konfiguriert statt auf mail.firma.de. Die externe URL ist allerdings bereits schon korrekt auf mail.firma.de konfiguriert.
Meine Herangehensweise wäre nun, dass ich folgende Tätigkeiten durchführe.
Im DNS zwei Zonen für mail.firma.de und autodiscover.firma.de konfigurieren.
Den Exchange-Server mit dem gültigen Zertifikat versorgen.
Via PowerShell-Skript (Danke an FrankysWeb) die Adressen anpassen, Ausschnitt: [ ... ]
Get-OwaVirtualDirectory -Server <Servername> | Set-OwaVirtualDirectory -InternalUrl 'https://mail.firma.de/owa' -ExternalUrl 'https://mail.firma.de/owa'
[ ... ]
Ist die o.g. Herangehensweise in Ordnung oder habe ich einen Punkt vergessen? Outlook sollte das ja (eigentlich?) nicht interessieren
und sich die neue Adresse für die Verbindung ziehen, oder?
Kann ich im IIS/Exchange irgendwo konfigurieren, dass der http-Zugriff automatisch auf https umgeleitet wird? Nach aktuellem Stand wurde z.B. OWA auch über mail.firma.de aufgerufen und dort hat die Umleitung der Reverse-Proxy übernommen.
