cymode
Goto Top

421 4.4.2 Connection Dropped Due to SocketError

Hi,

Wir haben den SBS 2011 mit Exchange 2010 nun deaktiviert und aus der Domain genommen.
Jetzt gibt es nur noch einen Windows 2019 AD server + einen Windows Server 2019 mit Exchange 2016.

Exchange Dienste vom SBS 2011 waren die letzen Tage bereits deaktiviert. Es hatte alles wunderbar funktioniert daher hatten wir Exchange nun deinstalliert und den Server aus der Domain genommen.

Ist Stand:
Versenden Intern: Geht, kommt aber nicht an
Versenden nach Extern: Geht
Empfangen von Intern: Geht nicht
Empfangen von Extern: Geht nicht

Die Empfangenen E-Mails hängen alle in der Warteschlange auf dem Exchange 2016 server.

screenshot 2020-03-22 at 21.30.58


Hat jemand eine Ahnung was genau das Problem ist?

Soll ich das backup vom SBS 2011 erst mal wieder einspielen?...


Danke
Cymode

Content-ID: 560344

Url: https://administrator.de/contentid/560344

Ausgedruckt am: 05.11.2024 um 18:11 Uhr

cykes
cykes 22.03.2020, aktualisiert am 23.03.2020 um 06:01:26 Uhr
Goto Top
Nabned,

Du solltest mal den FQDN in Deinem Screenshot schwärzen face-wink Stimmt denn dieser und auch die angezeigte interne IP-Adresse 192.168.0.105?
Auf jeden Fall sehen eure MX-Einträge im DNS etwas merkwürdig aus. ddns.net und 2x 1&1/Kundenserver.de. Empfangt ihr die Mails per Pop-Connector (zumindest bisher auf dem SBS)? Solltet vielleicht mal über eine feste IP am Telekom-Anschluss nachdenken und passenden Reverse-DNS-Eintrag.
Ist die Firewall schon passend auf den Connector des Exchange 2016 umgestellt?

Gruß

cykes
cymode
cymode 22.03.2020 aktualisiert um 23:22:33 Uhr
Goto Top
Hi cykes,

der FQDN ist der name vom exchange server, ja. Die IP Stimmt auch mit dem Exchange server überein.

Wir haben eine feste IP Adresse bei der Telekom. Nutzen aber aktuell zum versenden der E-Mails noch ein altes Konto welches früher per Pop3 Connector die E-Mails geholt hat. Das haben wir aktuell so gelöst da unsere versendeten E-Mails sonst aktuell ständig im spam gelandet waren.

An der Firewall hatten wir jetzt nichts geändert. Hatte ja bis vorhin noch alles funktioniert. Wir waren eigentlich der Meinung das der SBS nur noch eine Leiche im Netz war... Dem war aber irgendwie wohl doch nicht. Wir hatten die Firewall auch mal kurzfristig deaktiviert (für 2min), hat aber auch nichts gebracht.

Gruß
Cymode
cymode
cymode 23.03.2020 um 05:02:10 Uhr
Goto Top
Lösung habe ich leider immer noch keine gefunden.
Es ist wohl irgendein DNS Problem, aber ich kann die Ursache nicht finden.
Ich bin der Meinung es ist alles richtig eingestellt. -.-
cykes
cykes 23.03.2020 um 06:23:11 Uhr
Goto Top
Moin,


Zitat von @cymode:
Wir haben eine feste IP Adresse bei der Telekom. Nutzen aber aktuell zum versenden der E-Mails noch ein altes Konto welches früher per Pop3 Connector die E-Mails geholt hat.
Ok, was genau hat es mit diesem "alten Konto" auf sich, ihr verwendet vermutlich einen Smarthost? Bei welchem Provider liegt der Smarthost und stimmt alles bezüglich Port(s), SSL/TLS und der Zertifikate?
Das haben wir aktuell so gelöst da unsere versendeten E-Mails sonst aktuell ständig im spam gelandet waren.
Tja, da fehlt - wie gesagt - der Reverse DNS Eintrag in der Anschluss-Konfiguration. Der muss dann mit der FQDN übereinstimmen, mit der sich der Exchange bei einem HELO/EHLO meldet. Das Zertifikat muss dann entspürechend passen.

Gruß

cykes
Vision2015
Vision2015 23.03.2020 um 07:01:27 Uhr
Goto Top
moin,


Zitat von @cymode:

Hi cykes,

der FQDN ist der name vom exchange server, ja. Die IP Stimmt auch mit dem Exchange server überein.
gut..

Wir haben eine feste IP Adresse bei der Telekom. Nutzen aber aktuell zum versenden der E-Mails noch ein altes Konto welches früher per Pop3 Connector die E-Mails geholt hat. Das haben wir aktuell so gelöst da unsere versendeten E-Mails sonst aktuell ständig im spam gelandet waren.
oha...

An der Firewall hatten wir jetzt nichts geändert. Hatte ja bis vorhin noch alles funktioniert. Wir waren eigentlich der Meinung das der SBS nur noch eine Leiche im Netz war... Dem war aber irgendwie wohl doch nicht. Wir hatten die Firewall auch mal kurzfristig deaktiviert (für 2min), hat aber auch nichts gebracht.
Sende und Empfangsconnector mal überprüft?

Gruß
Cymode
Frank
Vision2015
Vision2015 23.03.2020 um 07:07:26 Uhr
Goto Top
moin...
Zitat von @cykes:

Moin,


Zitat von @cymode:
Wir haben eine feste IP Adresse bei der Telekom. Nutzen aber aktuell zum versenden der E-Mails noch ein altes Konto welches früher per Pop3 Connector die E-Mails geholt hat.
Ok, was genau hat es mit diesem "alten Konto" auf sich, ihr verwendet vermutlich einen Smarthost? Bei welchem Provider liegt der Smarthost und stimmt alles bezüglich Port(s), SSL/TLS und der Zertifikate?
Das haben wir aktuell so gelöst da unsere versendeten E-Mails sonst aktuell ständig im spam gelandet waren.
die eingehenden mails oder die abgehenden mails?
> Tja, da fehlt - wie gesagt - der Reverse DNS Eintrag in der Anschluss-Konfiguration. Der muss dann mit der FQDN übereinstimmen, mit der sich der Exchange bei einem HELO/EHLO meldet. Das Zertifikat muss dann entspürechend passen.
an das Revers DNS dachte ich ich auch als erstes, wenn die mails aber eingehend im spam landen, wird es eher ein Empfangsconnector sein etc sein..


Gruß

cykes
Frank
cykes
cykes 23.03.2020 aktualisiert um 07:33:51 Uhr
Goto Top
Moin,
Das haben wir aktuell so gelöst da unsere versendeten E-Mails sonst aktuell ständig im spam gelandet waren.
die eingehenden mails oder die abgehenden mails?
> Tja, da fehlt - wie gesagt - der Reverse DNS Eintrag in der Anschluss-Konfiguration. Der muss dann mit der FQDN übereinstimmen, mit der sich der Exchange bei einem HELO/EHLO meldet. Das Zertifikat muss dann entspürechend passen.
an das Revers DNS dachte ich ich auch als erstes, wenn die mails aber eingehend im spam landen, wird es eher ein Empfangsconnector sein etc sein..
Naja, aktuell scheint er ja über Smarthost zu versenden. Ich hatte ja die MX-Einträge überprüft als die FQDN noch sichtbar war und da war eben mit höchster Priorität ein ddns Host eingetragen und mit niedrigerer Prio 2x kundenserver.de (Strato) Mailserver.
Wenn er das ordentlich konfigurieren will, sollte er eben:
a) Im Kundenbereich des Anschlusses den Reverse-DNS konfigurieren
b) Beim Hoster in der DNS-Config die MX-Einträge geradeziehen
c) Exchange Connectoren anpassen
d) Ordentliche Zertifikate verwenden

Da das nicht mal eben so schnell umgestellt ist, jetzt die Smarthost-Config überprüfen (insbesonmdere die Auth-Methode), den eventuell weiterhin verwendeten POP-Connector checken.

P.S. Irgendein Mailserver muss den Hut aufhaben, momentan sieht es so aus, als wären das die Starto-Mailserver.
cymode
cymode 23.03.2020 aktualisiert um 09:25:12 Uhr
Goto Top
Moin,

so, status update:


1. Telekom Feste IP ist nun vergeben. Wir hatten 3x eine neue IP Adresse über die letzten 6 Monate bekommen. Jedes Mal meinte die Telekom die wüssten nicht warum da wir ja eine Feste IP gebucht hatten. Jetzt habe ich herausgefunden das man die Feste IP Adresse im Kundencenter "Aktivieren" muss.... warum weiß das nur keiner bei der Telekom? Au mann..

2. PTR Record für mail.xyz.de ist nun hinterlegt. https://www.mail-tester.com/ gibt nun grünes Licht jetzt beim Versenden der Mails an Extern. 9/10 Punkten (kein DKIM gesetzt)

3. DNS Einträge auf unserem webserver (sitzt außerhalb der Domain irgendwo in der Cloud) ist nun die Feste IP Adresse bei Mail.XYZ.de hinterlegt.

3.1 DNS Einträge von 1&1 wurden alle entfernt. Es zeigt nichts mehr zu mx.kundenserver.de. Dort sind seit vielen Tagen keine Mails mehr angekommen (habe mich eben auf die alten Konten via email.ionos.de angemeldet zum prüfen).

4. Pop3 Connector gibt es nicht mehr mit deinstallation vom SBS2011.

5. Empfang von E-Mails geht aber immer noch nicht, weder intern noch extern. In der Warteschlange sind nun knapp 200 e-mails. Montags ist bei uns viel los... -.-

Gruß
cymode
filippg
filippg 24.03.2020 um 23:29:41 Uhr
Goto Top
Hi,

ich verstehe die Richtung der Diskussion nicht (MX, POP3-Connector, ...).

Wenn ich das richtig sehe, dann
a) klappt Versand von ein internes an ein anderes internes Postfach nicht
b) Zeigt der Screenshot den Queue-Viewer auf dem Exchange 2016, und dort dass es eine Queue zu Mailbox Delivery gibt.
Richtig?

Dann hat doch MX etc damit überhaupt nichts zu tun... Die Verbindung sollte rein lokal auf dem Server erfolgen, zwischen Transport Service und Mailbox Transport Service (oder zwischen Mailbox Transport und Database? hm...). Sämtliche auftretenden IPs sollten nur die des Exchange selbst sein.
Problematisch nur: an der Stelle kann man nicht all zu viel konfigurieren (also eigentlich auch nicht all zu viel falsch machen ;) ). Der genutzte Send-Connector ist ein impliziter -> gar nicht konfigurierbar. Der benutzte Receive-Connector ist m.W. auch nur implizit und nicht konfigurierbar.
Ich würde als best Guess auf irgendein ominöses "Sicherheitsprodukt" tippen, dass den Server besonders sicher machen soll (ist er ja auch: aktuell werden sicher keine Schadmails zugestellt).

Wie sieht's aus mit IPv4 vs v6? ist v4 aktiviert, IP an (richtige) Netzwerkkarte gebunden?

Grüße

Filipp
Vision2015
Lösung Vision2015 25.03.2020 um 05:52:28 Uhr
Goto Top
moin...
Zitat von @filippg:

Hi,

ich verstehe die Richtung der Diskussion nicht (MX, POP3-Connector, ...).
richtig....

Wenn ich das richtig sehe, dann
a) klappt Versand von ein internes an ein anderes internes Postfach nicht
ja... so wars
b) Zeigt der Screenshot den Queue-Viewer auf dem Exchange 2016, und dort dass es eine Queue zu Mailbox Delivery gibt.
Richtig?
jo... zeigt er.

Dann hat doch MX etc damit überhaupt nichts zu tun...
nicht direkt.... der MX war aber auch nicht richtig
Die Verbindung sollte rein lokal auf dem Server erfolgen, zwischen Transport Service und Mailbox Transport Service (oder zwischen Mailbox Transport und Database? hm...). Sämtliche auftretenden IPs sollten nur die des Exchange selbst sein.
so sollte es sein!
Problematisch nur: an der Stelle kann man nicht all zu viel konfigurieren (also eigentlich auch nicht all zu viel falsch machen ;) ). Der genutzte Send-Connector ist ein impliziter -> gar nicht konfigurierbar. Der benutzte Receive-Connector ist m.W. auch nur implizit und nicht konfigurierbar.
Ich würde als best Guess auf irgendein ominöses "Sicherheitsprodukt" tippen, dass den Server besonders sicher machen soll (ist er ja auch: aktuell werden sicher keine Schadmails zugestellt).
ja, war etwas buggy, aber es war offensichtlich kein "Sicherheitsprodukt" installiert, alle connectoren wurden gelöscht etc.
eher war es eine SBS Migration mit leichen vom exchange 2003, das in die hose gegangen ist.... kann passieren! aber nix, was nicht zu löten ist face-smile

Wie sieht's aus mit IPv4 vs v6? ist v4 aktiviert, IP an (richtige) Netzwerkkarte gebunden?
ja, war er..
letztlich habe ich mit dem TO fix einen neuen Exchange 2016 installiert, vorher ein ordentliches zertifikat besorgt & DNS und Reverse Mapping richtig eingerichtet, postfächer verschoben, und gut ist face-smile
also alles nur kleinikeiten...

Grüße

Filipp
Frank
cykes
cykes 25.03.2020 um 07:01:25 Uhr
Goto Top
Zitat von @Vision2015:
[...] aber nix, was nicht zu löten ist face-smile
Wie jetzt - keine Kabelbinder benutzt? face-smile
ja, war er..
letztlich habe ich mit dem TO fix einen neuen Exchange 2016 installiert, vorher ein ordentliches zertifikat besorgt & DNS und Reverse Mapping richtig eingerichtet, postfächer verschoben, und gut ist face-smile
also alles nur kleinikeiten...
Gut, dass Du ihn kurz unterstützen konntest.

Gruß

cykes
cymode
cymode 26.03.2020 um 13:04:14 Uhr
Goto Top
Problem ist Gelöst face-smile

Frank hat mir echt viel weitergeholfen. Ich hätte schwören können das jeden Moment die Aussage kommen würde "sorry, da ist zu viel Zeug was der Grund für den Fehler sein könnte, nimm ein Streichholz, Zünde alles an und fang neu an". haha. Frank hat aber durchgebissen und einfach weiter gemacht bis es wieder Lief. Einfach Hammer!

Den "Grund" vom Problem konnten wir nicht ganz herausfinden. Könnte Leichen aus Exchange 2003 gewesen sein, Exchange 2010 Problem oder eventuell auch Rechte durch Fehlerhafte AD-Exchange Integration. Wir werden es wohl nie ganz genau Wissen. Die Telekom hatte mich darauf hingewiesen das wir zwar seit Jahren für eine Feste IP-Adresse bezahlen, diese aber nie "aktiviert" hätten. Das habe ich natürlich dann mit der Dame am Telefon gemacht, und zack hatten wir eine neue IP-Adresse bekommen nachdem gerade die ganzen MX Einträge gemacht wurden auf die alte.... Das wusste die am Telefon leider nicht das es einen IP Adressenbereich gibt der nur für feste IPs ist, und die Webseite der Telekom gibt diese Warnung leider auch nicht. Das hatte dann auch noch zu einem MX Chaos geführt. Zusätzlich hat Frank noch ein paar weitere kleinere Sachen gefunden die entweder falsch, oder nicht ideal Eingestellt waren welche ebenso das Problem verstärken konnten.

Was aber am Ende die Lösung gebracht hatte (zusammen mit verschiedenen Optimierungen & Verbesserungen) war einen neuen Server aufzusetzen, dort Exchange installieren, die Datenbanken rüber und dann ging es auch am Ende. Das hört sich jetzt natürlich einfacher an als es war.

Learning Points:
Wenn ich es alles noch mal machen müsste....
2) Don't ever do this on a Sunday evening....... Dafür ist Freitag 17:00 gedacht.
3) Nicht gleich 10 Sachen Zeitgleich. Der Exchange 2010 hätte auch noch länger leben dürfen, auch wenn er "nicht verwendet wird". Ebenso muss der SBS nicht gleich nach der Exchange Deinstallation aus der Domain entfernt werden. Hat doch alles seine Zeit. 2-3 Tage warten hätte viele Fehlerquellen ausschließen können und eventuell wäre das alles gar nicht erst passiert.

An sich ist die goldene Regel: Do it slowly, do it right - und wenn dann etwas nicht geht, sind die möglichen Fehlerquellen begrenzt und man muss nicht erst Stunden suchen.

Ein Mega Dank auf jeden Fall an den Frank und an die anderen welche Ratschläge gegeben hatten 👍🏻.

Gruß
Cymode
Vision2015
Vision2015 26.03.2020 um 13:21:09 Uhr
Goto Top
Moin...

gerne, hat Spass gemacht, und war ein netter Zeitvertreib face-smile
und du darfst dich bei Bedarf gerne weiter (kostenlos)melden!

Frank