Dieser Artikel soll eine kurze Übersicht darüber geben, was bei einer Mail-Migration alles zu beachten ist. Es geht hier nicht unbedingt um die Migration von Exchange zu Exchange, sondern um Migrationen im allgemeinen die als Zielsystem einen Exchange Server haben. Für eine vollständige Auflistung übernehme ich allerdings keinerlei Gewähr ;-).
Zuerst einmal ein paar Stichpunkte:
– Namespaces
– Zertifikate
– Autodiscover
– DNS-Einträge (MX-Records, Autodiscover)
– Anlegen der neuen Domain auf Exchange / Mailrelay
– PST Export / Import
– Besonderheiten (LegacyExchangeDN etc.)
Namespaces
Die Planung der Namespaces ist notwendig, damit entsprechende DNS-Einträge angelegt werden können. Standardmäßig verwendet Microsoft Exchange hierfür den FQDN des jeweiligen Client Access Servers (Beispiel: server.domain.local). Bei der Grundinstallation wird dieser meist schon geändert und es werden dann oft für interne und externe Anfragen die selben DNS-Namen verwendet, z.B. webmail.domain.tld. und autodiscover.domain.tld. Findet also keine Neuinstallation der Exchange Umgebung statt, ist dieser Punkt schon klar.
Zertifikate
Die verwendeten Zertifikate hängen wiederum mit dem Namespace zusammen, der verwendet wird. In unserem Beispiel wäre das Zertifikat ein SAN Zertifikat und hat die beiden SANs webmail.domain.tld. und autodiscover.domain.tld.
Autodiscover
Da die meisten Benutzer die ein Exchange Postfach verwenden Outlook einsetzen und ganz klar festgelegt ist mit welcher Exchange Version welche Version des Outlook Clients unterstützt werden, führt kein Weg an Autodiscover vorbei. Kurz erläutert handelt es sich hierbei um die automatische Konfiguration der Kontoeinstellungen unter Angabe von E-Mailadresse (=UPN) und Kennwort. Die zur Konfiguration notwendigen Informationen erhält der Client entweder aus dem Active Directory (SCP), sofern der Rechner Mitglied einer solchen ist. Anderenfalls werden die Konfigurationseinstellungen via DNS gesucht. Eine weitere Methode, die allerdings selten zum Einsatz kommt, ist eine lokale XML-Datei die notwendige Informationen enthält.
Gibt der Benutzer die E-Mail-Adresse andre@domain.tld in der Outlook Konfiguration ein, werden daraus folgende URLs für den Abruf der Autodiscover.xml generiert:
https://domain.tld/autodiscover/autodiscover.xml
https://autodiscover.domain.tld/autodiscover/autodiscover.xml
http://autodiscover.domain.tld/autodiscover/autodiscover.xml
Unter diesen URLs wird nun die XML-Datei gesucht um das Outlook Profil zu konfigurieren. Ist eine der URLs nicht erreichbar, wird diese übersprungen und die nächste URL getestet.
Die Reihenfolge:
1. Autodiscover Prüfung gegen Office 365 (Outlook.office365.com)
– https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml
2. Service Connection Point (SCP) im Active Directory (wird übersprungen wenn der Client nicht Mitglied der AD ist)
3. https://domain.tld/autodiscover/autodiscover.xml
4. https://autodiscover.domain.tld/autodiscover/autodiscover.xml
5. http://autodiscover.domain.tld/autodiscover/autodiscover.xml
6. SRV Record _autodiscover._tcp. domain.tld
7. lokale Autodiscover.xml Datei
Auch hier gibt es wieder einen spitzenmäßigen Artikel auf meinem Lieblings Blog – https://www.frankysweb.de/exchange-2016-umfangreiches-whitepaper-zu-autodiscover/.
DNS-Einträge
Wird nun eine Migration einer E-Maildomain auf einen Exchange Server durchgeführt ist es zwingend notwendig entsprechende DNS-Einträge zu erstellen, damit die Autodiscoverfunktion gegeben ist. Außerdem muss ein MX-Record erstellt bzw. der vorhandene angepasst werden, damit andere Mailserver wissen wer für die Domain zuständig ist und wohin sie E-Mails an diese senden dürfen/müssen.
Für Autodiscover gibt es mehrere Möglichkeiten:
– HOST-A
– CNAME
– SRV (_autodiscover._tcp.domain.tld)
Wird auf dem Ziel Exchange Server mehr als 1 Domain verwaltet empfiehlt es sich einen SRV-Eintrag zu verwenden, um die Menge der notwendigen SANs im Zertifikat zu minimieren bzw. um zu vermeiden, dass bei Migration einer neuen Domain das Zertifikat mit dem zusätzlichen SAN neu ausgestellt werden muss.
Beim MX-Record wird immer ein HOST-A Eintrag verwendet. Die Vorgehensweise sollte so sein, dass für den neuen MX-Record ein HOST-A Eintrag im DNS des Providers erstellt wird. Zum Zeitpunkt der Umstellung wird dann der bisher existierende MX-Eintrag angepasst und der bereits existierende HOST-A für den neuen Mailserver eingetragen. Bestenfalls wurde bereits vorab die TTL (Gültigkeitsdauer) des MX-Eintrags gesenkt, bei manchen Providern ist eine TTL von 24 Stunden voreingestellt. Das verzögert die Umstellung nur unnötigerweise.
Idealerweise findet die Umstellung des MX-Records zeitnah vor dem PST-Export statt, um einen nicht vermeidbaren zeitlichen Versatz zu vermeiden. Eine Alternative dazu ist es, den Benutzern beide Postfächer in ihrem Outlook Profil zu konfigurieren.
Anlegen der neuen Domain auf Exchange / Mailrelay
Letztendlich muss die neue Domain natürlich auch noch dem Exchange Server bekannt gegeben werden. Zu bedenken gilt hierbei jedoch, sobald die Domain der Exchange Organisation also “autoritativ” bekannt gegeben wird werden E-Mails an diese nicht mehr nach extern versendet, sondern Exchange versucht diese E-Mails an eigene Objekte zuzustellen. Sind diese nicht vorhanden, also die entsprechenden E-Mailadressen nicht vorhanden, bekommt der Absender eine Unzustellbarkeitsnachricht (NDR). Sind die Adressen in der Exchange Organisation bereits vorhanden werden E-Mails von Absendern aus der Organisation natürlich auch an die entsprechenden Postfächer zugestellt, also nicht mehr nach extern versendet. Die Lösung wäre auch hier wieder den Benutzern beide Postfächer in ihrem Outlook Profil zu konfigurieren.
Im evtl. vorgeschalteten Mailrelay muss die Domain natürlich auch konfiguriert werden, sonst werden für diese keine E-Mails von extern angenommen.
PST Export / Import
Bei einer sogenannten Cross Forest Migration werden oft PST-Dateien als Transportmittel verwendet. Vor allem wenn die bestehende Alt-Umgebung verhältnismäßig klein ist und sich aus diesem Grund die Anschaffung von speziellen Migrationstools nicht lohnt. D.h. die Inhalte der Postfächer aus der alten Umgebung werden in eine PST-Datei exportiert und im Anschluss auf dem Exchange Server per PowerShell in die neu angelegten Postfächer importiert.
Sonderfall LegacyExchangeDN
Wird die Migration aus einer bestehenden Exchange Umgebung durchgeführt darf auf keinen Fall der LegacyExchangeDN vergessen werden. Dieses Attribut wird von Outlook für die Autovervollständigung von E-Mail-Adressen und für die Zuordnung von Personen zu Terminen verwendet. Wird das Postfach nun in einer anderen Gesamtstruktur neu angelegt ändert sich dieses Attritut und Benutzer erhalten eine entsprechende Unzustellbarkeitsnachricht. Um das Problem zu vermeiden muss schlicht und einfach der alte LegacyExchangeDN zusätzlich als X500-Adresse in das neu angelegte Postfach eingetragen werden.
Frank Zöchling beschreibt das auf seinem Blog ausführlich im folgenden Artikel – https://www.frankysweb.de/exchange-migration-sonderfall-pst-migration-550-5-1-1/.