CrossOrg

Auch wenn diese Seite "CrossOrg" überschrieben ist und die allgemeinen Grundlagen einer Migration von Benutzern on Postfächern von einer Organisation in die andere beschreibt, so ist es durchaus eine "allgemeine" Seite, die auch generell für Migrationen von Fremdsystemen genutzt werden kann. Sie kann auch dafür genutzt werden, zwei Mailsysteme auch längere Zeit parallel zu betreiben, indem Sie die Migration einfach nie anfangen :-). Auch die Migration und Koexistenz mit der "Cloud", also Office365 und anderen Angeboten fällt in diesen Bereich. Diese Beschreibung ist also auf einen längeren Parallelbetrieb ausgelegt und sie besteht aus mehreren Bausteinen:

  • Vorwort zu Mailrouting und Verzeichnisabgleich
  • Einrichten der Koexistenz
  • Migration
  • Auflösen der Koexistenz

Für eine längere Koexistenz sind mehrere Faktoren wichtig

  • Mailrouting und Adressen
    Beide System sollten alle Empfänger beider Umgebungen können und über Weiterleitungen die jeweils andere Seite zu adressieren. So kann es letztlich egal sein, an welchem System eine Mail eingeliefert wird oder wer intern über das Adressbuch einen Empfänger auswählt
  • Verteiler
    Ebenso müssen auf beiden Seiten entweder "identische" Verteiler gepflegt werden oder sie nehmen Mehrfachübertragungen in Kauf und pflegen die Verteiler auf einer Seite und nutzen eine Weiterleitung auf dem anderen System.
  • öffentliche Ordner und Free/Busy
    Gerade beim Einsatz zweier Exchange Organisationen bietet es sich natürlich an, auch die gemeinsam Arbeitsbereiche irgendwie abzugleichen. Auch Frei/Belegt-Zeiten könnten abgeglichen werden.

Der Zugriff auf Postfächer des anderen Systems als "Stellvertreter" ist in den meisten Fällen nicht einfach möglich. Und auch die permanente Synchronisierung ist eine anspruchsvolle Aufgabe die oft unterschätzt wird. Wollen Sie aber nur mal schnell eine SBS Organisation in eine andere SBS-Organisation am Wochenende überführen, dann kann es auch mit der Holzhammermethode erfolgen.

Vorwort zu Mailrouting und Verzeichnisabgleich

Es gibt mehrere Möglichkeiten, die Migration von zwei Exchange Organisationen vorzubereiten. Speziell das Thema Mailfluss kann über "Überlaufconnectoren" gelöst werden, so dass Exchange nicht aufgelöste Empfänger an die neue bzw. alte Organisation weiter sendet. Allerdings halte ich dieses Vorgehen als weniger sinnvoll, da so nicht nur die Mails zugestellt werden, sondern auch sehr schnell Schleifen (z.B. bei nicht existenten Adressen) gelegt werden. Störender finde ich aber die partiellen Adressbücher, eine beschränkte Auflösbarkeit und die nicht "gesicherte" Zustellung .z.B. bei Verteilern. Und spätestens bei der Migration der Inhalte wird es auffallen, wenn die neuen Zielkonten nicht die richtigen Stammdaten haben oder die Bordmittel von Exchange einfach kein geeignetes Zielkonto finden. Daher ist von Anfang bis zum Ende ein sauberer Verzeichnisabgleich undein passendes Mailrouting erforderlich. Am Beispiel von zwei Organisationen kann das heissen:

  1. Gleiche SMTP-Domain firma.tld
    Zuerst gehe ich davon aus, dass Quelle und Ziel auch die gleich SMTP-Domäne benutzen wollen. Also muss ein Weg gefunden werden, wie Mails korrekt zugestellt werden können, auch wenn die Mailbox eigentlich außerhalb der eigenen Organisation ist.
  2. Routingdomains org1.firma.tld und org2.firma.tld
    Da beide Organisationen die gleiche primäre SMTP-Domäne haben, bekommt jede Organisation noch eine eindeutige SMTP-Domäne, die aber nach extern nicht sichtbar wird, d.h. kein Autodiscover, kein MX-Eintrag. Es ist einfach eine zusätzliche Adresse für die "Postfächer" in der jeweiligen Domäne, damit diese eindeutig erreicht werden können.
  3. Empfängerrichtlinien
    Entsprechend sollte die Empfängerrichtlinie für die Postfächer einer Domain erweitert werden, dass diese Benutzer auch noch die Adresse der Routingdomain ihrer Organisation bekommen.
  4. SMTP-Connectoren für die RoutingDomains
    Damit der Mailfluss gegeben ist, wird über SMTP-Connectoren sichergestellt, dass Mails an diese Routingdomain aus der anderen Organisationen an die Zielorganisation versendet werden kann.
  5. Mailrouting über DirSync mit TargetAddress
    Damit die Mails nun zuverlässig ankommen, müssen Sie für jedes Postfach in einer Organisation im in der anderen Organisation einen Empfänger (Mailkontakt, Mailuser, MailboxUser) anlegen, der über das Feld TargetAddress die Mails an die produktive Mailbox in der anderen Organisation weiter leitet. Beachten Sie hierbei Abhängigkeiten: Aus einem Mailkontakt können Sie keinen Benutzer machen (Unterschiedliche Objectclass). Ein MailUser (deaktiviertes AD-Konto als Exchange Kontakt) ist hier besser, wenn Sie auch die Konten selbst migrieren wollen. Per ADMT können Sie die Benutzer vorher migrieren und dann aktivieren oder später bestehende Benutzer mit der SIDHistory erweitern lassen.
    Für öffentliche Ordner sollten Sie auf der Gegenseite Kontakte anlegen lassen und nach der Migration der Ordner "umstellen".
    Für Verteiler haben Sie die Wahl, ob sie Kontakte anlegen oder Verteiler, die dann aber die Mitglieder (z.B. mit ADMT) synchronisieren müssen, damit die Empfänger die "Gleichen" sind.
    Hinweis: Das Exchange 2010-Skript "Prepare-Moveruest.ps1" kann hier eine wesentliche Rolle im Bezug auf Postfächer spielen

Solche eine perfekte Verbindung stellt sicher, dass alle Empfänger immer auf beiden Seiten 100% auflösbar und erreichbar sind und auch für die Anwender im Adressbuch zu sehen sind. Nebenbei können Skript die Übereinstimmung der GAL prüfen und Inkonsistenzen melden. Sie vermeiden Mailloops und wissen auch immer genau, wo ein Postfach letztlich "aktiv" ist.

Einrichten der Koexistenz

Erster Schritt ist also die Einrichtung der Koexistenz. Das ist erst mal einfacher gesagt als getan, da alle Postfächer der einen Seite auf der anderen Seite als Kontakte mit Weiterleitung eingerichtet werden müssen und der Mailfluss entsprechend eingerichtet werden kann. Wenn man den Fokus auf Exchange hat, dann kommt das Feld "TargetAddress" hier in den Vordergrund, welches eine besondere Funktion bei der Koexistenz hat. Eine Mail an ein Objekt mit gefüllter TargetAddress wird immer an diese Adresse "nach außen" weiter geleitet, selbst wenn es innerhalb der gleichen Organisation ein Objekt mit gleicher ProxyAdresse gibt. Das Feld ist normalweise nur bei Kontakten in der GUI konfigurierbar aber funktioniert auch, wenn man es bei Postfächern direkt einträgt.

Mailbox im Ziel
Auch wenn man im Ziel eine Mailbox anlegen und per TargetAdresse die Mails umleiten kann, so ist diese Verhalten gefährlich, weil Benutzer im Ziel als Stellvertreter eben diese "tote" Mailbox ansprechen könnten. Es gibt Drittprodukte, die allerdings Mailboxen replizieren.

Die Schritte in Kürze:

  • Anmeldekonten
    Wer eine Migration vor hat und als Quelle und Ziel mit Windows arbeitet, sollte die Benutzer und Gruppen natürlich mittels ADMT übertragen. Das geht nicht nur einfach sondern nimmt auch die alte SID, Kennworte, Gruppenmitgliedschaften, Profile und mehr mit, wenn man es richtig macht.
  • Mailrouting
    Dann sollte man natürlich sicherstellen, dass die Mails zwischen beiden Systemen nicht über das Internet laufen, sondern sicher und schnell intern zugestellt werden. Durch den Trick mit der "TargetAddress" können beide Organisationen sogar die gleiche SMTP-Domain nutzen, die sogar autoritativ sein darf.
  • Kontakte und Verteiler
    Damit das aber funktioniert, müssen Sie irgendwie einen Verzeichnisabgleich erreichen, der die Postfächer einer Umgebung auf der anderen Seite als Weiterleitungen einträgt. In Exchange Umfeldern kann man dies per LDAP und VBScript (MiniSync) erreichen oder kommerzielle Tools (Verzeichnisabgleich) erreichen. Auch die Verteiler solle man entsprechend abgleichen oder als Weiterleitungen einrichten.
  • Free/Busy und Public Folder
    Zwischen Exchange Umgebungen kann man mit IOREPL - InterOrg Replication Tool Inhalte von öffentlichen Ordnern abgleichen. Auch Inhalte von öffentlichen Ordnern sind möglich

Weitere Informationen finden Sie auch auf Verbinden von Organisationen. Auf diesem Stand könnten sie nun lange verharren und einfache zwei oder sogar mehr Systemen nebeneinander betreiben. Das geht sogar mit Fremdsystemen, wenn Sie entsprechend den Verzeichnisabgleich effektiv automatisieren.

Unterstützung durch Net at Work:
Wir können Sie aktiv unterstützen. Rufen Sie einfach an.

Migration

Auf Dauer wird aber keine Firma mehrere Mailsysteme parallel nebeneinander betreiben wollen, sondern letztlich doch in ein System überführen. Die Migration eines Postfachs in Kurzform lautet dann wie folgt:

  • Weiterleitung von Ziel zur Quelle deaktivieren
    Damit werden dann Mails an diese Adressen aus dem Ziel nicht mehr zur Quelle gesendet.. Ist Exchange das Ziel, dann können Sie den Kontakt bzw. den mailaktivieren Benutzer in eine Mailbox konvertieren. Ist das Ziel bereits eine Mailbox, dann löscht man einfach das Feld "TargetAddress".
  • Weiterleitung von Quelle ins Ziel aktivieren (aber nicht das Postfach löschen !)
    Damit wird sichergestellt, dass jede Mail die noch an die Quelle geht, zum Ziel umgeleitet wird. Das Quellpostfach ist damit "fast" eingefroren. Bei Exchange kann es leider schon passieren, dass ein Stellvertreter noch darauf zugreifen könnte. Das ist noch zu verhindern.
    Vorsichtige Naturen können natürlich das Mailrouting komplett anhalten, da die Migration ja auch schief gehen könnte und dann neue Mails schon im Ziel liegen könnten. Hier ist als umsicht gefragt.
  • Mails versenden und abrufen
    Noch kann der Benutzer Mails versenden. Das sollte er auch als letzte Chance nutzen, um Mails auf einem PDA (ActiveSync), Notebook (OST-Datei) oder anderen Systemen zu versenden.
    Ist die Quelle kein Exchange, dann muss geprüft werden, ob die Daten überhaupt auf dem Server liegen und von dort direkt übertragen werden können (z.B.: per IMAP4) oder ob die Mails sowieso auf dem Client liegen (z.B.: bei POP3). Notfalls sieht die Migration so aus, dass die Clients ein letztes Mal noch das alte Postfach leeren, ehe Sie auf das neue Postfach umkonfiguriert werden.
  • Inhalte von Exchange migrieren
    Wird der Inhalt mit Mailmig oder Move-Mailbox migriert, dann setzen die Tools in der Quelle das Flag "PR_IN_TRANSIT", was Exchange als Quelle dazu veranlasst, Mails an dieses Postfach "onHold" zu legen. Dies kann man natürlich auch programmatisch nutzen, um ein Postfach einige Zeit zu blockieren.
    Bei der Migration gehen natürlich ein paar Informationen verloren, z.B. Dumpster, Stellvertreter und Regeln können unter umständen auch nicht mehr funktionieren.
  • Ersetzen des MailboxUsers in QUELLE durch MAILUSER
    Nach dem Move ist das Quellpostfach aber wieder frei. Hier sollte dann möglichst bald aus dem Benutzer mit Postfach ein Benutzer mit Mailkontakt (Mailaktivierter Benutzer) oder gar nur noch ein Kontakt werden.

Die Migration von einer Exchange 2003/2007/2010 in eine andere Exchange Organisation erfolgt über verschiedene Programme.

Quelle/Ziel Exchange 2003 Exchange 2007 Exchange 2010
Exchange 2003

MailMig

Org2Org 2007 Move-Mailbox

Org2Org 2010 MoveRequest

Exchange 2007

 

Org2Org 2007 Move-Mailbox

Org2Org 2010 MoveRequest

Exchange 2010

 

 

Org2Org 2010 MoveRequest

Für öffentliche Ordner stellt Microsoft nur das Programm IOREPL zur Verfügung, welche Die Inhalte übertragen kann. Das Übertragen von Mailadressen, Ordnerberechtigungen etc. ist nicht damit abgedeckt und muss durch andere Werkzeuge wie PFDavAdmin/ExFolders für die Berechtigungen und PowerShell-Skripte für die Mailaktivierung erfolgen.

Abbau

Wenn Sie dann alle Postfächer und Ordner migriert haben, dann sollte es nun in der Quelle nur noch Mailkontakte geben, die jede Mail über den Eintrag der TargetAddress in die Zielorganisation weiter leiten. Spätestens jetzt können Sie die Quellorganisation nach einer Überprüfung langsam abbauen. Die Überprüfung ist erforderlich, da ja immer noch andere Dienste "über diese Organisation" arbeiten.

  • SMTP Routing Umstellung
    Wenn dies noch schon früher passiert ist, dann müssen si nun langsam daran gehen, den Mailempfang aus dem Internet auf die neue Exchange Organisation umzustellen und auch ausgehend nicht mehr die alte Organisation zu nutzen. Das Exchange Message-Tracking ist hier eigentlich der zuverlässigste Indikator, da hier jede übertragene Mail protokolliert wird. In einer leeren Umgebungen sollten maximal noch ein paar Public Folder Replikationsmails auftreten, wenn es mehrere Public Folder Speicher gibt.
  • Postfächer und Ordner
    Wenn Sie alles richtig gemacht haben, dann sollten Sie in der Quell auch keine Postfächer mehr haben. Ich habe mir angewöhnt auch Postfächer die angeblich "keiner mehr braucht" dann auch löschen zu lassen, denn spätestens bei der Deinstallation des Servers muss dies dann doch erfolgen.
    Das gleiche gilt für öffentliche Ordner.
  • QuellUmgebung aufräumen/deinstallieren
    Dazu gehört auch, dass Sie in der abzubauenden Organisation auch Zusatzprodukte (Faxserver Connectoren, Blackberry, Antivirus, Backup etc.) abschalten

Wenn die Quellorganisation wirklich "leer" ist, dann sollte auch die Deinstallation kein Problem darstellen

Weitere Links

FreeBusy

Quelle: http://technet.microsoft.com/en-us/library/bb201680.aspx
A mail contact that represents a recipient object from another forest. Mail forest contacts are typically created by Microsoft Identity Integration Server (MIIS) synchronization.
Important:
Mail forest contacts are read-only recipient objects that are Updated only through MIIS or similar custom synchronization. You cannot remove or modify a mail forest contact by using the Exchange Management Console or the Exchange Management Shell.

Weitere Links