Hallo zusammen,
habe unseren produktiven Exchange 2019 CU14 versucht zu migrieren auf einen Server 2022 mit Exchange SE. Ging in der Testumgebung gut, hier fiel das auf die Nase, die Clients konnten sich teilweise nicht mehr verbinden und Outlook stürzte ständig ab. Nach der Deinstallation ging zum Glück wieder alles ;).
Jedenfalls ist mir aufgefallen, dass im Event-Log vom Exchange 2019 die im Titel genannten Fehlermeldungen vorhanden sind. Ich stehe aber etwas auf dem Schlauch, das interne Transportzertifikat ist doch im IIS das vom "Exchange Back End"? Das ist jedenfalls noch gültig, es ist is jenes, was bei der Installation von Exchange self signed erstellt wird und fünf Jahre gültig ist. Das einzige abgelaufene Cert auf dem Server ist das alte gekaufte Cert von IMAP, POP und IIS, ich erneuere das seit jeher jährlich und lösche dann das alte.
Bevor ich jetzt anfange wild rumzuprobieren würde ich lieber verstehen, wo das abgelaufene Cert noch dran gebunden ist. Löschen via EAC geht nicht, es hat angeblich noch IMAP und POP als Dienst zugewiesen, die beiden Häkchen dafür lassen sich auch nicht rausnehmen. Im IIS finde ich keine Bindung von diesem Cert. Und bevor ich hier die Brechstange ansetze und es aus dem Cert-Store einfach lösche, sollte ich das Problem vielleicht erst besser verstehen ;). Vielleicht hat ja hier jemand eine Idee dazu.
Bestes Beispiel, dass eine Testumgebung halt auch keine allzweckwaffe ist. ;)
wie genau hast du denn migriert?
Ich stehe aber etwas auf dem Schlauch, das interne Transportzertifikat ist doch im IIS das vom "Exchange Back End"?
Nein, der iis hat genau nichts mit Transport zu tun. ;) und im iis sollte man auch maximal das backend cert tauschen, wenn alle anderen Optionen nicht funktionieren.
ohne weitere Infos wirds aber schwer hier einen vernünftigen Ratschlag zu geben. Du kannst ja mal die Ausgabe vom get-exchangecertificate hier posten. Ggf. Auch mit Info welches Zertifikat bei dir wofür aktuell konfiguriert ist. Dann könnte man weiterschauen.
bye
norbert
Bestes Beispiel, dass eine Testumgebung halt auch keine allzweckwaffe ist. ;)
Du sagst es, aber ich hätte vor dem Versuch mal gründlicher ins Logfile schauen sollen, das war wirklich dämlich.
wie genau hast du denn migriert?
Neuen Server aufgesetzt, Exchange installiert um dann die Postfächer zu migrieren. Ganz klassisch.
ohne weitere Infos wirds aber schwer hier einen vernünftigen Ratschlag zu geben. Du kannst ja mal die Ausgabe vom get-exchangecertificate hier posten. Ggf. Auch mit Info welches Zertifikat bei dir wofür aktuell konfiguriert ist. Dann könnte man weiterschauen.
Das sind die Zertifikate:
Thumbprint Services Subject
---------- -------- -------
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX IP.W... CN=webmail.domain.com
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX IP..... CN=webmail.domain.com -> abgelaufen
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ....S.. CN=Microsoft Exchange Server Auth Certificate
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ...W... CN=HOSTNAME
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ....... CN=WMSvc-SHA2-HOSTNAME
Hier sieht man, dass das abgelaufene noch an IMAP und POP gebunden ist, genau wie das erste, was ja noch gültig ist.
Hier sieht man, dass das abgelaufene noch an IMAP und POP gebunden ist, genau wie das erste, was ja noch gültig ist.
Das ist grundsätzlich erstmal wurscht. Wenn du es nicht explizit gebunden hast, kannst du es normalerweise in der EAC oder per Exchange Powershell löschen. Geht das? Falls nicht, wäre die Fehlermeldung interessant. Im Exchange Backend Virtual Directory ist üblicherweise ein selfsigned cert gebunden, das eine Laufzeit von 5 Jahren hat. Damit macht man nix falsch und das funktioniert normalerweise problemfrei. Das Auth Zertifikat ist speziell und normalerweise nur per set-authconfig konfiguriert. Das WMSVC... ist nix von Exchange sondern von Windows und sollte somit erstmal egal sein.
Das ist grundsätzlich erstmal wurscht. Wenn du es nicht explizit gebunden hast, kannst du es normalerweise in der EAC oder per Exchange Powershell löschen. Geht das? Falls nicht, wäre die Fehlermeldung interessant. Im Exchange Backend Virtual Directory ist üblicherweise ein selfsigned cert gebunden, das eine Laufzeit von 5 Jahren hat. Damit macht man nix falsch und das funktioniert normalerweise problemfrei. Das Auth Zertifikat ist speziell und normalerweise nur per set-authconfig konfiguriert. Das WMSVC... ist nix von Exchange sondern von Windows und sollte somit erstmal egal sein.
Das abgelaufene Cert lässt sich nicht löschen:
"Ein spezieller RPC-Fehler ist auf Server HOSTNAME aufgetreten: Das interne Transportzertifikat kann nicht entfernt
werden, weil dies das Beenden des Microsoft Exchange-Transportdiensts bewirken würde. Erstellen Sie ein neues
Zertifikat, um das interne Transportzertifikat zu ersetzen. Das neue Zertifikat wird automatisch als internes
Transportzertifikat eingesetzt.
Überprüft man, was das interne Transportcert ist, sieht man, dass Eigenartigerweise das abgelaufene gekaufte Cert gebunden ist:
[PS] C:\Windows\system32>Get-Transportservice | Select InternalTransportCertificateThumbprint
InternalTransportCertificateThumbprint
--------------------------------------
THUMBPRINT DES ABGELAUFENEN CERT
Das ist also das Problem, ich habe keine Ahnung, wieso dieses Cert an diesem Service hängt. Die Frage ist, wie ich das jetzt korrekt erneuere.
Na siehst du. Einfach mal die Fehlermeldung komplett posten und schon wird’s logisch.
nimm das hier: CN=HOSTNAME aus deiner Liste.
enable-exchangecertificate thumbprint deines hostname-zerts -Services smtp
die frage ob das das neue standardzertifikat werden soll, beantwortest du in diesem fall mit ja. Sonst üblicherweise immer mit Nein.
