17
Migration Exchange 2013 zu 2019, nach Änderung Port-Weiterleitung keine Verbindung mehr
Hallo zusammen,
wir haben noch einen Exchange 2013 im Einsatz, welcher durch die 2019er Version abgelöst werden soll.
Infos zum Umfeld:
- Mailabruf erfolgt per POPcon, Mailversand direkt per SMTP (an dem Thema soll derzeit nichts geändert werden)
- OWA ist per https://sub.domain.de/owa intern und extern erreichbar
- der Ex2013 ist auf CU23 und aktuell gepatcht
Den Exchange 2019 habe ich auf einem neuen Windows Server 2019 installiert und die weitere Einrichtung nach dem HowTo von "Frankys Web" [1] vorgenommen.
Abweichend zu seinem Umfeld existiert bei mir nur ein DNS-Eintrag auf den Server, der Eintrag "autodiscover" existiert bei mir nicht.
Mit seinem Skript habe ich die virtuellen Verzeichnisse vom alten Exchange 2013 auf den Exchange 2019 übernommen.
Sendeconnector habe ich eingetragen und erfolgreich getestet, auch wenn nur der neue Exchange "darf".
Ich habe ein vorhandenes Test-Mailkonto vom Ex2013 zum Ex2019 migriert und kann damit einwandfrei arbeiten. OWA steht für diesen User auch mit dem 2019er Funktionsumfang zur Verfügung.
Dann noch den DNS-Eintrag auf die IP des Ex2019 geändert. Läuft alles.
Sobald ich aber die Port-Weiterleitung im Router umstelle (Ziel: die IP des neuen Ex2019, Port 443), geht nichts mehr.
OWA geht nicht mehr ("Fehler: Netzwerk-Zeitüberschreitung") und auch Outlook kann auf den Exchange nicht mehr zugreifen, es kommt keine Verbindung zustande.
Ich weiß gerade nicht wo ich ansetzen soll. Was soll ich prüfen, was sind typische Fehler?
Ich habe nicht viel Erfahrung mit dem Exchange. Vermute aber die Ursache in den virt. Verzeichnissen.
[1] https://www.frankysweb.de/migration-exchange-2016-zu-exchange-2019/
Viele Grüße
Nidavellir
wir haben noch einen Exchange 2013 im Einsatz, welcher durch die 2019er Version abgelöst werden soll.
Infos zum Umfeld:
- Mailabruf erfolgt per POPcon, Mailversand direkt per SMTP (an dem Thema soll derzeit nichts geändert werden)
- OWA ist per https://sub.domain.de/owa intern und extern erreichbar
- der Ex2013 ist auf CU23 und aktuell gepatcht
Den Exchange 2019 habe ich auf einem neuen Windows Server 2019 installiert und die weitere Einrichtung nach dem HowTo von "Frankys Web" [1] vorgenommen.
Abweichend zu seinem Umfeld existiert bei mir nur ein DNS-Eintrag auf den Server, der Eintrag "autodiscover" existiert bei mir nicht.
Mit seinem Skript habe ich die virtuellen Verzeichnisse vom alten Exchange 2013 auf den Exchange 2019 übernommen.
Sendeconnector habe ich eingetragen und erfolgreich getestet, auch wenn nur der neue Exchange "darf".
Ich habe ein vorhandenes Test-Mailkonto vom Ex2013 zum Ex2019 migriert und kann damit einwandfrei arbeiten. OWA steht für diesen User auch mit dem 2019er Funktionsumfang zur Verfügung.
Dann noch den DNS-Eintrag auf die IP des Ex2019 geändert. Läuft alles.
Sobald ich aber die Port-Weiterleitung im Router umstelle (Ziel: die IP des neuen Ex2019, Port 443), geht nichts mehr.
OWA geht nicht mehr ("Fehler: Netzwerk-Zeitüberschreitung") und auch Outlook kann auf den Exchange nicht mehr zugreifen, es kommt keine Verbindung zustande.
Ich weiß gerade nicht wo ich ansetzen soll. Was soll ich prüfen, was sind typische Fehler?
Ich habe nicht viel Erfahrung mit dem Exchange. Vermute aber die Ursache in den virt. Verzeichnissen.
[1] https://www.frankysweb.de/migration-exchange-2016-zu-exchange-2019/
Viele Grüße
Nidavellir
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: 717667383
Url: https://administrator.de/contentid/717667383
Ausgedruckt am: 25.11.2024 um 21:11 Uhr
17 Kommentare
Neuester Kommentar
moin....
so aus der hüfte.... Windows Firewall port 443 nicht offen...
Frank
so aus der hüfte.... Windows Firewall port 443 nicht offen...
Frank
Moin....
Den Exchange 2019 habe ich auf einem neuen Windows Server 2019 installiert und die weitere Einrichtung nach dem HowTo von "Frankys Web" [1] vorgenommen.
ok
Sobald ich aber die Port-Weiterleitung im Router umstelle (Ziel: die IP des neuen Ex2019, Port 443), geht nichts mehr.
OWA geht nicht mehr ("Fehler: Netzwerk-Zeitüberschreitung") und auch Outlook kann auf den Exchange nicht mehr zugreifen, es kommt keine Verbindung zustande.
ich vermute die Firewall.... port 443 dicht! l
Ich weiß gerade nicht wo ich ansetzen soll. Was soll ich prüfen, was sind typische Fehler?
die Firewall 
und Zertifikat!
Frank
Zitat von @Nidavellir:
Hallo zusammen,
wir haben noch einen Exchange 2013 im Einsatz, welcher durch die 2019er Version abgelöst werden soll.
Infos zum Umfeld:
- Mailabruf erfolgt per POPcon, Mailversand direkt per SMTP (an dem Thema soll derzeit nichts geändert werden)
das ist voll OKHallo zusammen,
wir haben noch einen Exchange 2013 im Einsatz, welcher durch die 2019er Version abgelöst werden soll.
Infos zum Umfeld:
- Mailabruf erfolgt per POPcon, Mailversand direkt per SMTP (an dem Thema soll derzeit nichts geändert werden)
- OWA ist per https://sub.domain.de/owa intern und extern erreichbar
der 2019er braucht aber nur ein https://sub.domain.de...- der Ex2013 ist auf CU23 und aktuell gepatcht
okDen Exchange 2019 habe ich auf einem neuen Windows Server 2019 installiert und die weitere Einrichtung nach dem HowTo von "Frankys Web" [1] vorgenommen.
Abweichend zu seinem Umfeld existiert bei mir nur ein DNS-Eintrag auf den Server, der Eintrag "autodiscover" existiert bei mir nicht.
dann leg es doch an...Mit seinem Skript habe ich die virtuellen Verzeichnisse vom alten Exchange 2013 auf den Exchange 2019 übernommen.
na ja... hätte ich jetzt nicht gemacht, aber ok! besser firsch selber anlegen, der gute Franky hat dafür auch scripte...Sendeconnector habe ich eingetragen und erfolgreich getestet, auch wenn nur der neue Exchange "darf".
Ich habe ein vorhandenes Test-Mailkonto vom Ex2013 zum Ex2019 migriert und kann damit einwandfrei arbeiten. OWA steht für diesen User auch mit dem 2019er Funktionsumfang zur Verfügung.
Dann noch den DNS-Eintrag auf die IP des Ex2019 geändert. Läuft alles.
primaIch habe ein vorhandenes Test-Mailkonto vom Ex2013 zum Ex2019 migriert und kann damit einwandfrei arbeiten. OWA steht für diesen User auch mit dem 2019er Funktionsumfang zur Verfügung.
Dann noch den DNS-Eintrag auf die IP des Ex2019 geändert. Läuft alles.
Sobald ich aber die Port-Weiterleitung im Router umstelle (Ziel: die IP des neuen Ex2019, Port 443), geht nichts mehr.
OWA geht nicht mehr ("Fehler: Netzwerk-Zeitüberschreitung") und auch Outlook kann auf den Exchange nicht mehr zugreifen, es kommt keine Verbindung zustande.
Ich weiß gerade nicht wo ich ansetzen soll. Was soll ich prüfen, was sind typische Fehler?
und Zertifikat!Ich habe nicht viel Erfahrung mit dem Exchange. Vermute aber die Ursache in den virt. Verzeichnissen.
nööööö, da bin ich noch nicht bei dir!Frank
1
Moin,
was mich wundert ist, dass auch die interne Kommunikation über euren (zentralen) Router läuft.
Richtet doch am DNS eine neue Zone für sub.domain.de ein.
Dann ist zumindest die interne Kommunikation prüfbar.
Stimmen zudem die Zertifikate?
was mich wundert ist, dass auch die interne Kommunikation über euren (zentralen) Router läuft.
Richtet doch am DNS eine neue Zone für sub.domain.de ein.
Dann ist zumindest die interne Kommunikation prüfbar.
Stimmen zudem die Zertifikate?
wenn er nach anleitung gegangen ist, sollte die zone drin sein...
Frank
Frank
Hallo
welchen DNS Eintrag hast du denn geändert? - MX record muss doch nicht geändert werden.
Ohne Autodiscover Eintrag im internen und externen DNS kann zumindest Outlook nicht darauf zugreifen
Hast du gültige HTTPS Zertifikate ?
so long
Yumper
welchen DNS Eintrag hast du denn geändert? - MX record muss doch nicht geändert werden.
Ohne Autodiscover Eintrag im internen und externen DNS kann zumindest Outlook nicht darauf zugreifen
Hast du gültige HTTPS Zertifikate ?
so long
Yumper
Hi,
danke schon mal für eure Beteiligung!
Ich habe testweise die Windows-Firewall am Ex2019 deaktiviert und die Portweiterleitung wieder auf diesen geändert. Keine Verbindung, keine Änderung zu vorher.
Ja, unsere Domäne ist domain.local
Den oben genannten DNS-Eintrag habe ich im DNS-Manager unter Forward-Lookupzonen >> domain.local angelegt.
Wenn ich jetzt die Portweiterleitung deaktiviere, sollten die Clients auf den Ex2019 verwiesen werden, auch wenn der von extern nicht erreichbar ist. Der Aufruf von sub.domain.de sollte dann von intern auch auf das OWA kommen. Korrekt?
Führe ich bei einem Test-Client "E-Mail-AutoKonfiguration testen" aus, erhalte ich folgendes Ergebnis. Sieht aus meiner Sicht korrekt aus.
danke schon mal für eure Beteiligung!
Ich habe testweise die Windows-Firewall am Ex2019 deaktiviert und die Portweiterleitung wieder auf diesen geändert. Keine Verbindung, keine Änderung zu vorher.
welchen DNS Eintrag hast du denn geändert? - MX record muss doch nicht geändert werden.
Bisher hat POPcon die Mails an ex2013.domain.local übergeben. Das habe ich nun geändert zu exchange.domain.local und einen DNS-Eintrag angelegt, der auf die IP des ex2019 zeigt. Damit habe ich getestet ob POPcon (egal auf welchem Exchange es läuft) sauber Mails zustellen kann, egal in welcher DB/auf welchem Exchange das Postfach liegt.Ja, unsere Domäne ist domain.local
Den oben genannten DNS-Eintrag habe ich im DNS-Manager unter Forward-Lookupzonen >> domain.local angelegt.
was mich wundert ist, dass auch die interne Kommunikation über euren (zentralen) Router läuft.
Richtet doch am DNS eine neue Zone für sub.domain.de ein.
Dann ist zumindest die interne Kommunikation prüfbar.
Ich habe jetzt eine Zone sub.domain.de angelegt (AD-integriert, Replikation auf alle DNS-Server dieser Domäne) und dort einen DNS-Eintrag der auf die IP des Ex2019 zeigt (Name = identisch mit übergeordnetem Ordner).Richtet doch am DNS eine neue Zone für sub.domain.de ein.
Dann ist zumindest die interne Kommunikation prüfbar.
Wenn ich jetzt die Portweiterleitung deaktiviere, sollten die Clients auf den Ex2019 verwiesen werden, auch wenn der von extern nicht erreichbar ist. Der Aufruf von sub.domain.de sollte dann von intern auch auf das OWA kommen. Korrekt?
Ohne Autodiscover Eintrag im internen und externen DNS kann zumindest Outlook nicht darauf zugreifen
So einen Eintrag gab es bisher nicht. Funktioniert mit dem alten Ex2013 dennoch.Führe ich bei einem Test-Client "E-Mail-AutoKonfiguration testen" aus, erhalte ich folgendes Ergebnis. Sieht aus meiner Sicht korrekt aus.
Hast du gültige HTTPS Zertifikate ?
Zertifikate wurden gemäß Anleitung vom alten Ex2013 übernommen und funktionieren auch. Lediglich im Firefox die Meldung, da es selbst ausgestellte Zertifikate sind.
Moin...
du sollst eine NEUE Zone anlegen!
wenn du magst, schreib mir ne PM, und wir Telen eben... dann mach ich dir das eben remote
Frank
du sollst eine NEUE Zone anlegen!
wenn du magst, schreib mir ne PM, und wir Telen eben... dann mach ich dir das eben remote
Frank
Hallo
ich gehe einmal davon aus das Gateway ist der Router auf dem Router ist DNS ausgeschaltet und DNS ist der DC.
bei dem A Record musst du schon den Namen angeben
Exch2019 A Record 192.x.x.x
Den legt Exchange allerdings bei der Installation an.
Das du die alten Zertifikate verwendest geht auch nicht, da beide Exchange Server einen unterschiedlichen Namen haben.
Schau doch auf dem neuen Exchange zuerst mit https://localhost/owa ob den eine Anzeige kommt.
Danach https://exch2019 und auch https://exch2019.domain.local - Schau auf welchen Namen das Zertifikat ausgestellt ist.
Der Unterschied zu 2013 ist das es keine Mapi- sondern nur noch SMTP Verbindungen gibt. Deshalb auch autodiscover.
Von aussen muss der Server wegen popcon nicht erreichbar sein so das das autodiscover Testtool auch nur error 401 ausgeben kann. Trotzdem benötigst du einen autodiscover Eintrag in deiner lokalen DNS Zone
so long
Yumper
ich gehe einmal davon aus das Gateway ist der Router auf dem Router ist DNS ausgeschaltet und DNS ist der DC.
bei dem A Record musst du schon den Namen angeben
Exch2019 A Record 192.x.x.x
Den legt Exchange allerdings bei der Installation an.
Das du die alten Zertifikate verwendest geht auch nicht, da beide Exchange Server einen unterschiedlichen Namen haben.
Schau doch auf dem neuen Exchange zuerst mit https://localhost/owa ob den eine Anzeige kommt.
Danach https://exch2019 und auch https://exch2019.domain.local - Schau auf welchen Namen das Zertifikat ausgestellt ist.
Der Unterschied zu 2013 ist das es keine Mapi- sondern nur noch SMTP Verbindungen gibt. Deshalb auch autodiscover.
Von aussen muss der Server wegen popcon nicht erreichbar sein so das das autodiscover Testtool auch nur error 401 ausgeben kann. Trotzdem benötigst du einen autodiscover Eintrag in deiner lokalen DNS Zone
so long
Yumper
Vision
er kann neue DNS Zonen anlegen wie er will - Den Exchange Server kann er nicht verschieben.
so long
Yumper
er kann neue DNS Zonen anlegen wie er will - Den Exchange Server kann er nicht verschieben.
so long
Yumper
Moin...
@yumper vor 1 Stunde
so long
Yumper
Frank
@yumper vor 1 Stunde
er kann neue DNS Zonen anlegen wie er will - Den Exchange Server kann er nicht verschieben.
warum sollte er auch?so long
Yumper
Frank
Hallo
ich gehe einmal davon aus das Gateway ist der Router auf dem Router ist DNS ausgeschaltet und DNS ist der DC.
sollte so sein!bei dem A Record musst du schon den Namen angeben
Exch2019 A Record 192.x.x.x
Den legt Exchange allerdings bei der Installation an.
ja... er braucht einen Split-DNS, deswegen eine neue Zone. exchange.domaine .de, mit er intern wie extern auflösen kann!Exch2019 A Record 192.x.x.x
Den legt Exchange allerdings bei der Installation an.
ist doch simpel.....
Das du die alten Zertifikate verwendest geht auch nicht, da beide Exchange Server einen unterschiedlichen Namen haben.
was... das ist blödsinn, da hast du ne wissenslücke!natürlich kann er das Öffentliche Zertifikat nutzen, so lange es gültig ist!
es geht ja um IIS, SMTP, IMAP und POP- natürlich auch for EWS / OWA etc.... und nicht um den hostnamen!
und du kannst ja, intern und extern das gleiche zertifikat nutzen..... macht es einfacher
Der Unterschied zu 2013 ist das es keine Mapi- sondern nur noch SMTP Verbindungen gibt. Deshalb auch autodiscover.
falsch... MAPI über HTTP ist standardmäßig aktiviert bei einer Migration von 2016 auf 2019!on aussen muss der Server wegen popcon nicht erreichbar sein so das das autodiscover Testtool auch nur error 401 ausgeben kann. Trotzdem benötigst du einen autodiscover Eintrag in deiner lokalen DNS Zone
warumn soll er von aussen nicht erreichbar sein... was ist mit OWA? was du meinst ist SMTP!so long
Yumper
So, ich habe weiter getestet und komme voran, denke ich. ;)
Für die folgenden Test habe ich die Portweiterleitung deaktiviert.
Client im internen Netz:
- Outlook stellt Verbindung mit dem Exchange her
- OWA ist erreichbar
Client im Homeoffice, VPN Tunnel im TAP-Modus:
- Exchange und OWA nicht erreichbar
- setze ich einen Eintrag in die HOSTS-Datei (192.168.1.x sub.domain.de) kann ich auf beides zugreifen
- auskommentiert > kein Zugriff
ich gehe einmal davon aus das Gateway ist der Router auf dem Router ist DNS ausgeschaltet und DNS ist der DC.
Absolut korrekt. Manche Sachen sind leider zu selbstverständlich für einen selbst, das man es vergisst aufzuzählen.Schau doch auf dem neuen Exchange zuerst mit https://localhost/owa ob den eine Anzeige kommt.
Danach https://exch2019 und auch https://exch2019.domain.local - Schau auf welchen Namen das Zertifikat ausgestellt ist.
Alles erfolgreich. Zertifikat ist auf sub.domain.de ausgestellt.Danach https://exch2019 und auch https://exch2019.domain.local - Schau auf welchen Namen das Zertifikat ausgestellt ist.
Das du die alten Zertifikate verwendest geht auch nicht, da beide Exchange Server einen unterschiedlichen Namen haben.
Das wird sowohl in der Anleitung von frankysweb (siehe ganz oben), als auch im Artikel "Migration zu Exchange 2019" aus der Administrator Ausgabe 2019-04 so beschrieben. Ja, die Server haben unterschiedliche Hostnamen. Angesprochen werden sie doch aber über sub.domain.de und das ist im Zertifikat gelistet.Trotzdem benötigst du einen autodiscover Eintrag in deiner lokalen DNS Zone
Das habe ich jetzt im Zweig domain.local angelegt, zeigt auf die IP des Ex2019.Für die folgenden Test habe ich die Portweiterleitung deaktiviert.
Client im internen Netz:
- Outlook stellt Verbindung mit dem Exchange her
- OWA ist erreichbar
Client im Homeoffice, VPN Tunnel im TAP-Modus:
- Exchange und OWA nicht erreichbar
- setze ich einen Eintrag in die HOSTS-Datei (192.168.1.x sub.domain.de) kann ich auf beides zugreifen
- auskommentiert > kein Zugriff
falsch... MAPI über HTTP ist standardmäßig aktiviert bei einer Migration von 2016 auf 2019!
Ich migriere von 2013 zu 2019. Laut [1] ist bei "Upgrading from an environment that contains any Exchange 2013 servers" mit Exchange 2019 "MAPI over HTTP is disabled by default".Ich habe in der Hinsicht nichts angepasst.
Unsere Outlook Clients sind übrigens durchgängig 2019er Versionen.
[1] https://docs.microsoft.com/en-us/Exchange/clients/mapi-over-http/mapi-ov ...
Zu:
ja... er braucht einen Split-DNS, deswegen eine neue Zone. exchange.domaine .de, mit er intern wie extern auflösen kann!
Hier lese ich grad noch im Whitepaper zu Autodiscover von frankysweb.https://www.frankysweb.de/exchange-2016-umfangreiches-whitepaper-zu-auto ...
Zitat von @Nidavellir:
So, ich habe weiter getestet und komme voran, denke ich. ;)
So, ich habe weiter getestet und komme voran, denke ich. ;)
ich gehe einmal davon aus das Gateway ist der Router auf dem Router ist DNS ausgeschaltet und DNS ist der DC.
Absolut korrekt. Manche Sachen sind leider zu selbstverständlich für einen selbst, das man es vergisst aufzuzählen.Schau doch auf dem neuen Exchange zuerst mit https://localhost/owa ob den eine Anzeige kommt.
Danach https://exch2019 und auch https://exch2019.domain.local - Schau auf welchen Namen das Zertifikat ausgestellt ist.
Alles erfolgreich. Zertifikat ist auf sub.domain.de ausgestellt.Danach https://exch2019 und auch https://exch2019.domain.local - Schau auf welchen Namen das Zertifikat ausgestellt ist.
Das du die alten Zertifikate verwendest geht auch nicht, da beide Exchange Server einen unterschiedlichen Namen haben.
Das wird sowohl in der Anleitung von frankysweb (siehe ganz oben), als auch im Artikel "Migration zu Exchange 2019" aus der Administrator Ausgabe 2019-04 so beschrieben. Ja, die Server haben unterschiedliche Hostnamen. Angesprochen werden sie doch aber über sub.domain.de und das ist im Zertifikat gelistet.Trotzdem benötigst du einen autodiscover Eintrag in deiner lokalen DNS Zone
Das habe ich jetzt im Zweig domain.local angelegt, zeigt auf die IP des Ex2019.Für die folgenden Test habe ich die Portweiterleitung deaktiviert.
Client im internen Netz:
- Outlook stellt Verbindung mit dem Exchange her
- OWA ist erreichbar
Client im Homeoffice, VPN Tunnel im TAP-Modus:
- Exchange und OWA nicht erreichbar
- setze ich einen Eintrag in die HOSTS-Datei (192.168.1.x sub.domain.de) kann ich auf beides zugreifen
- auskommentiert > kein Zugriff
Bitte richte Split DNS ein, das wird so nix!
und mach die Portweiterleitung an... so wie es war°!
das ist echt nur ne Minutensache...
Frank
das ist nicht dein problem....
Bitte richte Split DNS ein, das wird so nix!
und mach die Portweiterleitung an... so wie es war°!
das ist echt nur ne Minutensache...
und mach die Portweiterleitung an... so wie es war°!
das ist echt nur ne Minutensache...
Wie in meiner letzten Antwort in einem anderen Zweig geschrieben, lese ich mich gerade zu Split DNS ein. Danke
Die Portweiterleitung habe ich immer nur kurz für meine Tests deaktiviert.
Grüße
Nidavellir
So, Ende der Woche, Ende des Problems. 
Danke für eure Unterstützung!
Mir hat bei der ganzen Geschichte folgendes die Tour vermasselt.
Wir haben zwei Internetanschlüsse (DSL und Kabel), aber noch keinen ordentlichen Router der die Last verteilt. Um dennoch beide Leitungen zu nutzen, bekommen DHCP-Clients als Standardgateway die Fritzbox die am Kabelmodem hängt. Server und zentrale VMs haben vom alten Dienstleister feste IP-Adressen und als Standardgateway die DSL-Fritte bekommen. Ich bin aber kein Freund von festen IP-Adressen, sondern bevorzuge DHCP-Reservierungen. Die Maschinen haben dennoch ihr "feste" IP, aber es ist übersichtlicher wenn kaum Doku vorhanden ist...
Das hatte zum Ergebnis, das die Exchange2019-VM als Gateway die Kabel-Fritzbox bekommen hat, eingehender Traffic aber über die DSL-Fritzbox (Telekom, feste IP, Portweiterleitung) rein kam. Die alte Exchange2013-VM hatte eine feste IP und die DSL-Fritzbox als Gateway.
Das hab ich Mittwoch Abend endlich gecheckt und korrigiert. Dann lief auch alles mit den neuen DNS-Zonen autodiscover.domain.de und sub.domain.de - yeah. :D
Ich habe mich gegen eine domain.de Zone entschieden, da ich sonst für alle Sub-Domains Einträge hätte anlegen müssen - das wären über 50 Stück gewesen.
Auflösung funktioniert jetzt auf jeden Fall sauber und ich migriere - im Schneckentempo - die Postfächer.
Danke und ein schönes Wochenende!
Danke für eure Unterstützung!
Mir hat bei der ganzen Geschichte folgendes die Tour vermasselt.
Wir haben zwei Internetanschlüsse (DSL und Kabel), aber noch keinen ordentlichen Router der die Last verteilt. Um dennoch beide Leitungen zu nutzen, bekommen DHCP-Clients als Standardgateway die Fritzbox die am Kabelmodem hängt. Server und zentrale VMs haben vom alten Dienstleister feste IP-Adressen und als Standardgateway die DSL-Fritte bekommen. Ich bin aber kein Freund von festen IP-Adressen, sondern bevorzuge DHCP-Reservierungen. Die Maschinen haben dennoch ihr "feste" IP, aber es ist übersichtlicher wenn kaum Doku vorhanden ist...
Das hatte zum Ergebnis, das die Exchange2019-VM als Gateway die Kabel-Fritzbox bekommen hat, eingehender Traffic aber über die DSL-Fritzbox (Telekom, feste IP, Portweiterleitung) rein kam. Die alte Exchange2013-VM hatte eine feste IP und die DSL-Fritzbox als Gateway.
Das hab ich Mittwoch Abend endlich gecheckt und korrigiert. Dann lief auch alles mit den neuen DNS-Zonen autodiscover.domain.de und sub.domain.de - yeah. :D
Ich habe mich gegen eine domain.de Zone entschieden, da ich sonst für alle Sub-Domains Einträge hätte anlegen müssen - das wären über 50 Stück gewesen.
Auflösung funktioniert jetzt auf jeden Fall sauber und ich migriere - im Schneckentempo - die Postfächer.
Danke und ein schönes Wochenende!
