diagram

Vorbereiten des Mail-Fluss für die Office 365 Migration

5fd223ff74934390a8da8772024dfe38

Dieser Artikel ist Teil meiner Migrationsreise von meinem alten Office 365 zu meinem neuen Microsoft 365 Abonnement. In diesem Artikel geht es um das Thema des Mailverkehrs während der Migration und wie Datenverlust vermieden werden kann.

Im Mai 2015 habe ich bereits den Artikel „Migration von einem Office365 Tennant zu einem anderen Office365 Tennant“ geschrieben, die relevanten Teile aus dem alten Artikel werde ich hier mit übernehmen und anpassen.

Besonderheit von Office365 Postfächern

Das gute an Office 365 Postfächern ist, Sie haben alle eine Interne ID. Diese besteht aus der Tenant-Bezeichnung und dem Benutzernamen. Ein Beispiel ist „spam_mich_zu@niesenf.onmicrosoft.com“, diese Adressen nutzen wir später, sowohl für die neue als auch die alte Umgebung.

Arten der Migration

Als nächstes muss überlegt werden welches der Richtige Ansatz für die Mailmigration ist.

Die Big-Bang Migration

Ein Fall von „Treffen sich die Admins am Wochenende und Migrieren mal eben alles“. Dies ist bei kleinen Unternehmen unter Umständen noch möglich, bei den meisten eher nicht. Der große Vorteil, es ist der einfachste Weg. Umstellen Migrieren, fertig.Ist eigentlich ganz einfach.

Mailflow bei der Migration von 2 Office365 Umgebungen
Mailflow bei der Migration von 2 Office365 Umgebungen
Die Koexistenz

Jetzt wird es schon schwieriger, wenn die Migration nicht auf einen Schlag erfolgen kann, dann wird es für die meisten IT-Abteilungen schon schwer. In diesem Fall wird Koexistenz benötigt, das bedeutet beide Welten arbeiten miteinander. Das ist, wenn beides Office365 Umgebungen sind nicht einfach. Auch müssen beide Welten jeweils wissen welches Postfach wo liegt und auch untereinander richtig Kommunizieren. Dies führt vor allem bei Terminen und Antworten auf Mails öfters zu Problemen. Nach meiner Erfahrung ist Koexistenz zweier Office 365 Umgebungen ohne Drittanbieter Lösungen mit entsprechendem Wissen nur mit sehr großem Aufwand möglich. Immerhin müssten Sie einige Skripte schreiben, um die Umgebungen entsprechend zu Konfigurieren.

Wenn Sie Koexistenz benötigen, empfehle ich Ihnen sich ein passendes Systemhaus zu suchen. Achten Sie darauf das entsprechende Migration Referenzen vorliegen.

Hintergrund der Herausforderungen bei einer Koexistenz sind die internen Adressierungen wie zum Teil X400 oder X500, je nach der Entstehungsgeschichte Ihrer Umgebung. Auch halten sich unter Umständen die alte Umgebung für zuständig, obwohl der Benutzer schon auf der neuen liegt oder umgekehrt. Entsprechend müssen in dem anderen System Weiterleitungen gepflegt werden. Ein weiteres Problem können Berechtigungen und Authentifizierung sein. Die betrifft vor allem den gemeinsamen Zugriff. Zum Beispiel Verfügbarkeitsinformationen von Kalendern, Verfügbarkeiten von Besprechungsräumen und Ressourcen oder aber auch Postfachberechtigungen für Vertretern oder Assistenten.

Die jeweiligen Schritte hängen vom Werkzeug und der Konzeption der Koexistenz ab, und würden hier den Rahmen sprengen.

Entsprechend betrachte ich in diesem Artikel im Schwerpunkt die „Big-Bang“ Migration.

Werbung

Weiterleitungen der Mails

Da Änderungen im DNS immer eine Weile brauchen, ist nicht nur die Reduzierung der Lebensdauer (TTL) der DNS-Einträge wichtig. Auch muss man sich über den Mailfluss in der Zwischenzeit Gedanken machen. Generell schicken Mailserver eine Mail nochmal, wenn Sie nicht zugestellt werden konnte. Die einzigen die das im Normalfall nicht machen sind Spammer die Systeme gekapert haben, deshalb unterstützen viele Server heute auch Greylisting. Das Problem ist nur, das weder das Intervall noch die Versuchsdauer einheitlich sind. Viele versuchen es jede Stunde für 24 Stunden.

Und jetzt kommt die Besonderheit der Microsoft Umgebung ins Spiel. Aufgrund der Komplexen Infrastruktur, auch gerade bei dem Schutz der Systeme, kann es bis zu 24 Stunden dauern bis eine Maildomäne von einer Microsoft Office 365 Umgebung gelöst ist und ggf. nochmal so lange, um diese wieder hinzuzufügen. Das sind Zahlen, die Microsoft mal als „bis zu“ kommuniziert hat. Bei meiner Migration lag der Zeitraum für die Entfernen bei unter einer Stunde. Sicherheitshalber sollte man noch etwas extra Wartezeit für nachgelagerte Systeme hinzufügen.

Damit jetzt keine Mails verloren gehen, nutzen wir einen dritten Server. In meinem Fall der Mailserver des Webhosting der sonst nichts zu tun hat. Was wir aufbauen müssen ist eine kleine Kette.

DNS-Einträge zu den verschiedenen Zeiten der Migration
DNS-Einträge zu den verschiedenen Zeiten der Migration

Dazu werden alle Mail Adressen auf dem Webserver eingerichtet und eine Weiterleitung an das entsprechende Postfach unter der @neu.onmicrosoft.com Adresse konfiguriert. Dafür müssen die Postfächer in der neuen Welt schon mit der Onmicrosoft Adresse existieren. Sobald die Weiterleitungen eingerichtet und am besten von dem Webserver aus auch getestet wurden, können der MX und der TXT mit dem Sender Policy Framework (SPF) Einträge auf den Interims Mailserver umgestellt werden. Wer möchte kann in Schritt 1 den neuen MX dann mit einer schlechteren Priorität hinzufügen und die, wenn es soweit ist ändern.

Wenn der MX-Eintrag auf den neuen Server geändert wurde, kann noch bis zum Ablauf der TTL Mails an das alte System zugestellt werden. Belassen Sie solange auch die Domäne im Office 365! Ich spare mir den Hinweis wie wichtig die TTL bei den DNS-Einträgen ist an dieser Stelle.

Sender Policy Framework (SPF)

Noch ein paar Worte zum SPF, diesen für die Spam Bekämpfung notwendigen Eintrag passe ich meistens schon mit der TTL an. Dieser Eintrag teilt anderen Mailservern mit, welche Server eigentlich Mails für die Domäne verschicken dürfen. Mails, die von anderen Systemen kommen werden, somit je nach Konfiguration als Spam markiert oder direkt verworfen. Entsprechend vorsichtig sollten man mit diesem Eintrag sein. Microsoft nennt hier „v=spf1 include:spf.protection.outlook.com -all“, ich nutze für die Migration „v=spf1 a mx include:spf.protection.outlook.com -all“. Das „a“ bedeutet das alle Systeme, die einen Hosteintrag im DNS haben Mails verschicken dürfen. Der Eintrag „mx“ bedeutet das alle Mail Server, also auch der Interim-Mailserver Mails verschicken dürfen. Um bei Überschneidungen eine Ablehnung zu vermeiden passe ich den Eintrag möglichst früh an.

Umstellung nach der Einrichtung des neuen Office 365

Wenn die Domänen alle in das neue Office365 übertragen wurden, und dort auch die entsprechenden Mail Aliase konfiguriert wurde, dann kann der MX auf die neue Office 365 Umgebung eingestellt werden. Bitte achten sie darauf, dass der Assistent bei dem Hinzufügen der Domäne vor falschen DNS-Einträgen warnt. Dies müssen Sie ignorieren!

Wenn Sie die Einträge ändern wie gewünscht, zeigt der MX auf die neue Umgebung, bevor die Postfächer Ihre Aliase haben, somit würden ggf. Mails als Unzustellbar abgelehnt. Nach der Umstellung sollten sie wieder mindestens die TTL abwarten bevor Sie den Mailserver zurück bauen. Ich persönlich warte immer noch ein paar Tage damit, bevor noch eine Mail von einem Server, der die DNS-Abfrage, nicht richtig implementiert hat, verloren geht.

Werbung

Das ist mir schonmal bei einer Migration passiert wo der Interim Server mit Greylisting geschützt war und der sendende Server nicht erneut den DNS geprüft hat, sondern an die intern gespeicherte Adresse geschickt hat. Sollte nicht passieren, aber… Da alle Mails an Office365 weitergeleitet werden, greifen auch die Schutzmechanismen in Office365. Somit ist dieses auch kein Sicherheitsrisiko. Anders sähe es aus, wenn sie den Interim Server als besonders vertrauenswürdig während der Migration eingestuft hätten.

Mögliche Stolperfallen

Es gib einiges was zu Komplikationen führen kann. Hier ein paar Beispiele die entsprechend beleuchtet werden sollten:

Werbung
  • Safe-Sender Konfiguration in Office 365, ist vielleicht der Webserver für interne Prozesse bzw. Dienste in der alten Umgebung gesondert Freigeschaltet? Dann muss das wahrscheinlich in der neuen Umgebung auch sein. Die kann Auswirkung auf die Sicherheit bei der Weiterleitung und den Viren- und Spamschutz haben.
  • Gibt es noch interne Systeme die Mail versenden? Wenn ja, wie ist da der Mailflow? Definierte IP bzw. Hostname oder MX-Abfrage? Dies könnten zum Beispiel Scanner / Multifunktionsdrucker oder interne Skripte zum Beispiel ein WSUS Bereinigungsskript oder ein Benutzeranlage Skript sein.
  • Sicherheitskonfigurationen mit Partnern oder Kunden in der alten Office 365 Umgebung, wie zum Beispiel Konnektoren mit Zertifikatsüberprüfung
  • Fehlerhafte DNS-Konfiguration, die verhindert das die Einträge öffentlich werden. Ein Beispiel hierfür war ein Kunde, der den falschen DNS-Server gepflegt hat. Deshalb prüfen Sie die Einträge zum Beispiel mit den Heise DNS Tools, dann kann die Antwort auch nicht von internen Systemen oder DNS Weiterleitungen verfälscht werden.

Kommentare

Eine Antwort zu „Vorbereiten des Mail-Fluss für die Office 365 Migration“

  1. Moni

    Danke für diesen tollen Blog. Das war sehr interessant zu lesen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

New articles in english

Werbung

Themen

Active Directory Administrative Vorlagen Anleitung AppV5 Autopilot Azure Azure AD ConfigMgr Deployment GPO Gruppenrichtlinien Guide How-To Linux Microsoft Microsoft Intune Office Office365 PowerShell Public Preview SCCM2012R2 SCSM2012R2 ServiceMgr Sicherheit TechNet Windows Windows 10 Windows10 Windows Server 2012 Windows Server 2012R2

Hinweise zum Affiliate-Marketing

Auf diesen Seiten werden auch Affiliate Marketing Links angezeigt. Diese sind meistens an dem kleinen „€“ oder einem „*“ dahinter zu erkennen. Der Betreiber dieser Seite erhält beim Kauf über diesen Link eine Provision, ohne das es den Verkaufspreis beeinflusst. Diese Einnahmen tragen zur Finanzierung der Seite bei.