nidavellir
Goto Top

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

Content-Key: 717667383

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

Ausgedruckt am: 19.03.2024 um 05:03 Uhr

Mitglied: Vision2015
Vision2015 17.06.2021 um 18:14:11 Uhr
Goto Top
moin....

so aus der hüfte.... Windows Firewall port 443 nicht offen...

Frank
Mitglied: Vision2015
Vision2015 17.06.2021 um 18:28:01 Uhr
Goto Top
Moin....
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 OK
- 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
ok

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
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.
prima

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 face-smile 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
Mitglied: em-pie
Lösung em-pie 17.06.2021 um 18:35:34 Uhr
Goto Top
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?
Mitglied: Vision2015
Vision2015 17.06.2021 um 18:39:33 Uhr
Goto Top
wenn er nach anleitung gegangen ist, sollte die zone drin sein...


Frank
Mitglied: yumper
Lösung yumper 18.06.2021 um 01:19:11 Uhr
Goto Top
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
Mitglied: Nidavellir
Lösung Nidavellir 18.06.2021 aktualisiert um 10:39:21 Uhr
Goto Top
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.

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).

zone

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.
auto

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.
Mitglied: Vision2015
Vision2015 18.06.2021 um 11:16:12 Uhr
Goto Top
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
Mitglied: yumper
yumper 18.06.2021 aktualisiert um 13:06:27 Uhr
Goto Top
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
Mitglied: yumper
yumper 18.06.2021 um 13:09:47 Uhr
Goto Top
Vision

er kann neue DNS Zonen anlegen wie er will - Den Exchange Server kann er nicht verschieben.

so long

Yumper
Mitglied: Vision2015
Vision2015 18.06.2021 um 15:07:54 Uhr
Goto Top
Moin...
@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
Mitglied: Vision2015
Vision2015 18.06.2021 um 15:29:33 Uhr
Goto Top
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!
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 face-smile

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
Mitglied: Nidavellir
Nidavellir 18.06.2021 um 15:58:04 Uhr
Goto Top
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.

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
Mitglied: Nidavellir
Lösung Nidavellir 18.06.2021 aktualisiert um 16:04:13 Uhr
Goto Top
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 ...
Mitglied: Vision2015
Lösung Vision2015 18.06.2021 um 16:03:22 Uhr
Goto Top
Zitat von @Nidavellir:

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.

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
Mitglied: Vision2015
Vision2015 18.06.2021 um 16:04:48 Uhr
Goto Top
das ist nicht dein problem....
Mitglied: Nidavellir
Nidavellir 18.06.2021 um 16:06:11 Uhr
Goto Top
Bitte richte Split DNS ein, das wird so nix!
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 face-smile
Die Portweiterleitung habe ich immer nur kurz für meine Tests deaktiviert.

Grüße
Nidavellir
Mitglied: Nidavellir
Lösung Nidavellir 25.06.2021 um 14:30:42 Uhr
Goto Top
So, Ende der Woche, Ende des Problems. face-wink
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!