Hallo zusammen,
ich habe mal wieder ein Problem. Wahrscheinlich ist die Lösung einfach und ich sehe nur den Wald vor lauter Bäumen nicht.
Es gibt einen Exchange 2019 auf einem Server der extern gehostet wird (Glaube bei Hetzner.). Der soll nicht mehr bei Hetzner sein, sondern dort wo auch der Rest der AD ist. Soweit so einfach.
Server 2022 aufgesetzt, Exchange 2019 installiert, Virtuelle Verzeichnisse konfiguriert, usw. User-Postfächer vom Hetzner-Exchange (auch 2019, auch in der AD) per Migrationsbatch auf den neuen Exchange 201 migriert, alles problemlos.
Der (einzige) Sendconnector ist irgendein Smarthost ohne Authentifizierung. Keiner weiß mehr genau, was das für ein Smarthost ist, keiner hat mehr irgendwelche Zugänge dafür.
Auf dem neuen Exchange 2019 habe ich ein neues Wildcard-Zertifikat hinterlegt, auch an die Empfangs- und den Sendeconnector gebunden und den Diensten SMTP und IIS zugewiesen.
Die Queue des neuen Exchange 2019 ist voll, gehen keine E-Mails raus. (Im Sendconnector habe ich den neuen Exchange-Server aber als "erlaubten Sender" eingetragen.)
Meine Vermutung ist, dass es Probleme bereitet, dass der neue Exchange 2019 - Server ein anderes Zertfikat hat als der alte. Oder bin ich auf dem Holzweg?
Ich würde jetzt das neue Wildcard-Zertifikat auch auf dem alten Exchange-Server hinterlegen und im Zweifel einfach einen neuen Sendconnector ohne Smathost anlegen.
Hat jemand noch nen heißen Tipp?
Versuch doch erstmal per Telnet zum Smarthost zu kommen. Kann ja sein, dass der dich gar nicht ran lässt.
Das probiere ich morgen gerne mal aus.
Dann müsste der Smarthost aber definitiv weg, bzw. ersetzt werden.
Dazu kennt hier niemand außer dir deine Umgebung, um darauf eine sinnvolle Antwort zu geben.
- entweder schauen, ob man den Smarthost-Betreiber erreicht und das klären kann.
- anderen Smarthost organisieren
- selbst senden, wenn die Voraussetzungen (static ip) und die notwendige Konfiguration machbar ist.
bye
norbert
Damit hast Du recht.
Die Voraussetzungen für erstmal selber senden sind da. Für die Übergangszeit, in der der alte Exchange-Server noch aktiv ist, müssen dann nur beide Öffentlichen IPs in den SPF. Der Server bei Hetzner hat natürlich eine andere, als der "interne".
Ja, die sollte dann zusätzlich in den spf rein. Reverse DNS sollte ggf. auch passend konfiguriert sein.
Du hattest natürlich so recht. Der Smarthost lässt nur den alten Server ran.
Also habe ich auf selber senden umgestellt, Reverse DNS und SPF angepasst alles funktioniert.
Der alte Server hat jetzt auch das neue Wildcard-Zertifikat. An die Empfangskonnektoren gebunden. Jetzt können die E-Mails senden, aber keine mehr empfangen, der Absender bekommt keine Unzustellbarkeitsmeldung oder ähnliches. :D Als Spam-Filter istr Antispamcloud dazwischen.
Ich weiß aber nicht, wo ich da falsch abgebogen sein könnte, um das "Empfangen" lahmgelegt zu haben. Folgendes habe ich gemacht:
- SPF-Record auf die beiden WAN-IPs angepasst. Mit so nem Online-E-Mail-Reputations-Check-Dings geprüft, Ergebnis: 9 von 10 Punkten (Weil kein DKIM.)
- SSL-Zertifikat, wie gesagt, auch auf dem alten Server importiert, in IIS hinterlegt (IIS neu gestartet.) und an die Empfangskonnektoren des alten Servers gebunden (An die Empfangskonnekoren des neuen Servers habe ich das Zertifikat schon gestern gebunden.)
Mehr war es nicht. Der MX zeigt nach wie vor auf Antispamcloud (In Antispamcloud habe ich nichts geändert.)
SSL-Zertifikat, wie gesagt, auch auf dem alten Server importiert, in IIS hinterlegt (IIS neu gestartet.)
Was genau hast du im iis gemacht? Da sollte man mit Zertifikaten maximal das backend Zertifikat zuweisen und das ist normalerweise nicht dasselbe Zertifikat wie für die frontend Seite. Hat aber nix mit dem Empfang zu tun. Wenn keine Mails ankommen, schau nach warum. Der Spam Anbieter sollte ja entsprechende Mails in der queue haben oder zumindest im logfile was ausspucken. Meine Vermutung:
durch den Austausch des Zertifikats hast du die explizite Bindung im empfangsconnector geändert und deswegen wird kein tls mehr angeboten. Oder der ehlo Name stimmt nicht mehr.
wird vermutlich irgendwas in der Richtung sein.
bye
norbert
@norbertfe Na ja, wenn ich ein neues Zertifikat importiere, ist es nicht automatisch dem Front End bei der 443 - Bindung zugewiesen. Das habe ich gemacht und dann den IIS-Dienst neu gestartet.
Ich habe jetzt das alte Zertifikat wieder importiert, gebunden, usw. Also alles rückgängig gemacht, empfängt immer noch nicht.
Na ja, wenn ich ein neues Zertifikat importiere, ist es nicht automatisch dem Front End bei der 443 - Bindung zugewiesen. Das habe ich gemacht und dann den IIS-Dienst neu gestartet.
Das erledigt man aber _nicht_ im IIS, sondern per
enable-exchangecertificate deincertthumbprint -services IIS
Ich habe jetzt das alte Zertifikat wieder importiert, gebunden, usw. Also alles rückgängig gemacht, empfängt immer noch nicht.
Na dann hast du einfach Pech. Oder war "schau in die diversen Logfiles" nicht aussagekräftig genug? ;) Ohne Fehlermeldung wirds halt schwer dir was zu raten.
Bye
Norbert
Das erledigt man aber _nicht_ im IIS, sondern per
enable-exchangecertificate deincertthumbprint -services IIS
Welchen Vorteil hat es, das per Powershell zu machen?
Ich komme leider (noch) nicht an die Logfiles von Antispamcloud. Ich wühle mich da gerne durch, sobald ich die habe.
Mittlerweile sieht man in der Queue des alten Servers, dass er die E-Mails zwar annimmt, aber nicht an die Postfächer, die bereits in die Datenbank des neuen Servers migriert wurden, zustellen kann.
Welchen Vorteil hat es, das per Powershell zu machen?
Du kannst es auch im EAC erledigen, aber _nicht_ im IIS. Das hat den Vorteil, dass das was der Exchange konfiguriert im Zweifel die IIS Konfiguration überschreibt.
Mittlerweile sieht man in der Queue des alten Servers, dass er die E-Mails zwar annimmt, aber nicht an die Postfächer, die bereits in die Datenbank des neuen Servers migriert wurden, zustellen kann.
Und da sollte man doch dann sehen, über welchen Connector die zum Exchange (neu) gesendet werden sollen und dann könnte man (vorausgesetzt man hat es aktiviert) auch im Logfile nachschauen, warum das nicht funktioniert.
Bye
Norbert
Du kannst es auch im EAC erledigen, aber _nicht_ im IIS. Das hat den Vorteil, dass das was der Exchange konfiguriert im Zweifel die IIS Konfiguration überschreibt.
O.K., verstanden und abgespeichert.Und da sollte man doch dann sehen, über welchen Connector die zum Exchange (neu) gesendet werden sollen und dann könnte man (vorausgesetzt man hat es aktiviert) auch im Logfile nachschauen, warum das nicht funktioniert.
Das müsste ja dann entweder der Empfangskonnektor auf Port 25 oder der Empfangskonnektor auf Port 587 sein.
Ich sehe gerade, dass das cmdlet: Enable-ExchangeCertificate -Thumbprint meinthumbprint -Services POP,IMAP,IIS,SMTP (Ja, ich sehe auch gerade, dass ich dem IIS das Zertifikat mit diesem Befehl zuweise. :) ) nicht vollständig funktioniert hat. Das Zertifikat ist nicht zuständig für "smtp", das wird vermutlich das Problem sein. Ich bekomme es aber auch nicht für smtp zugewiesen. Weder per EAC, noch wie gesagt per Exchange Management Shell. (Habe dsbzgl. das Forum durchgesucht. Zertifikat löschen und neu importieren hat nichts gebracht.)
Ich sehe gerade, dass das cmdlet: Enable-ExchangeCertificate -Thumbprint CA60DA60125AE47CEF026B54CD66E539FA3E2B5D -Services POP,IMAP,IIS,SMTP (Ja, ich sehe auch gerade, dass ich dem IIS das Zertifikat mit diesem Befehl zuweise. :) ) nicht vollständig funktioniert hat. Das Zertifikat ist nicht zuständig für "smtp", das wird vermutlich das Problem sein.
Dann hast du das Zertifikat mal importiert, OHNE dafür die Exchange Powershell zu nutzen. Exportiere dir das Zertifikat mit private Key, lösche es aus dem Zertifikatsspeicher (entweder direkt in der MMC oder per remove-exchangecertificate) und importiere es hinterher wieder per Exchange Powershell https://learn.microsoft.com/en-us/powershell/module/exchange/import-exchangecertificate?view=exchange-ps
Wie genau hast du es denn importiert, wenn du es schonmal gelöscht hast?
Abgesehen davon siehst du grad auch die Nachteile von wildcard Zertifikaten. Da muss man den ganzen Kram immer mehr berücksichtigen, als hätte man einfach nur ein Zertifikat mit den für Exchange notwendigen Namen.
Das müsste ja dann entweder der Empfangskonnektor auf Port 25 oder der Empfangskonnektor auf Port 587 sein.
Du sollst in den Sendeconnector auf dem ALTEN Server schauen. Aber wenn du schon im Empfangsconnector am neuen Server schauen willst, dann ist es immer auf Port 25 also sehr wahrscheinlich der Default Frontend Connector. Es sei denn, du hast dir einen eigenen Connector gebastelt. Mit welcher Fehlermeldung stehen die Mails denn in der Queue? Laß dir doch nicht alles einzeln aus der Nase ziehen.
Bye
Norbert
@norbertfe Ich habe auf beiden Servern das Zertifikat per Exchange Management Shell neu importiert (Vorher über die MMC gelöscht.). Das Zuweisen an die Dienste IIS und SMTP hat jetzt auf beiden Servern funktioniert.
Auf beiden Servern habe ich das Zertifkat an die Empfangskonnektoren gebunden. Beim neuen auch an den Sendeconnector. Beim Versuch, das Zertifikat vom alten Server aus an den Sendeconnector zur binden, bekomme ich den Fehler "Error 0x6ba (Der RPC-Server ist nicht verfügbar)", was ja eher auf Replikationsprobleme hindeutet.
Die Fehlermeldung aus der Warteschlange des alten Servers habe ich als jpg angehängt.
Die Fehlermeldung stünde übrigens auch im SMTP Sendelog ;) Aber am ENde bedeutet das nur, dass dein alter Exchange nicht zum neuen verbinden kann. Mach doch mal einfach ein Telnet auf Port 25 zum neuen Exchange. Geht das?
was ja eher auf Replikationsprobleme hindeutet.
Wo genau sollen da denn bitte Replikationsprobleme auftreten? Oder nimmst du einfach den ersten Google Hit bei Eingabe des Fehlercodes?
Schau erstmal was Telnet sagt, danach kann man weitersehen. Im Zweifel wärs vermutlich schneller und billiger gewesen, du hättest dir jemanden geholt, der sowas schon häufiger gemacht hat, oder ist das egal, dass da jetzt seit Tagen die Mails nicht korrekt laufen?
Bye
Norbert
Die Fehlermeldung stünde übrigens auch im SMTP Sendelog ;) Aber am ENde bedeutet das nur, dass dein alter Exchange nicht zum neuen verbinden kann. Mach doch mal einfach ein Telnet auf Port 25 zum neuen Exchange. Geht das?
Im Endeffekt war das das Problem. Wie gesagt, "steht" der alte Server räumlich woanders. Ich bin nicht direkt darauf gekommen, weil die Firewall im Netz des neuen Servers zwar den Ping durchgelassen hat, DNS auch funktionierte aber Port 25 nicht erlaubt war.
Wo genau sollen da denn bitte Replikationsprobleme auftreten? Oder nimmst du einfach den ersten Google Hit bei Eingabe des Fehlercodes?
Ich hatte nicht erwähnt das in dem Netz des ALTEN Servers auch ein DC steht. Da auch dieser DC "nur" per VPN mit dem übrigen Netz verbunden ist, sich aber im gleichen Netz wie der alte Server befindet, vermutete ich in Verbindung mit dem RPC-Fehler, dass es ggfs. auch ein Replikationsproblem sein KÖNNTE.
Im Zweifel wärs vermutlich schneller und billiger gewesen, du hättest dir jemanden geholt, der sowas schon häufiger gemacht hat, oder ist das egal, dass da jetzt seit Tagen die Mails nicht korrekt laufen?
Ich verstehe ja, dass es Dich wahrscheinlich nervt, dass hier im Forum ständig ähnlich bescheuerte Fragen, wie die meine, gestellt werden. Wenn mich so etwas nerven würde, wäre meine erste Überlegung, ob ich denn diese bescheuerten Fragesteller überhaupt an meinem unermesslichen Wissen teilhaben lassen möchte und ob so ein Forum der richtige Ort ist, wo ich meine Zeit verplempern möchte.
Wahrscheinlicher ist allerdings, dass ich mir, so ich denn helfen möchte, solche Bemerkungen einfach spare und mich daran erfreue, einen Exchange-Interessierten wieder ein bisschen schlauer gemacht zu haben. :)
Ich habe mal in meinen Unterlagen geschaut, ich habe 11 (Ist nicht besonders viel, ich weiß.) Exchange-on-prem zu Exchange-on-prem - Migrationen gemacht (On-prem zu O365 alleine in den letzten 1,5 Jahren doppelt so viele, wobei die aber auch echt einfacher sind.). Teilweise waren die Netzwerk-/VPN-Konstrukte da noch viel komplzierter, nur eben ohne einen geblockten Port 25 oder ähnliche Probleme. Ich habe das also noch keine 47000 mal gemacht so wie Du vermutlich und manchmal fehlt, so wie diesesmal, einfach der gedankliche Schubs in die richtige Richtung. Dafür sei Dir herzlich und ehrlich gedankt. :)
Alle deine Probleme basierten also auf ganz banalen blockierten Ports die für den Mailtransfer notwendig sind (SMTP). Und auch nach dem Hinweis einfach mal in die Logs zu schauen um dann wieder mit den selben Problemen anzukommen ist eben schon etwas strange. Da du ja jetzt wieder ein "ein bisschen schlauer gemachter Exchange-Interessierter" bist, hats doch geholfen. Wo ist dein Problem?
Freue mich für dich über deine 12 Migration. ;)
Schönes Wochenende
Norbert
Natürlich frage ich bei den Vorbesprechungen mit den Kunden die Gegebenheiten ab und sage, was erforderlich ist (Z.B. ungehinderte Kommunikation der Server, usw.). Ich lerne daraus, dass ich mich nicht unbedingt auf alle Informationen des Kunden verlassen kann (Sicherlich keine Absicht des Kunden.) und als Verbesserungsvorschlag für mich selbst z.B. eine entsprechende Checkliste o.ä. erstelle, die dann dann vorher abgearbeitet wird.
Ich habe kein Problem. Hab Dir nur mal meine, teilweise auch selbstkritischen, Gedanken dazu mitgeteilt und mich doch dann im Endeffekt auch angemessen für Deine Unterstützung bedankt.
Die auch ein schönes Wochenende. :)
P.S.: Danke für die Glückwünsche.