13
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 560344
Url: https://administrator.de/forum/421-4-4-2-connection-dropped-due-to-socketerror-560344.html
Ausgedruckt am: 26.12.2024 um 09:12 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
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
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
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. -.-
Es ist wohl irgendein DNS Problem, aber ich kann die Ursache nicht finden.
Ich bin der Meinung es ist alles richtig eingestellt. -.-
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.
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
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
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
Problem ist Gelöst
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
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
1
Moin...
gerne, hat Spass gemacht, und war ein netter Zeitvertreib
und du darfst dich bei Bedarf gerne weiter (kostenlos)melden!
Frank
gerne, hat Spass gemacht, und war ein netter Zeitvertreib
und du darfst dich bei Bedarf gerne weiter (kostenlos)melden!
Frank
1
