Part 1 of the article series "Migration from Exchange 2016 to Exchange 2019" only described the test environment and the installation of Exchange 2019. Now the more interesting steps follow. This part now deals with the configuration of Exchange 2019 for co-existence with Exchange 2016.
The aim of this article is to have a functional Exchange 2019 server, which will later replace the Exchange 2016 server. The certificate and also the URLs (e.g. OWA) should be retained. Users should therefore not have to remember a new URL for OWA. Existing applications that interact with Exchange should also not be affected by the migration (assuming compatibility).
Exchange 2019 configuration
The first configuration I make on a new Exchange Server is to rename and move the database to its destination. This is done quickly using the Exchange Management Shell:
Get-MailboxDatabase -Server Exchange2019 | Set-MailboxDatabase -Name DB2019 Move-DatabasePath DB2019 -EdbFilePath d:\DB2019\DB2019.edb -LogFolderPath d:\DB2019
So that Exchange 2019 can also deliver mails to the Internet, the new server must be entered as the source server for the send connector:
Only the Exchange 2019 server needs to be added here. If there are other send connectors, the new server must also be entered here:
Next up are the URLs for the various virtual directories.
To avoid having to configure each of the Exchange URLs manually, the following small script can be used. Only the first two lines need to be adapted and the respective host names of Exchange 2016 and Exchange 2019 entered. The script then reads the URLs from the Exchange 2016 configuration and configures the same settings for Exchange 2019:
$Exchange2019Server = "Exchange2019" $Exchange2016Server = "Exchange16" #Get URLs from Exchange 2016 Server $autodiscoverhostname = (Get-ClientAccessService $Exchange2016Server).AutoDiscoverServiceInternalUri $owainturl = (Get-OwaVirtualDirectory -Server $Exchange2016Server).internalurl $owaexturl = (Get-OwaVirtualDirectory -Server $Exchange2016Server).externalurl $ecpinturl = (Get-EcpVirtualDirectory -server $Exchange2016Server).internalurl $ecpexturl = (Get-EcpVirtualDirectory -server $Exchange2016Server).externalurl $ewsinturl = (Get-WebServicesVirtualDirectory -Server $Exchange2016Server).internalurl $ewsexturl = (Get-WebServicesVirtualDirectory -Server $Exchange2016Server).externalurl $easinturl = (Get-ActiveSyncVirtualDirectory -Server $Exchange2016Server).internalurl $easexturl = (Get-ActiveSyncVirtualDirectory -Server $Exchange2016Server).externalurl $oabinturl = (Get-OabVirtualDirectory -server $Exchange2016Server).internalurl $oabexturl = (Get-OabVirtualDirectory -server $Exchange2016Server).externalurl $mapiinturl = (Get-MapiVirtualDirectory -server $Exchange2016Server).internalurl $mapiexturl = (Get-MapiVirtualDirectory -server $Exchange2016Server).externalurl $OutlAnyInt = (Get-OutlookAnywhere -Server $Exchange2016Server).internalhostname $OutlAnyExt = (Get-OutlookAnywhere -Server $Exchange2016Server).externalhostname #Configure Exchange 2019 Server Get-OwaVirtualDirectory -Server $Exchange2019Server | Set-OwaVirtualDirectory -internalurl $owainturl -externalurl $owaexturl -Confirm:$false Get-EcpVirtualDirectory -server $Exchange2019Server | Set-EcpVirtualDirectory -internalurl $ecpinturl -externalurl $ecpexturl -Confirm:$false Get-WebServicesVirtualDirectory -server $Exchange2019Server | Set-WebServicesVirtualDirectory -internalurl $ewsinturl -externalurl $ewsexturl -Confirm:$false Get-ActiveSyncVirtualDirectory -Server $Exchange2019Server | Set-ActiveSyncVirtualDirectory -internalurl $easinturl -externalurl $easexturl -Confirm:$false Get-OabVirtualDirectory -Server $Exchange2019Server | Set-OabVirtualDirectory -internalurl $oabinturl -externalurl $oabexturl -Confirm:$false Get-MapiVirtualDirectory -Server $Exchange2019Server | Set-MapiVirtualDirectory -externalurl $mapiexturl -internalurl $mapiinturl -Confirm:$false Get-OutlookAnywhere -Server $Exchange2019Server | Set-OutlookAnywhere -externalhostname $OutlAnyExt -internalhostname $OutlAnyInt -ExternalClientsRequireSsl:$true -InternalClientsRequireSsl:$true -ExternalClientAuthenticationMethod 'Negotiate' -Confirm:$false Get-ClientAccessService $Exchange2019Server | Set-ClientAccessService -AutoDiscoverServiceInternalUri $autodiscoverhostname -Confirm:$false #Display setttings Get-OwaVirtualDirectory | fl server,externalurl,internalurl Get-EcpVirtualDirectory | fl server,externalurl,internalurl Get-WebServicesVirtualDirectory | fl server,externalurl,internalurl Get-ActiveSyncVirtualDirectory | fl server,externalurl,internalurl Get-OabVirtualDirectory | fl server,externalurl,internalurl Get-MapiVirtualDirectory | fl server,externalurl,internalurl Get-OutlookAnywhere | fl servername,ExternalHostname,InternalHostname Get-ClientAccessService | fl name,AutoDiscoverServiceInternalUri
The configured URLs are listed at the end and should be checked once. Both servers must have the same URLs:
That is actually all there is to it.
To be on the safe side, however, you should go through the complete Exchange 2016 configuration and configure Exchange 2019 accordingly. For example, settings for the receive and send connectors (relay settings, throttling, message size)
The database settings are also important; the limits should also be adjusted here. It would not be nice if, for example, 10 GB was set as the maximum for mailboxes on the Exchange 2016 server, but only 2 GB on Exchange 2019. When data is later transferred from Exchange 2016 to Exchange 2016, a 5 GB mailbox would be over the limit and Exchange would prohibit sending and receiving.
Take over certificate
Once Exchange 2019 has been configured, the certificate can be transferred. To do this, the certificate must first be exported from the Exchange 2016 server:
The certificate is now saved directly on the Exchange 2019 server. At this point, you can of course also specify any other share that can be reached from both servers. Password and path are required again for the import:
The previously exported certificate can now be imported to the Exchange 2019 server:
The path and password of the exported certificate must be entered here:
In the last step of the dialog, the Exchange 2019 server on which the certificate is to be installed is specified:
After the certificate has been installed, the Exchange services must be bound to the certificate:
Exchange 2019 is now able to work as a proxy for Exchange 2016. It is now a good idea to carry out a few tests by editing the hosts file of a client. In this example, I would now adjust the hosts file on a client and let outlook.frankysweblab.de point to the IP of the Exchange 2019 server. If the first tests were successful, the DNS and firewall can be changed.
Change DNS and firewall
The IP address for the entries "outlook.frankysweblab.de" and autodiscover.frankysweblab.de" must now be changed on the internal DNS server. Currently, both entries point to the IP of the Exchange 2016 server:
The IP of the two Host-A entries is now changed to the IP of the Exchange 2019 server. In this case 192.168.200.18:
To ensure that external clients are also referred to Exchange 2019, the NAT entry still needs to be adjusted; it currently points to Exchange 2016:
The port forward only needs to be changed to Exchange 2019 at this point:
Following these changes, Exchange 2019 is now a CAS proxy for Exchange 2016. The users' mailboxes are currently still hosted on Exchange 2016. The migration of the data is part of the next article, which will follow shortly.
At this point, it is recommended to go through the DNS entries: Other DNS entries, such as CNAMES and SRV records (Autodiscover) should also point to Exchange 2019. In many environments, CNAMES have been configured to the hostname of the (old) Exchange server (for example, for SMTP traffic from other devices/applications). Devices such as printers / scanners should also be checked once, experience has shown that the IP is often used here instead of an FQDN.
In dieser Konstellation kann jetzt Exchange 2019 erst einmal parallel zu Exchange 2016 laufen. Wenn sich keine Probleme ergeben, kann mit der Datenmigration weiter gemacht werden. Sollten doch Probleme auftreten, können mit wenig Aufwand die DNS- und NAT Einstellungen rückgängig gemacht werden.
Data migration is part of the next article.
Hallo ich bekomme beim Senden einer E-Mail folgendes Problem:
Die Nachrichtenzustellung dauert etwas länger als erwartet.
Die Installion von exchanger-server 2019 war ohne Probleme.
Auch der export und import vom Zertifikat ging.
im Zustellbericht wird die Mail an exchangeserver2016 übermittelt,
danach wurde die nachricht
durch exchange 2019 von exchange 2016 empfangen
die nachricht befindet sich auf exchane 2019
und es kommt die meldung:
Fehler: ‚[{LED=};{MSG=};{FQDN=};{IP=};{LRT=}]‘
Nach einer Zeit gibt der exchange 2019 auf die e-mail zu versenden.
Wie kann ich vom Client aus erkennt, ob er sich mit dem neuen Server verbunden hat?
DNS und alles ist umgestellt. Im Verbindungsstatus steht unter Version aber weiterhin 15.1, für einen EX 2019 müsste aber 15.2 sein.
Daran hat auch die Migration meines Postfaches nichts geändert.
Der neue Server wurde automatisch in die bestehende Umgebung mit hinzugefügt, das hat zur folge das Outlook nicht mehr startet
Es erscheint die Meldung in Outlook-. Ordnergruppe kann nicht geöffnet werden, Informationsspeicher steht nicht zur Verfügung
ich habe folgendes Problem: Server 2019 installiert, Exchange 2019 auf dem Server installiert, Wenn ich jetzt das Admin Center öffne sehe ich beide Server, ich kann mich via Powershell aber nicht am neuen Server anmelden
Hallo!
Ich bin gerade im Schritt „Serverzertifikat Exportieren (2016) und neu importieren auf dem 2019“
Leider sehe ich bei mir keine Möglichkeit das Zerti zu exportieren.
Die 3 Punkte habe ich nicht… Gibts eine andere Möglichkeit?
Gruß Sascha
Hallo Sascha,
etwas spät, aber vielleicht dennoch hilfreich.
Die drei Punkte sind seit einem Update nicht mehr da…
Von daher musst Du den Export über die Management Shell ausführen.
export-exchangecertificate ist hierfür der Befehl.
Zuvor kannst Du Dir am 2016er mit get-exchangecertificate deine Zertifikate anzeigen lassen. Kopier dann das Thumbprint des aktiven und für IIS und SMTP aktiven Zertifikats. das brauchst Du beim Export.
Dann Exportieren in eine Datei als Binary und mit import-exchangecertificate wieder am neuen importieren.
LG
Hallo und vielen Dank für die klasse Anleitung. Ich bin gerade am Ende von Teil 2 an dem folgenden Punkt.
In dieser Konstellation kann jetzt Exchange 2019 erst einmal parallel zu Exchange 2016 laufen. Wenn sich keine Probleme ergeben, kann mit der Datenmigration weiter gemacht werden. Sollten doch Probleme auftreten, können mit wenig Aufwand die DNS- und NAT Einstellungen rückgängig gemacht werden.
E-Mails können versendet und empfangen werden. Allerdings bekomme ich beim Versand an externe Empfänger folgende Fehlermeldungen.
Remote Server returned ‚441 4.4.1 Error encountered while communicating with primary target IP address: „421 4.4.2 Connection dropped due to SocketError.“ Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts. The last endpoint attempted was „interne IP der Sophos UTM“
Ihre Nachricht konnte nicht zugestellt werden, und es wurde kein gültiger, erweiterter Statuscode vom Remote-E-Mail-System ausgestellt, um die genaue Ursache zu ermitteln. Status: „Relay not permitted“.
Die folgende Organisation hat Ihre Nachricht abgelehnt: URL vom Mail Gateway
Einige Nachrichten werden versendet und einige nicht. Manchmal klappt es auch beim wiederholten Senden. Ist der Fehler am Exchange zu suchen oder auf der UTM?
Viele Grüße
Moin Thomas,
ich hatte das gleiche Problem. Ursache war die Sophos Firewall, wo in den Relay Setting noch der neue Exchangeserver als Versender hinzugefügt werden muss.
Das es mal funktioniert und mal nicht liegt daran, dass er mal den alten (noch erlaubten) Server zum versenden nutzt und mal den neuen (noch geblockten).
Hoffe das hilft.
Hallo Jannik,
das scheint es gewesen zu sein. Tausend Dank!
Viele Grüße
Thomas
Ich habe mit einem Testclient versucht, wieder auf Outlook zuzugreifen. Das mißlingt mit der nichtssagenden Meldung „…Fehler bei der Anmeldung“. Ein Versuch, das Mailprofil neu einzurichten endet mit (sinngemäß) „Fehler bei Exchange ActiveSync (EAS) Server nicht gefunden“. Beim Versuch über den neuen Exchange-Server auf die ActiveSync Webseite zuzugreifen, bekomme ich nach Anmeldung einen 501 Fehler (Seite nicht gefunden). Danach habe ich über die ECP das virtuelle Verzeichnis resetet und die URL’s neu gesetzt – gleiches Ergebnis. Ein „Test-Activesyncconnectivity“ meldet ein Fehler:
„Die zugrunde liegende Verbindung wurde geschlossen: Für den geschützten SSL/TLS-Kanal konnte keine Vertrauensstellung hergestellt werden.. Interner Fehler [System.AuthenticationException]Security.Authentication.: Das Remotezertifikatist laut Validierungsverfahren ungültig.“
Das Zeretifikat ist das aus dem EX2016 exportierte mit mit dem Certifikatsassistent erstellte Let’s Encrypt Zertifikat. Ich habe daraufhin das Zertifikat mittels Assistent neu erstellen lassen und das alte gelöscht. Gleicher Fehler. Immer noch hat der Ex2019 offenbar ein Problem mit der Acrivesync Webseite und mein Outlook verbindet sich nicht. Jetzt weiß ich nicht weiter. Hat jemand ein Tipp für mich?
Eine Frage habe ich doch noch. Das Split-DNS ist optional und nicht muss? Zumindest wenn Full-Nat an der UTM konfiguriert wird?!
Der für uns wichtige Test, sind die neuen Client Zugriffsregeln, mit den es möglich sein soll, den Zugriff auf das Admin Center einzuschränken und nicht wie empfohlen, auf mindestens 2 Exchange Server zu setzen.
Top! Danke! Das Problem mit bzgl. Scan2mail wird oft vergessen. Es ist gut, darauf hinzuweisen.