Exchange 2019 auf gekauftes Zertifikat umstellen
Hallo zusammen,
ich möchte bei einem lokalen Exchange 2019 im AD das Zertifikat umstellen von selbstsigniert über (AD CS) auf gekauft.
Momentan laufen die Outlook-Clients intern über die exchangeserver.local-Adresse zum Exchange. Wenn ich nun die virtuellen Verzeichnisse etc. auf eine öffentliche Domain umstelle (mail. und autodiscover.), dann werden danach wohl die bereits eingerichteten Outlook-Clients nicht mehr den Server erreichen.
Wie lässt sich das beheben/vermeiden?
Ich plane nach dieser Anleitung zu verfahren - und in den Kommentaren taucht besagtes Problem ja mehrfach auf.
https://www.frankysweb.de/exchange-2016-zertifikate-konfigurieren-teil-2 ...
Vielen Dank vorab!
Gruß
Colt
ich möchte bei einem lokalen Exchange 2019 im AD das Zertifikat umstellen von selbstsigniert über (AD CS) auf gekauft.
Momentan laufen die Outlook-Clients intern über die exchangeserver.local-Adresse zum Exchange. Wenn ich nun die virtuellen Verzeichnisse etc. auf eine öffentliche Domain umstelle (mail. und autodiscover.), dann werden danach wohl die bereits eingerichteten Outlook-Clients nicht mehr den Server erreichen.
Wie lässt sich das beheben/vermeiden?
Ich plane nach dieser Anleitung zu verfahren - und in den Kommentaren taucht besagtes Problem ja mehrfach auf.
https://www.frankysweb.de/exchange-2016-zertifikate-konfigurieren-teil-2 ...
Vielen Dank vorab!
Gruß
Colt
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672807
Url: https://administrator.de/forum/exchange-2019-auf-gekauftes-zertifikat-umstellen-672807.html
Ausgedruckt am: 10.05.2025 um 14:05 Uhr
18 Kommentare
Neuester Kommentar
Moin,
naja erreichen: Zertifikat ist Name und nicht IP.
Wäre .local weltweit auflösebar - wie DE - wäre es auch kein Thema. Das ist der Gedanke dahinter.
Wenn man kostenlose nimmt braucht es eine Challenge um festzustellen dass der Exchange auch derjenige welche ist. Bei HTTP muss also Apache/ IIS o.ä. von außen erreichbar sein. Bei DNS Challange hat man meist eine TXT mit kryptischen Textcode in der Domainverwaltung.
Hatte nie eines gekauft. Die Challenge dürfte hier ja dann vermutlich obsolet sein. Auch ACME Script Let's Encrypt.
All das hast du ja nun nicht mehr.
https://www.alitajran.com/install-exchange-certificate-with-powershell/
Bei Franky's Web ähnlich. Hier ging es bei Migration um Übertragung der vorhanenden Zertifikate. Import fällt ja nun bei dir weg, da es ja wohl via Mail vom Aussteler geliefert wird!
Import ist weg. [...] Menü gibt es nicht mehr. Deswegen importieren einige das Ding so. "Mit So" meine ich den Winndows Zertifikate-Manager - gab hier auch im Forum erst vor ein paar Wochen Thema dazu!
Alternative kannst du wie oben mit PowerShell importieren.
Ja es ist so ekelig mit ReadAllBytes.
Assign certificate to the Exchange Server services
Da wird es dann zugewiesen.
https://learn.microsoft.com/de-de/powershell/module/exchange/get-exchang ...
,
Ich rate drigend das letzte mal zu üben! PowerShell ist für die Verwaltung essentiell. Hier siehst du auch Thumbprints von installieren Zertifikaten.
Um ein Zertifikat in den weiten des Serviers zu finden ist Get-ExchangeCertificate das Mittel der Wahl. Dein Freund ist Thumbprint - alles eindeutig auffindbar!
Autodiscover sollte ja jetzt schon laufen. Macht vieles einfacher! Normal ist es kein Problem. Neues Zertifikat wird meist automatisch erkannt und verwendet.
Wir hatten Autodiscover auch geändert: Intern 2010 zu Intern 2016 z.B. Wäre bei dir 1:1 das Gleiche.
Ich nehme Autodiscover Änderungen vor und die Clients fragen die beim nächsten Start ab. Wir hatten ganze DNS Subdomäne entfernt. Neuer Name, alte gab es nicht.
Egal ob intern oder extern. Solche Änderungen an Autodiscover sind "immer massiv", aber i.d.R. läuft alles automatisch.
Ansonten kann man Autodiscover auch manuell am Client umbiegen. Ist aber wie IPs in der Hostdatei. Es rächt sich irgendwann. So eine Umstellung geht meist ohne Rückmeldungen. Ansonten kommt max. ein Bestätigungsdialog beim Ausführen von Outlook.
Strg + re. Mausstage auf das OL Tray-Icon neben der Uhr. Verbindungsübersicht zeigt dir alles an.
Du kannst hier auch Autodiscover testen, wenn nötig. Für dich wäre ja die Domän-Spalte interessant! Wurde die neue "gezogen"?
ping neue-domain.de, nslookup - das übliche bei Problemen. Sind die DNS Änderungen aber soweit durchgelaufen sollte im Verbindungsstatus dann die korrekte Domäne stehen.
Das wäre es im Großen und Ganzen.
naja erreichen: Zertifikat ist Name und nicht IP.
Wäre .local weltweit auflösebar - wie DE - wäre es auch kein Thema. Das ist der Gedanke dahinter.
Wenn man kostenlose nimmt braucht es eine Challenge um festzustellen dass der Exchange auch derjenige welche ist. Bei HTTP muss also Apache/ IIS o.ä. von außen erreichbar sein. Bei DNS Challange hat man meist eine TXT mit kryptischen Textcode in der Domainverwaltung.
Hatte nie eines gekauft. Die Challenge dürfte hier ja dann vermutlich obsolet sein. Auch ACME Script Let's Encrypt.
All das hast du ja nun nicht mehr.
https://www.alitajran.com/install-exchange-certificate-with-powershell/
Bei Franky's Web ähnlich. Hier ging es bei Migration um Übertragung der vorhanenden Zertifikate. Import fällt ja nun bei dir weg, da es ja wohl via Mail vom Aussteler geliefert wird!
Import ist weg. [...] Menü gibt es nicht mehr. Deswegen importieren einige das Ding so. "Mit So" meine ich den Winndows Zertifikate-Manager - gab hier auch im Forum erst vor ein paar Wochen Thema dazu!
Alternative kannst du wie oben mit PowerShell importieren.
Import-ExchangeCertificate -Server "EX01-2016" -FileData ([System.IO.File]::ReadAllBytes('\\ex01-2016\Certs\ExchangeCert.pfx')) -PrivateKeyExportable:$true -Password (ConvertTo-SecureString -String 'P@ssw0rd1' -AsPlainText -Force Ja es ist so ekelig mit ReadAllBytes.
Assign certificate to the Exchange Server services
Enable-ExchangeCertificate -Server "EX01-2016" -Thumbprint 0C4C00B76EB7DB236573BF79258888D32C9B753D -Services SMTP,IMAP,IIS Da wird es dann zugewiesen.
https://learn.microsoft.com/de-de/powershell/module/exchange/get-exchang ...
,
Get-ExchangeCertificate -Server Mailbox01Ich rate drigend das letzte mal zu üben! PowerShell ist für die Verwaltung essentiell. Hier siehst du auch Thumbprints von installieren Zertifikaten.
Um ein Zertifikat in den weiten des Serviers zu finden ist Get-ExchangeCertificate das Mittel der Wahl. Dein Freund ist Thumbprint - alles eindeutig auffindbar!
Autodiscover sollte ja jetzt schon laufen. Macht vieles einfacher! Normal ist es kein Problem. Neues Zertifikat wird meist automatisch erkannt und verwendet.
Wir hatten Autodiscover auch geändert: Intern 2010 zu Intern 2016 z.B. Wäre bei dir 1:1 das Gleiche.
Ich nehme Autodiscover Änderungen vor und die Clients fragen die beim nächsten Start ab. Wir hatten ganze DNS Subdomäne entfernt. Neuer Name, alte gab es nicht.
Egal ob intern oder extern. Solche Änderungen an Autodiscover sind "immer massiv", aber i.d.R. läuft alles automatisch.
Ansonten kann man Autodiscover auch manuell am Client umbiegen. Ist aber wie IPs in der Hostdatei. Es rächt sich irgendwann. So eine Umstellung geht meist ohne Rückmeldungen. Ansonten kommt max. ein Bestätigungsdialog beim Ausführen von Outlook.
Strg + re. Mausstage auf das OL Tray-Icon neben der Uhr. Verbindungsübersicht zeigt dir alles an.
Du kannst hier auch Autodiscover testen, wenn nötig. Für dich wäre ja die Domän-Spalte interessant! Wurde die neue "gezogen"?
ping neue-domain.de, nslookup - das übliche bei Problemen. Sind die DNS Änderungen aber soweit durchgelaufen sollte im Verbindungsstatus dann die korrekte Domäne stehen.
Das wäre es im Großen und Ganzen.
PS:
Ich sagte Hostdatei ist böse.... Stimmt nicht ganz!
Wenn du zum Testen - rät ja auch Franky - an einen Client Autodisover via Host-File umbiegst, dann siehst du doch rasch selber wie sich OL nach einen Neustart verhält!
Geh ja auch nach Feierabend... Wenn die Zertifiakte nicht gelöscht sind, sind sie mit Thumbprint im System auffindbar. Also einfach wieder zurück stellen. Das ist eig. schmerzfrei möglich.
Hostdatei bei DNS ist einfach schneller, da es ja etwas braucht bist alle die Änderung mit bekommen haben.
Mehr ist dazu nicht zu sagen.
Ich sagte Hostdatei ist böse.... Stimmt nicht ganz!
Wenn du zum Testen - rät ja auch Franky - an einen Client Autodisover via Host-File umbiegst, dann siehst du doch rasch selber wie sich OL nach einen Neustart verhält!
Geh ja auch nach Feierabend... Wenn die Zertifiakte nicht gelöscht sind, sind sie mit Thumbprint im System auffindbar. Also einfach wieder zurück stellen. Das ist eig. schmerzfrei möglich.
Hostdatei bei DNS ist einfach schneller, da es ja etwas braucht bist alle die Änderung mit bekommen haben.
Mehr ist dazu nicht zu sagen.
moin!
Vielen Dank für Deine Antwort.
Mir geht es nochmal um folgenden Punkt:
Wenn ich nun das gekaufte Zertifikat (mit autodiscover.domain.xy mail.domain.xy) im Exchange korrekt eingebunden habe und im Exchange alles angepasst habe, passiert ja folgendes:
Outlook Client wird gestartet und guckt wie gewohnt erstmal unter autodiscover.exchange2019.local.
Die DNS-Auflösung zeigt ja weiterhin auf den Exchange (von daher sehe ich beim DNS auch kein Problem), aber der liefert dann ein Zertifikat mit domain.xy am Ende aus und nicht mit .local - also wirft der Outlook Client nen Fehler und nix geht mehr.
Wie man in den Kommentaren des Artikels auf frankysweb lesen kann, kommen deshalb dann ja bei den bereits eingerichteten Outlook-Clients die Zertifikatfehler - ein Autodiscover-Austausch kommt dann ja auch gar nicht zustande, weil so weit kommt es dann ja gar nicht.
Von daher nochmal die Frage: wie lässt sich dieses Problem verhindern? Offenbar läuft an dieser Stelle ja nicht alles automatisch.
Gruß
Colt
Vielen Dank für Deine Antwort.
Mir geht es nochmal um folgenden Punkt:
Wenn ich nun das gekaufte Zertifikat (mit autodiscover.domain.xy mail.domain.xy) im Exchange korrekt eingebunden habe und im Exchange alles angepasst habe, passiert ja folgendes:
Outlook Client wird gestartet und guckt wie gewohnt erstmal unter autodiscover.exchange2019.local.
Die DNS-Auflösung zeigt ja weiterhin auf den Exchange (von daher sehe ich beim DNS auch kein Problem), aber der liefert dann ein Zertifikat mit domain.xy am Ende aus und nicht mit .local - also wirft der Outlook Client nen Fehler und nix geht mehr.
Wie man in den Kommentaren des Artikels auf frankysweb lesen kann, kommen deshalb dann ja bei den bereits eingerichteten Outlook-Clients die Zertifikatfehler - ein Autodiscover-Austausch kommt dann ja auch gar nicht zustande, weil so weit kommt es dann ja gar nicht.
Von daher nochmal die Frage: wie lässt sich dieses Problem verhindern? Offenbar läuft an dieser Stelle ja nicht alles automatisch.
Gruß
Colt
Ich glaube, Du verwechselst da was.
autodiscover.exchange2019.local
Das würde ja bedeuten, dass da ein Postfach mit einer Adresse aus @exchange2019.local eingerichtet wäre. Wird es aber nicht sein, oder?
Erstelle auf dem internen DNS Server zwei Zonen, mit diesen beiden Namen
E.
autodiscover.exchange2019.local
Das würde ja bedeuten, dass da ein Postfach mit einer Adresse aus @exchange2019.local eingerichtet wäre. Wird es aber nicht sein, oder?
Erstelle auf dem internen DNS Server zwei Zonen, mit diesen beiden Namen
- autodiscover.domain.xy
- mail.domain.xy
E.
Sorry - war nicht ganz korrekt formuliert.
Der Exchange-Server ist ja von intern und extern erreichbar.
Intern heißt er exchange2019.ad-domain.local. Und extern über mail.domain.xy.
Der Outlook-Client im LAN ruft also autodiscover.exchange2019.ad-domain.local auf.
Nach der Umstellung meldet sich der Exchange und schickt ein Zertifikat mit, das nach der Umstellung nur noch domain.xy enthält. Und dann meckert der Outlook-Client verständlicherweise.
Schaut doch mal in den Kommentaren des Artikels - das Problem haben doch mehrere dort gemeldet.
Zu den Postfächern: auch die haben im AD doppelte Bezeichnungen: mueller@domain.xy, aber eben auch mueller@ad-domain.local.
Zu sehen im Exchange Admin-Center unter Empfänger -> Postfächer -> E-Mail-Adresse:
Gruß
Colt
Der Exchange-Server ist ja von intern und extern erreichbar.
Intern heißt er exchange2019.ad-domain.local. Und extern über mail.domain.xy.
Der Outlook-Client im LAN ruft also autodiscover.exchange2019.ad-domain.local auf.
Nach der Umstellung meldet sich der Exchange und schickt ein Zertifikat mit, das nach der Umstellung nur noch domain.xy enthält. Und dann meckert der Outlook-Client verständlicherweise.
Schaut doch mal in den Kommentaren des Artikels - das Problem haben doch mehrere dort gemeldet.
Zu den Postfächern: auch die haben im AD doppelte Bezeichnungen: mueller@domain.xy, aber eben auch mueller@ad-domain.local.
Zu sehen im Exchange Admin-Center unter Empfänger -> Postfächer -> E-Mail-Adresse:
Gruß
Colt
Zitat von @emeriks:
Ich glaube, Du verwechselst da was.
autodiscover.exchange2019.local
Das würde ja bedeuten, dass da ein Postfach mit einer Adresse aus @exchange2019.local eingerichtet wäre. Wird es aber nicht sein, oder?
Doch ich glaube genau das ist gemeint. Wenn der DNS Name deines Servers wechselt (weil wie hier ein Zertifikat auf einen anderen Namen lauten muss) dann wirst du Outlook neu einrichten müssen. DNS wie beschrieben einrichten, Zertifikat einbinden, Exchange URLs ändern, Mail Profil löschen und Outlook starten. Dann sollte Autodiscover den Rest machen - idealerweise^^Ich glaube, Du verwechselst da was.
autodiscover.exchange2019.local
Das würde ja bedeuten, dass da ein Postfach mit einer Adresse aus @exchange2019.local eingerichtet wäre. Wird es aber nicht sein, oder?
1Zitat von @ukulele-7:
Doch ich glaube genau das ist gemeint. Wenn der DNS Name deines Servers wechselt (weil wie hier ein Zertifikat auf einen anderen Namen lauten muss) dann wirst du Outlook neu einrichten müssen. DNS wie beschrieben einrichten, Zertifikat einbinden, Exchange URLs ändern, Mail Profil löschen und Outlook starten. Dann sollte Autodiscover den Rest machen - idealerweise^^
Doch ich glaube genau das ist gemeint. Wenn der DNS Name deines Servers wechselt (weil wie hier ein Zertifikat auf einen anderen Namen lauten muss) dann wirst du Outlook neu einrichten müssen. DNS wie beschrieben einrichten, Zertifikat einbinden, Exchange URLs ändern, Mail Profil löschen und Outlook starten. Dann sollte Autodiscover den Rest machen - idealerweise^^
endlich versteht mich jemand!
Genau darum geht es - das möchte ich irgendwie verhindern.
1)
Wenn die Outlook-Clients feststellen, dass die interne URL nicht fehlerfrei läuft, probieren dann automatisch den autodiscover über die externe URL? Das würde mir reichen, weil die ändert sich ja nicht, ist also bereits in den Clients bekannt.
2)
Sollte 1) nicht funktionieren: kann ich denn die Clients z.B: über Gruppenrichtlinien umbiegen? Dutzende Clients neu einrichten - das muss man doch irgendwie verhindern können?!
Gruß
Colt
zu 1)
Nein. Ein bereits eingerichtetes Outlook Profil sucht nach dem dort hinterlegten Server und wird diesen kontaktieren. Beim DNS ist das ja erstmal kein Problem. Der Exchange weiß auch nicht, welchen DNS Namen du verwendet hast, um Kontakt aufzunehmen. Er wird einfach davon ausgehen, das du die neue URL angefragt hast und liefert auch nur das eine Zertifikat mit aus, egal an wen. Dein Client bekommt dann nicht gesagt "hier ist mein neuer Servername" sondern dein Client merkt, Zertifikat passt nicht zum angefragten Server. Rein aus Sicherheitsaspekten kann der Client ja auch nicht wissen, das der Server jetzt legitim anders heißt sondern er denkt sich "das ist nicht der, den ich wollte".
zu 2)
Da bin ich nicht sicher. Ich mache wirklich viel mit GPOs aber diese Outlook Profile sind wirklich nicht trivial. Ich glaube nicht aber vielleicht geht es irgendwie. Wir haben mal, im Rahmen eines anderen Problems, den Exchange-Namen (für intern und extern identisch) geändert. Ich meine aber, wir haben alle Profile neu gemacht.
Nein. Ein bereits eingerichtetes Outlook Profil sucht nach dem dort hinterlegten Server und wird diesen kontaktieren. Beim DNS ist das ja erstmal kein Problem. Der Exchange weiß auch nicht, welchen DNS Namen du verwendet hast, um Kontakt aufzunehmen. Er wird einfach davon ausgehen, das du die neue URL angefragt hast und liefert auch nur das eine Zertifikat mit aus, egal an wen. Dein Client bekommt dann nicht gesagt "hier ist mein neuer Servername" sondern dein Client merkt, Zertifikat passt nicht zum angefragten Server. Rein aus Sicherheitsaspekten kann der Client ja auch nicht wissen, das der Server jetzt legitim anders heißt sondern er denkt sich "das ist nicht der, den ich wollte".
zu 2)
Da bin ich nicht sicher. Ich mache wirklich viel mit GPOs aber diese Outlook Profile sind wirklich nicht trivial. Ich glaube nicht aber vielleicht geht es irgendwie. Wir haben mal, im Rahmen eines anderen Problems, den Exchange-Namen (für intern und extern identisch) geändert. Ich meine aber, wir haben alle Profile neu gemacht.
PS: Deswegen würde ich auch nicht exchange2019 als Alias nehmen sondern exchange.domain.de oder mail.domain.de und alles darüber abbilden, intern wie extern. Diese Probleme hast du sonst noch öfter. Der Host kann ja exchange2019 heißen, den Mail-Alias kann man dann gesondert definieren und bei einer Migration getrennt umstellen.
Zitat von @ukulele-7:
zu 1)
Nein. Ein bereits eingerichtetes Outlook Profil sucht nach dem dort hinterlegten Server und wird diesen kontaktieren. Beim DNS ist das ja erstmal kein Problem. Der Exchange weiß auch nicht, welchen DNS Namen du verwendet hast, um Kontakt aufzunehmen. Er wird einfach davon ausgehen, das du die neue URL angefragt hast und liefert auch nur das eine Zertifikat mit aus, egal an wen. Dein Client bekommt dann nicht gesagt "hier ist mein neuer Servername" sondern dein Client merkt, Zertifikat passt nicht zum angefragten Server. Rein aus Sicherheitsaspekten kann der Client ja auch nicht wissen, das der Server jetzt legitim anders heißt sondern er denkt sich "das ist nicht der, den ich wollte".
zu 1)
Nein. Ein bereits eingerichtetes Outlook Profil sucht nach dem dort hinterlegten Server und wird diesen kontaktieren. Beim DNS ist das ja erstmal kein Problem. Der Exchange weiß auch nicht, welchen DNS Namen du verwendet hast, um Kontakt aufzunehmen. Er wird einfach davon ausgehen, das du die neue URL angefragt hast und liefert auch nur das eine Zertifikat mit aus, egal an wen. Dein Client bekommt dann nicht gesagt "hier ist mein neuer Servername" sondern dein Client merkt, Zertifikat passt nicht zum angefragten Server. Rein aus Sicherheitsaspekten kann der Client ja auch nicht wissen, das der Server jetzt legitim anders heißt sondern er denkt sich "das ist nicht der, den ich wollte".
ok, verstanden. Was ist denn, wenn der Exchange von den Clients im LAN über die interne URL gar nicht mehr erreichbar ist - z.B. weil die übers DNS auf eine nicht vergebene IP verweist? Haben die dann die externe URL noch als Fallback drin und versuchen sie es dann darüber?
Ich hinterlege lieber bei jedem Client vorübergehend ne andere Hostdatei (mit dem alten DNS-Namen, der ins Leere führt), als alle Profile neu einzurichten.
Müsste ja nur einmalig klappen, dann würden sie ja über die autodiscover-Funktion vermutlich die aktuellen Updates erhalten und künftig nicht mehr über die alte URL versuchen, oder? Und dann entferne ich die die hosts-Datei wieder.
Moin,
Mal so als Denkanstoß:
Wir lassen den Exchange intern über ein SAN-Zertifikat (smtp.intern.tld, Exchange.intern.tld), ausgestellt von der internen CA laufen.
Da die internen Clients eh alle im AD hängen, kennen die das Zertifikat der CA.
Extern kommen die Jungs-\Mädels nur über eine WAF an den Exchange. Und dort ist das öffentliche Zertifikat eingebunden.
Der Exchange verlängert frühzeitig selbst sein Zertifikat und an der WAR wird es 1x im Jahr ausgetauscht.
Edit:
Auf diese Weise kannst du eine weiche Migration machen:
Erstmal mit einem internen Zertifikat auf
Autodiscover.domain.de
Mail.domain.de
Exchange2019.intern.de
Und wenn alle Clients dann umgestellt sind, könntest du das interne Certifikat auf ein lffentliches (Wildcard) umstellen…
Mal so als Denkanstoß:
Wir lassen den Exchange intern über ein SAN-Zertifikat (smtp.intern.tld, Exchange.intern.tld), ausgestellt von der internen CA laufen.
Da die internen Clients eh alle im AD hängen, kennen die das Zertifikat der CA.
Extern kommen die Jungs-\Mädels nur über eine WAF an den Exchange. Und dort ist das öffentliche Zertifikat eingebunden.
Der Exchange verlängert frühzeitig selbst sein Zertifikat und an der WAR wird es 1x im Jahr ausgetauscht.
Edit:
Auf diese Weise kannst du eine weiche Migration machen:
Erstmal mit einem internen Zertifikat auf
Autodiscover.domain.de
Mail.domain.de
Exchange2019.intern.de
Und wenn alle Clients dann umgestellt sind, könntest du das interne Certifikat auf ein lffentliches (Wildcard) umstellen…
1Zitat von @em-pie:
Edit:
Auf diese Weise kannst du eine weiche Migration machen:
Erstmal mit einem internen Zertifikat auf
Autodiscover.domain.de
Mail.domain.de
Exchange2019.intern.de
Und wenn alle Clients dann umgestellt sind, könntest du das interne Certifikat auf ein lffentliches (Wildcard) umstellen…
Edit:
Auf diese Weise kannst du eine weiche Migration machen:
Erstmal mit einem internen Zertifikat auf
Autodiscover.domain.de
Mail.domain.de
Exchange2019.intern.de
Und wenn alle Clients dann umgestellt sind, könntest du das interne Certifikat auf ein lffentliches (Wildcard) umstellen…
schöne Idee (hilft vielleicht Mitlesern), klappt bei mir aber leider nicht. Die interne CA ist defekt und soll deshalb weg - weil der Server wurde mal migriert und hat dabei den Hostnamen geändert. Offenbar habe ich die Migration der CA damals nicht korrekt gemacht. Was ich dazu gelesen habe als mögliche Fehlerbehebung ist haarsträubend und bekomme ich allein definitiv nicht hin - da müsste man erstmal einen Experten dazuholen.
Zitat von @coltseavers:
ok, verstanden. Was ist denn, wenn der Exchange von den Clients im LAN über die interne URL gar nicht mehr erreichbar ist - z.B. weil die übers DNS auf eine nicht vergebene IP verweist? Haben die dann die externe URL noch als Fallback drin und versuchen sie es dann darüber?
Nein. Outlook hat sein Default-Profil und das hat eine Serveradresse die es anspricht.ok, verstanden. Was ist denn, wenn der Exchange von den Clients im LAN über die interne URL gar nicht mehr erreichbar ist - z.B. weil die übers DNS auf eine nicht vergebene IP verweist? Haben die dann die externe URL noch als Fallback drin und versuchen sie es dann darüber?
Ich hinterlege lieber bei jedem Client vorübergehend ne andere Hostdatei (mit dem alten DNS-Namen, der ins Leere führt), als alle Profile neu einzurichten.
Ja dann geht dein Profil nicht weil dein Mailserver nicht erreichbar ist. In der Folge hast du keine E-Mails....Müsste ja nur einmalig klappen, dann würden sie ja über die autodiscover-Funktion vermutlich die aktuellen Updates erhalten und künftig nicht mehr über die alte URL versuchen, oder?
Nein. Nur weil der gesuchte Mailserver nicht antwortet nimmt er keinen neuen Mailserver und schon gar nicht automatisch. Das wäre auch gar nicht wünschenswert.Die Idee mit dem SAN Zertifikat ist nicht schlecht. I.d.R. kann man glaube ich bis zu drei Hostnamen ins SAN schreiben, technisch geht aber mehr (kostet eventuell mehr). Müssten dann mind. 4 sein, je Autodiscover und je Server-Adresse. Ich habe gute Erfahrungen mit dem Support von PSW Group gemacht, ansonsten frag den Zertifikatsdienstleister deines Vertrauens mal.
Zitat von @ukulele-7:
Zitat von @coltseavers:
ok, verstanden. Was ist denn, wenn der Exchange von den Clients im LAN über die interne URL gar nicht mehr erreichbar ist - z.B. weil die übers DNS auf eine nicht vergebene IP verweist? Haben die dann die externe URL noch als Fallback drin und versuchen sie es dann darüber?
Nein. Outlook hat sein Default-Profil und das hat eine Serveradresse die es anspricht.ok, verstanden. Was ist denn, wenn der Exchange von den Clients im LAN über die interne URL gar nicht mehr erreichbar ist - z.B. weil die übers DNS auf eine nicht vergebene IP verweist? Haben die dann die externe URL noch als Fallback drin und versuchen sie es dann darüber?
Da habe ich die leise Hoffnung, dass Du Dich irrst.
Siehe hier auf Seite 11:
https://www.rf-partners.ch/publikationen/rfpupload.pdf
oder hier:
https://www.itslot.de/2018/12/wie-funktioniert-outlook-einrichtung.html
1)
Wenn Autodiscover scheitert, versucht er dann entweder tatsächlich automatisch über die externe URL zu gehen (weil Maildomain), oder:
2)
vielleicht biege ich Outlook dann temporär in der Registry über "PreferLocalXML" auf die neue XML-Datei um, die ich lokal auf die Clients lege.
Das SAN-Zertifikat habe ich bereits bei PSW geordert
Aber Danke für den Tip!
Outlook macht auf jeden Fall verdammt viel im Hintergrund, am liebsten mit Microsoft 365 Servern Also ich mag mich irren und vielleicht bekommst du es umgebogen. Du solltest das testen und rechne mit ungeahnten Komplikationen, am Ende wirst du eventuell doch neu einrichten. Teste mal so Dinge wie Global Catalog, Einladung anderer Benutzer im Terminplanunsassistenten oder den Abwesenheitsassistenten. Da hatten wir bei der Migration die Probleme, die sind "empfindlich".
Also ich mag mich irren und vielleicht bekommst du es umgebogen. Du solltest das testen und rechne mit ungeahnten Komplikationen, am Ende wirst du eventuell doch neu einrichten. Teste mal so Dinge wie Global Catalog, Einladung anderer Benutzer im Terminplanunsassistenten oder den Abwesenheitsassistenten. Da hatten wir bei der Migration die Probleme, die sind "empfindlich".
Intern / Extern kann getrennt sein, muss aber nicht. Franky's web hat ja überall die gleichen Werte eingetragen.
Extern liegt die Auflösung beim Provider, Intern bei Windows DNS Server. Wenn man nicht alle Kombinationen im Zertifikat haben will hilft nur Split-DNS:
.local.ad-domain - hast du ja.
.de.meine-firma - müsste noch her
https://www.petenetlive.com/KB/Article/0000830
https://www.petenetlive.com/KB/Article/0001184
Durch SRV Eintrag wird dann der hinterlegte Server angefragt.
Gibt noch andere Anleitungen im Netz. Das wäre aber dann das einfachste, zu mal ja dein gekauftes Zertifikat ein Wildcard Zertifikat ist.
Ein SRV Eintrag ist ja kein einfacher Alias. Denke das sollte dann so seinen Zweck erfüllen.
.local.ad-domain - Autodiscover
.de.meine-firma - SRV Eintrag
Extern liegt die Auflösung beim Provider, Intern bei Windows DNS Server. Wenn man nicht alle Kombinationen im Zertifikat haben will hilft nur Split-DNS:
.local.ad-domain - hast du ja.
.de.meine-firma - müsste noch her
https://www.petenetlive.com/KB/Article/0000830
https://www.petenetlive.com/KB/Article/0001184
Durch SRV Eintrag wird dann der hinterlegte Server angefragt.
Gibt noch andere Anleitungen im Netz. Das wäre aber dann das einfachste, zu mal ja dein gekauftes Zertifikat ein Wildcard Zertifikat ist.
Ein SRV Eintrag ist ja kein einfacher Alias. Denke das sollte dann so seinen Zweck erfüllen.
.local.ad-domain - Autodiscover
.de.meine-firma - SRV Eintrag
Hallo nochmal,
kurze Rückmeldung in die Runde:
das Problem ist durch das Installieren des gekauften Zertifikats und der restlichen Anleitung aus FrankysWeb (Umstellung der virtuellen Verzeichnisse, Anpassung der URL des CAS-Dienstes, Ergänzung der DNS-Einträge im Windows-DNS, und Verknüpfung des neuen Zertifikats an die Dienste IIS, SMTP, POP und IMAP) gelöst. Einen Neustart des Exchange-Servers habe ich mir gleich auch noch gegönnt, anstatt nur den IIS neu zu starten.
An den Outlook-Clients habe ich erstmal gar nichts gebastelt und so kamen dann zwei Fehlermeldungen:
1) Es liegt ein Problem mit dem Sicherheitszertifikat des Proxyservers vor. [...] (kann man nur mit OK bestätigen.)
2) Sicherheitshinweis […] Möchten Sie den Vorgang fortsetzen? Habe es mit JA bestätigt.
Anschließend Outlook geschlossen, eine Minute gewartet und den Rechner neu gestartet.
Nun wieder Outlook geöffnet und alles läuft wieder einwandfrei.
Lieben Dank an dieser Stelle an alle Ideengeber und Helfenden!
Gruß
Colt
kurze Rückmeldung in die Runde:
das Problem ist durch das Installieren des gekauften Zertifikats und der restlichen Anleitung aus FrankysWeb (Umstellung der virtuellen Verzeichnisse, Anpassung der URL des CAS-Dienstes, Ergänzung der DNS-Einträge im Windows-DNS, und Verknüpfung des neuen Zertifikats an die Dienste IIS, SMTP, POP und IMAP) gelöst. Einen Neustart des Exchange-Servers habe ich mir gleich auch noch gegönnt, anstatt nur den IIS neu zu starten.
An den Outlook-Clients habe ich erstmal gar nichts gebastelt und so kamen dann zwei Fehlermeldungen:
1) Es liegt ein Problem mit dem Sicherheitszertifikat des Proxyservers vor. [...] (kann man nur mit OK bestätigen.)
2) Sicherheitshinweis […] Möchten Sie den Vorgang fortsetzen? Habe es mit JA bestätigt.
Anschließend Outlook geschlossen, eine Minute gewartet und den Rechner neu gestartet.
Nun wieder Outlook geöffnet und alles läuft wieder einwandfrei.
Lieben Dank an dieser Stelle an alle Ideengeber und Helfenden!
Gruß
Colt
