Postfachmigrationen finden heutzutage meistens von alten Exchange-Infrastrukturen auf neue Releases, also beispielsweise von Exchange Server 2007/2010 nach Exchange Server 2013 oder aus dem eigenen Rechenzentrum in Richtung Cloud, sprich nach Office 365, statt. Dennoch kann es vorkommen, dass Postfächer aus der Cloud in das eigene Rechenzentrum übertragen werden müssen. Dieser Artikel gibt Hilfestellung.
Ist Exchange in einer Hybridbereitstellung mit der Cloud verbunden, so ist das Ganze ein Kinderspiel. Es kommt jedoch auch vor, dass Postfächer, die bislang rein cloudbasiert betrieben wurden, gänzlich ohne Integration in die eigene IT-Infrastruktur übertragen werden müssen. Stellen Sie sich beispielsweise vor, zwei Unternehmen fusionieren, von denen eines über eigene Rechenzentren verfügt, während das andere bislang ohne eigenes Active Directory auskam und sämtliche Dienste aus der Cloud bezog.
Ausgangssituation
Vor der Migration funktioniert der Mailflow wie oben dargestellt. E-Mails, die an Fabricam gesendet werden, werden über den DNS MX-Record an die Microsoft-Cloud übermittelt, wohingegen E-Mails an Contoso am Mailgateway im eigenen Rechenzentrum landen und dann an die Exchange-Infrastruktur übergeben werden.
Um in der Lage zu sein, im eigenen RZ von Contoso E-Mails für Fabricam zu verarbeiten, muss die Domäne fabricam.com im Exchange-System von Contoso als akzeptierte Domäne konfiguriert werden. Hierbei ist es wichtig, die Domäne mit dem Typ Internal Relay zu definieren. Wenn die Zielumgebung über einen Sendeconnector verfügt, über den die Auflösung der Zielsysteme über DNS MX-Einträge geschieht, müssen Sie nichts weiter tun. Andernfalls wird ein dedizierter Sendeconnector für die Domäne fabricam.com benötigt. Gleichzeitig wird die Domäne in der Microsoft-Cloud ebenfalls in eine interne Relaydomäne umkonfiguriert und ein Sendeconnector angelegt, über den E-Mails an Contoso übermittelt werden können.
Alle E-Mails an eine interne Relaydomäne werden in der eigenen Exchange-Organisation zuzustellen versucht. Ist kein entsprechendes Empfängerpostfach vorhanden, werden die Mails über einen Sendeconnector an ein weiteres E-Mail-System weitergeleitet. Da sich bislang an den externen DNS MX-Einträgen nichts geändert hat, werden E-Mails für Fabricam nun immer noch an die Microsoft-Cloud übermittelt. Ist der gewünschte Empfänger in der Cloud nicht bekannt, findet eine Weiterleitung an das Contoso-Mailgateway statt. Da die Konfiguration im Contoso-Rechenzentrum identisch ist, ist es wichtig, Loops im Mailflow zu verhindern. Andernfalls werden E-Mails über den MX-Eintrag nach Office 365 eingeliefert und, wenn der Empfänger nicht bekannt ist, an Contoso weitergeleitet. Ist der Empfänger in Contoso ebenfalls nicht bekannt, wird die E-Mail wiederum an Fabricam weitergeleitet und so weiter. Um dies zu umgehen, sollte eine Art Empfängerfilterung am Mailgateay auf Contoso-Seite konfiguriert werden, beispielsweise über eine Art Whitelisting. Contoso nimmt dann nur E-Mails für Empfänger an, für die bislang ein Postfach in der Cloud existiert hat.
Im Beispiel oben existiert der Empfänger tim@fabricam com, wohingegen die Adresse timx@fabricam.com unbekannt ist. Da beide Empfänger in der Cloud nicht bekannt sind, erfolgt eine Weiterleitung ins eigene Rechenzentrum. Da einer der Empfänger auf der Whitelist steht, wird die E-Mail angenommen, die E-Mail wird an die unbekannte Adresse zurückgewiesen.
Mit der PowerShell in die Cloud
Einen entsprechenden Export kann man sich einfach über die PowerShell aus der Cloud generieren. Hierzu ist es zunächst notwendig, eine PowerShell-Sitzung in die Cloud aufzubauen und die Sitzung in die PowerShell zu importieren.
Sobald nun Exchange-CMDLETs in der aktuellen PowerShell-Sitzung abgesetzt werden, findet die Ausführung in der Cloud statt. Der Befehl
Get-Mailbox | Select PrimarySMTPAddress | Export-CSVC:TempCloudMailboxes.csv -NoTypeInformation
wird beispielsweise einen Export aller E-Mail-Adressen für die Empfängerfilterung generieren.
SPF als Showstopper
Sender Policy Framework ist ein einfaches System, mit dessen Hilfe geprüft wird, ob eine empfangene E-Mail von einem für die Absenderdomäne autorisierten Mailserver abgesendet wurde. Hierzu wird in der öffentlichen DNS-Zone der Absenderdomäne ein spezieller DNS TXT-Eintrag konfiguriert, in dem die IP-Adressen der E-Mail-Server eingetragen sind, von denen E-Mails der Absenderdomäne verschickt werden dürfen. Ein empfangendes E-Mail-System, das SPF nutzt, wird nach Empfang einer E-Mail prüfen, ob ein entsprechender DNS TXT-Eintrag existiert und in dem Fall die E-Mail nur dann annehmen, wenn der absendende Server über eine IP-Adresse aus der Liste verfügt. Stimmt die IP-Adresse des sendenden Servers nicht mit der Liste überein, wird die E-Mail abgelehnt.
Aufgrund der Tatsache, dass die Domäne fabricam.com als interne Relaydomäne konfiguriert wurde, werden E-Mails nicht einfach umgeleitet, sofern das Postfach in der Cloud nicht gefunden werden kann, sondern relayed, der absendende Server ist also für das Contoso-Gateway ein E-Mail-Server in der Microsoft-Cloud. Ist SPF aktiv, so wird eine weitergeleitete E-Mail höchstwahrscheinlich am Contoso-Gateway abgelehnt, da die IP-Adresse von Microsoft nicht mit den IP-Adressen im TXT-Eintrag des Absenders übereinstimmt. Aus diesem Grund sollte SPF als SPAM-Schutz zumindest während der Migrationsphase für die Domäne fabricam.com am Contoso-Gateway abgeschaltet werden.
Vor der Migration
Bevor die ersten Postfächer migriert werden können, brauchen Sie einen Migrationsendpunkt in der Cloud. Gleichzeitig muss die MRS-Proxy-Funktion auf den Client Access Servern im eigenen Rechenzentrum aktiviert werden, wodurch die CAS-Server als Migrationsendpunkt dienen können. Zudem wird ein E-Mail-aktiviertes Benutzerkonto für das zu migrierende Postfach im Contoso-Active Directory benötigt, das die E-Mail-Adresse und die Exchange-GUID des Cloud-Postfachs erhält. Auch hier unterstützt die PowerShell beim Extrahieren der notwendigen Informationen aus der Cloud und der Konfiguration im eigenen Active Directory.
Die Migration
Für die eigentliche Migration wird im Exchange Admin Center von Office 365/Exchange Online ein neuer Migrationsbatch erstellt.
Bevor die Migration startet, wird noch einmal geprüft, ob ein passendes Benutzerkonto im Ziel-AD gefunden werden kann. Ist dies der Fall, wird die Migration durchgeführt, andernfalls erscheint eine entsprechende Fehlermeldung. In der Cloud wird bei Abschluss der Migration ein E-Mail-aktivierter Benutzer für das ehemalige Cloudpostfach angelegt, damit Benutzer, deren Postfächer noch nicht migriert wurden, weiterhin in der Lage sind, den Empfänger im Adressbuch aufzulösen und E-Mails dorthin zuzustellen.
Ich hoffe, Ihnen ein wenig weiter geholfen zu haben bei der Herausforderung, Cloudressourcen in die eigene Umgebung zu übertragen. Sollten Sie dennoch weitere Fragen zur Migration von Postfächern in oder aus der Cloud oder rund um Exchange Server haben, stehen wir Ihnen gerne mit unserer Expertise zur Verfügung.
