Org2Org MoveRequest (2010)

Mit Exchange 2010 hat sich schon wieder alles geändert. Das bisherige Move-Mailbox mit direkter aktiver Arbeit durch den Admin wurde durch einen "MoveRequest" ersetzt, den ein Administrator über die PowerShell in eine Warteschlange einstellt und der Dienst Mailbox Replication Service (MRS) dann mit den Berechtigungen der Exchange Server ausführt.

Das funktioniert auch über die Grenzen einer Organisation hinweg, wenn man einen "Remote Move-Request" einstellt. Natürlich müssen Sie dann ein paar passende Credentials eingeben, die aus der Quelle die Inhalte exportieren und in das Ziel übertragen kann. Per PowerShell kann dem Request sogar noch mitgeteilt werden, das in der Quelle das Postfach durch einen Mailkontakt, d.h. eine AD-Benutzerkonto mit Exchange Kontakteigenschaften ersetzt wird.

Matching

Beim Migrieren über die Grenzen einer Organisation hinaus stellt sich immer die Frage, woran die Software erkennt, in welches Ziel die Inhalte importiert werden sollen. Während es bei MailMig InterOrg noch SMTP-Adressen, LegacyExchangeDN oder ALIAS waren und bei Move-Mailbox noch SMTPAddress, source objectSID auf sidHistory und legacyExchangeDN waren, ist es bei Exchange 2010 nur noch das Feld "msExchMailboxGUID" zu sein, welches im Ziel den gleichen Wert enthalten muss, wie in der Quelle.

Das Script Prepare-Moverequest ist meiner Meinung nach ein sehr gutes Script, um das Matching vorzubereiten. Die nachfolgend beschriebenen Optionen über CSV-Dateien sind nur zweite Wahl, da viele anderen Einstellungen einfach nicht übernommen werden.

Das PowerShell-Skript "Prepare Moverequest" übernimmt dieser Arbeit, aus der Quelle die Benutzer auf bestehende Benutzer im Ziel zu matchen und vor allem den Inhalt von "msExchMailboxGUID" zu setzen.

Verschieben per GUI

Natürlich können Sie die Verschiebung auch aus der GUI starten:

Ein Assistent fordert dann die entsprechenden Daten an.

All diese Funktionen sind natürlich auch per PowerShell einzustellen. Das macht insbesondere dann Sinn, wenn Sie mit Listen von Benutzern arbeiten und diese Benutzer dann durch die verschiedenen Prozesse (ADM, Prepare-Moverequest, MoveMailbox etc) schieben

Funktionsweise

Im Hintergrund passiert nun folgendes

  1. Move-Request landet in einer Queue
  2. MRS-Service eins CAS im Ziel wird angeschubst
  3. MRS verbindet sich mit der Quelle (Bei Exchange 2003/2007 per MAPI und bei Exchange 2010 per HTTPS auf den MRS in der Quelle. Bei Exchange 2003/2007 müssen natürlich die Namensauflösung und TCP-Ports offen sein. Bei Exchange 2010 muss auf der Quelle der MRS-Proxy aktiviert sein und natürlich HTTPS funktionieren. Bei Cross Forest Moves kann hier die StammCA und CRL ihnen das Leben erschweren
  4. MRS legt eine Mailbox im Ziel an
  5. MRS lockt die Quellmailbox für Zugriffe, wenn diese nicht auf Exchange 2007SP2/2010 liegt
    Erst ab Exchange 2007SP2/2010 kann ein "Online Move" genutzt werden. Bei früheren Versionen wird der Zugriff auf die Quelle blockiert.
  6. MRS überträgt die Inhalte in das Ziel
    Wenn Exchange 2007SP2/2010 als Quelle genutzt wird, kann der MRS bei ca. 95% den Move anhalten. So können viele Mailboxen quasi bis kurz vor den Abschluss schon ins Ziel übertragen werden und mit einem "RESUME" die Umschaltung sehr schnell erfolgen
  7. Umschaltung
    Sobald der MRS fertig ist, wird in der Zielmailbox die Weiterleitung über die TargetAddress entfernt und in der Quell aus dem Postfach ein MailUser gemacht. Der MailUser in der Quelle bekommt die Zieladresse der Mailbox im Ziel als TargetAddress.

Ein "Parallelbetrieb" von beiden Mailboxen, wie dies z.B. Quest anbietet, ist nicht möglich. Der Online-Move erlaubt es aber, die Benutzer nur sehr kurz auszusperren und mit Einschränkungen sogar Verschiebungen über WAN durchzuführen. Der Vorgang selbst ist aber vom Exchange Team auf dem Blog noch ausführlicher beschrieben.

Matching mit CSVDE vorbereiten

Nun ist es ja so , dass gerade das Feld msExchangeMailboxGUID im Ziel vermutlich ab wenigsten gesetzt sein dürfte. Die Mailadresse kann man ja noch per Empfängerrichtlinien in den meisten Fällen identisch hin bekommen. Aber in vielen anderen Fällen klappt das nicht. Aber hier kann CSVDE mit der Export/Import Funktion helfen.

Zuerst exportieren wir die Benutzer mit der MailboxGUID aus der Quelle mit:

csvde -f Userlist.csv -r "( &(mailnickname=*)(objectClass=User))" -l dn,objectclass,msexchmailboxguid

Das Ergebnis ist eine schnöde Textdatei.

Wer etwas pfiffiger ist, sollte sich noch auf die OUs beschränken, in denen auch die "echten" Benutzer sind und die Systemaccounts ausschließen. Da es aber ja ein einmaliger Prozess ist, kann das auch einfach per NOTEPAD nachträglich korrigiert werden.

Der Einfachheit halber gehe ich davon aus, dass die Benutzer im Ziel den gleichen RDN haben so dass nur der Pfad zum Benutzer geändert werden muss. Das können Sie auch wieder in Notepad einfach durch "Suchen & Ersetzen" machen oder beim Import von CSVDE das Vorkommen ersetzen lassen.

csvde -i -f Userlist.csv -c "OU=test,DC=msxfaq,DC=de" "OU=Neu,DC=Ziel,dc=tld"

Das funktioniert natürlich nur so einfach, wenn die Benutzer im Ziel auch die gleichen relativen Pfade haben.

CSVDE und PowerShell

Wenn Sie ein anderes Feld zum "Matchen" brauchen, dann hilft CSVDE und etwas PowerShell. Zuerst exportieren wir wieder die Benutzer samt msexchMailboxGUID aus der Quelle. Hinzu kommen muss aber nun auch das Feld, welches zum "matchen" herangezogen werden soll. Diese CSV-Datei können wir dann im Ziel mit PowerShell und den Quest Tools einfach einlesen und verwenden, z.B. mit:

import-csv c:\Userliste.csv | set-ADUser -identity $_.SamAccoutname -replace @{msexchMailboxGUID=$_.msexchMailboxGUID}

Hinweis: Das Skript habe ich "trocken" entwickelt und konnte es noch nicht selbst testen.

Weitere Links