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.
Hat jemand eine Ahnung was genau das Problem ist?
Soll ich das backup vom SBS 2011 erst mal wieder einspielen?...
Danke
Cymode
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.
Hat jemand eine Ahnung was genau das Problem ist?
Soll ich das backup vom SBS 2011 erst mal wieder einspielen?...
Danke
Cymode
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 560344
Url: https://administrator.de/contentid/560344
Ausgedruckt am: 05.11.2024 um 18:11 Uhr
13 Kommentare
Neuester Kommentar
Nabned,
Du solltest mal den FQDN in Deinem Screenshot schwärzen 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
Du solltest mal den FQDN in Deinem Screenshot schwärzen 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
Moin,
Gruß
cykes
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?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.
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
moin,
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
Zitat von @cymode:
Hi cykes,
der FQDN ist der name vom exchange server, ja. Die IP Stimmt auch mit dem Exchange server überein.
gut..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
moin...
Gruß
cykes
Frank
Zitat von @cykes:
Moin,
die eingehenden mails oder die abgehenden mails?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.
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.
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
Moin,
die eingehenden mails oder die abgehenden mails?
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.
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.
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..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.
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
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
moin...
richtig....
Wenn ich das richtig sehe, dann
a) klappt Versand von ein internes an ein anderes internes Postfach nicht
ja... so wars
Dann hat doch MX etc damit überhaupt nichts zu tun...
nicht direkt.... der MX war aber auch nicht richtig
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
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
also alles nur kleinikeiten...
Grüße
Filipp
Frank
richtig....
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?
jo... zeigt er.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.
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.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).
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
Wie sieht's aus mit IPv4 vs v6? ist v4 aktiviert, IP an (richtige) Netzwerkkarte gebunden?
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
also alles nur kleinikeiten...
Grüße
Filipp
Wie jetzt - keine Kabelbinder benutzt?
Gruß
cykes
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
also alles nur kleinikeiten...
Gut, dass Du ihn kurz unterstützen konntest.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
also alles nur kleinikeiten...
Gruß
cykes