Exchange Migration Wizard im Details

Diese Seite befasst sich etwas mit den Hintergründen von MailMig und wie das alles funktioniert.

  • Migrationsdateien
    Ich erkläre ihnen die Details zu den Migrationsdateien, die bei einer Zweischrittmigration angelegt werden und wie diese für eigene Zwecke angepasst werden können.
  • Matching
    Zudem lesen Sie, wie MailMig im Ziel eventuell bestehende Benutzer findet, denen er dann die Maildaten und Adressen zuordnet
  • Recovery, Rollback, Testfeld
    MailMig kann sogar exportierte Daten auf den gleichen Server wieder zurück importieren. damit ist MailMig ein nettes Werkzeug um z.B. zu löschende Benutzer mit all ihren Daten als Paket vorab zu exportieren oder Daten in ein Testfeld zu übertragen.
  • MailMig Kommandozeilen
    Für die Freunde der Automatisierung können Sie MailMig über Kommandozeilen komplett steuern.

Die Migrationsdateien

Wenn man mit MailMig migriert, dann werden dabei nicht nur die Inhalte übernommen, sondern zum Teil auch die Verzeichnisinformationen. MailMig bedient sich dabei einiger temporärer Dateien. Der Pfad hierzu muss bei der Zweischrittmigration beim Export mit angegeben werden. Beim Import wählen sie dann direkt die Migrationsdateien als Quelle aus. In dem Verzeichnis befinden sich meist folgende Dateien (Hier am Beispiel einer Zweischritt Migration aus Exchange 2003.

In dem Verzeichnis befinden sich folgende Dateien, die alle den Aufbau einer CSV-Datei haben, d.h. eine Tabellarische Struktur mit einem Datensatz je Zeile und durch Komma getrennte Felder.

  • Exch.PKL  (Packing List)
    Dies ist die Hauptdatei, die den Migrationsassistent anweist, welche weitere Dateien er verarbeiten soll. Diese ist für den Einsatz von MailMig zwingend erforderlich

! CodePage
1252
! HeaderLine
Filename,Filetype
Directory.PRI,Primary
00000001.PRI,Primary
00000001.SEC,Secondary

  • Directory.PRI (Primary File)
    Zu jeder Migration gehört eine PRI-Datei, die alle Verzeichnisinformationen enthält. Diese nutzt MailMig um die Benutzer zu "finden" oder Anzulegen und Mailadressen etc. zu erhalten. Anhand der Beispieldatei sieht man gut, welche Felder alle übernommen werden können. Achten Sie aber auch auf die Felder "Match-GUID" und "Owner-SID". Die brauchen wir später noch

! Migration Type
DIRECTORY
! HeaderLine
Obj-Class,Common-Name,Display-Name,Given-Name,Surname,Comment,Secondary-Proxy-Addresses,Mail-Nickname,Obj-User,Match-GUID,Owner-Sid,legacyExchangeDN,ADCGlobalName,Initials,Title,Telephone-Office1,Telephone-Office2,Telephone-Home,Telephone-Home2,Telephone-Mobile,Telephone-Pager,Telephone-Fax,Assistant-Name,Telephone-Assistant,Street-Address,Locality-Name,State-Or-Province-Name,Postal-Code,Text-Country,Company,Department,Physical-Delivery-Office-Name,Extension-Attribute-1,Extension-Attribute-2,Extension-Attribute-3,Extension-Attribute-4,Extension-Attribute-5,Extension-Attribute-6,Extension-Attribute-7,Extension-Attribute-8,Extension-Attribute-9,Extension-Attribute-10,Extension-Attribute-11,Extension-Attribute-12,Extension-Attribute-13,Extension-Attribute-14,Extension-Attribute-15,Description,X-AD-IpPhone,Telephone-Home-Fax,X-AD-OtherIpPhone,Telephone-Personal-Mobile,X-AD-OtherPager,Post-Office-Box,Street-Address,X-AD-OtherWebAddress,WWW-Home-Page,X-AD-CountryAbbr,X-AD-MailboxOwnerList,X-AD-CountryCode,X-AD-mDBStorageQuota,X-AD-mDBOverQuotaLimit,X-AD-mDBOverHardQuotaLimit,X-AD-HideFromAddressLists,X-AD-mDBUseDefaults

MailBox,RUSTest1,RUSTest1,,,,"SMTP:RUSTest1@msxfaq.local%SMTP:RUSTest1@msxfaq.local%X400:c=DE;a= ;p=MSXFAQ;o=Exchange;s=RUSTest1;%x400:c=DE;a= ;p=MSXFAQ;o=Exchange;s=RUSTest1;",RUSTest1,RUSTest1,,S-1-5-21-3830009233-4121518305-2830858423-1111,/o=MSXFAQ/ou=Erste administrative Gruppe/cn=Recipients/cn=RUSTest1,,,,,,,,,,,,,,,,,,,,,,,Terminpatch:18.04.2007 00:58:05,"RUSTest1@msxfaq.local",,,,,,,,,,,,,,,,,,,,,,,,0,,,,,

MailBox,RUSTest2 (Firma),RUSTest2 (Firma),,,,"SMTP:RUSTest2@msxfaq.local%SMTP:RUSTest2@msxfaq.local%X400:c=DE;a= ;p=MSXFAQ;o=Exchange;s=RUSTest2;%x400:c=DE;a= ;p=MSXFAQ;o=Exchange;s=RUSTest2;",RUSTest2,RUSTest2,,S-1-5-21-3830009233-4121518305-2830858423-1112,/o=MSXFAQ/ou=Erste administrative Gruppe/cn=Recipients/cn=RUSTest2,,,,,,,,,,,,,,,,,,Firma,,,,,Terminpatch:18.04.2007 00:58:05,"RUSTest2@msxfaq.local",,,,,,,,,,,,,,,,,,,,,,,,0,,,,,

  • 00000001.PRI  (Primary File)
    In der 00000001.PRI finden sich dann noch mal die Verwaltungsinformationen für die Inhalte. für jedes Postfach in der Directory.PRI gibt es eine Zeile, die einen Verweis auf die PST-Datei samt dem Kennwort zur PST-Datei enthält:

! Migration Type
PST
! HeaderLine
Display-Name,Proxy-Address,Filename,Password
RUSTest1,x500:/o=MSXFAQ/ou=Erste administrative Gruppe/cn=Recipients/cn=RUSTest1,RUSTest1.PST,j5C8ogD5g29bjA
RUSTest2 (Firma),x500:/o=MSXFAQ/ou=Erste administrative Gruppe/cn=Recipients/cn=RUSTest2,RUSTest2 (Firma).PST,t9K9wvh26E94sf

  • 00000001.SEC (Secondary File)
    Wozu das SEC-File erforderlich ist, konnte ich noch nicht klar austesten. MailMig legt diese Datei zwar an, aber der Inhalte ist quasi leer. Ich glaube mich erinnern zu können, dass früher bei Migrationen von MS-Mail und cc:Mail weitere Importdateien vorhanden war. Die Quelldaten müssen nämlich nicht immer aus PST-Dateien kommen.

! HeaderLine
Type,Length,Encoding,Islast,Name,Position,Format

  • PST.PASSWORD
    Diese Datei enthält noch mal die Zuordnung der PST-Dateien und Kennworten. für den Import ist diese Datei aber nicht erforderlich.

Benutzername, PST-Dateiname, Kennwort, E-Mail-Adresse
"RUSTest1", "c:\temp\Exch.001\RUSTest1.PST", "j5C8ogD5g29bjA", "x500:/o=MSXFAQ/ou=Erste administrative Gruppe/cn=Recipients/cn=RUSTest1"
"RUSTest2 (Firma)", "c:\temp\Exch.001\RUSTest2 (Firma).PST", "t9K9wvh26E94sf", "x500:/o=MSXFAQ/ou=Erste administrative Gruppe/cn=Recipients/cn=RUSTest2"

  • *.PST
    Und dann gibt es natürlich noch für jeden Benutzer eine PST-Datei, die seine Nachrichten enthält. Ich habe es noch nicht getestet, aber ich befürchte, dass auch hier das 2GB Limit gilt, da auf dem Server natürlich ein Outlook 2003/2007 installiert ist und damit unicode-PST -Dateien nicht verfügbar sind.

Die Zusammenhänge lassen sich auch bildlich darstellen:

Mehr ist in dem Verzeichnis nicht enthalten. Aufgrund des einfachen Aufbaus ist natürlich auch eine manuelle Anpassung möglich. Man kann z.B. die Mailadressen erweitern, um im Ziel zusätzliche Adressen zu haben oder ein Matching zu erleichtern. Man kann die PST-Dateien auch austauschen.

Bei dem Import in das Ziel, werden Kopien der PKL und PRI-Dateien mit laufender Nummer angelegt, wenn die Option ", nomodify" nicht aktiv ist.

Beim Export kann spezifiziert werden, ob MailMig beim späteren Import die im Ziel gefundenen Active Directory Benutzer mit den Exchange Daten der Quelle aktualisiert oder Benutzer ohne Postfach in Exchange Empfänger konvertiert. Faktisch wird dabei aber nur in der Directory.PRI der Wert "nomodify" addiert:

! Migration Type
DIRECTORY, nomodify
! HeaderLine
Obj-Class,Common-Name,Display.......
MailBox,RUSTest1,RUSTest1,,,,"SM.....
MailBox,RUSTest2 (Firma),RUSTest2 (Firma.....

Dann werden keine Änderungen an den Zielkonten vorgenommen. Zielbenutzer müssen also schon ein Exchange Postfach haben, damit MailMig die Inhalte hinein migriert. Ansonsten werden diese Postfächer nicht im Ziel angelegt. Das kann man aber jederzeit noch einmal nachholen. Einfach das Zielkonto mit einer Exchange Mailbox versehen, eine Mailadresse angeben, die MailMig finden kann und die Migration erneut starten oder sie entfernen den "nomodify"-Eintrag, dann bietet ihnen MailMig den Dialog an, welche Benutzer mit welchen Postfachdaten aktiviert werden sollen.

Wie findet MailMig die Zielkonten (Matching)?

Wir wissen nun, wie die Informationen in den Quelldateien interpretiert werden. Dann fehlt noch das Wissen, wie MailMig die Konten im Ziel zuordnen kann. Dazu nutzt der MailMig folgende Logik, um die Benutzer zuzuordnen.

  • msExchMasterAccountSID
    MailMig erkennt Ressourcenkonten dadurch, dass die Konten unter Exchange 2000/2003 deaktiviert sind und das Konto "SELF" die zugeordnete msExchMasterAccountSID ist. Bei Exchange 5.5 sind dies Konten, in denen "NTDSNOMATCH" in einem der erweiterten Attribute steht. Diese Konten werden niemals für eine Zuordnung genutzt. Hier werden immer neue deaktivierten Konten angelegt.
    Aus der Quelldatei ist das der Inhalt von "Owner-SID"
  • objectSID oder sidHistory
    Dann sucht MailMig nach der SID des Quellobjekts in der SID des Zielobjekts bzw. in der SID-History. Das kann die gleiche SID sein, wenn bei einer Zweischritt Migration erst die Daten exportiert und nach der Neuinstallation der Exchange Organisation die Daten wieder importiert werden. Bei der Migration in einen anderen Forest oder Domäne ist die objectSID zwar die gleich, aber man kann die alte objectSID in der SID-History des Zielobjekts hinterlegen und so MailMig den Weg zeigen. Auch hier orientiert sich MailMig an der "Owner-SID"
  • LegacyExchangeDN als X.500 Adresse
    Wurde immer noch kein Objekt gefunden, dann nutzt MailMig den Inhalt des "LegacyExchangeDN" der Quelle und sucht danach in den ProxyAddresses über die X.500 Adresse. Die X.500 kommt bei der Migration auch in anderer Hinsicht eine wichtige Bedeutung zu, z.B.: dass Mails an die alte Adresse weiterhin zugestellt werden können. Daher sollten Sie bei der Migration in eine anderen Organisation immer darauf achten, dass der LegacyExchangeDN des alten Kontos im Ziel als X500 Adresse hinzu kommt.
  • ProxyAddresses
    Erst dann nutzt MailMig die Informationen aus den "ProxyAddresses" der Quelle und versucht entsprechenden Konten mit gleichen ProxyAddresses im Ziel zu finden.
  • "Migrate:x500:/O=Organisation,/OU=Site/cn=Recipients/cn=alias
    Selbst dann gibt MailMig noch nicht auf und sucht nach mailboxaktivierten Usern, die in den ProxyAddressen, bei denen nun ein "Migrate:x500:" als Prefix vor dem alten LegacyExchangeDN steht.

Entsprechend können Sie nun ermessen, wie wichtig neben der Migration der Postfächer auch die Migration der Benutzer ist. Das bevorzugte Werkzeug hierzu ist natürlich ADMT, um die Benutzer und Gruppen von einem Forest in den anderen Forest zu übertragen. Dann ist sichergestellt, dass die Zielkonten auch die alte SID enthalten. ADMT selbst migriert nämlich nicht einmal die Mailadressen oder andere Exchange Eigenschaften mit.

Mein persönlicher Favorit ist natürlich erst einmal die SID, welche bei der Migration der AD-Benutzer durch ADMT mit übernommen wird und MailMig damit eine eindeutige Zuordnung erlaubt.
Wenn Sie eine "CrossOrg" Migration durchführen, und dabei keine Windows Konten übertragen, dann ist die X.500 -Adresse ein sehr guter primärer Schlüssel. Ich habe mir dazu extra Skripte gebaut, die das MailMig-DIRECTORY.PRI-File auswertet und anhand der ProxyAdressen im Ziel das passende Objekte sucht und den LegacyExchangeDN als X.500 Adresse einträgt.

 Ausgehend von diesen Informationen arbeitet MailMig dann wie folgt:

  • "Passendes" Zielkonto gefunden
    Dann nutzt MailMig dieses Zielobjekt, um eine Mailbox anzulegen und die Inhalte zu importieren, vorausgesetzt, Sie haben beim Export dieses Funktion aktiviert. (Create/Modify Account) oder nachträglich das "Nomodify"-Attribut aus der Datei "Directory.PRI" entfernt
  • Keine Übereinstimmung
    MailMig legt einen deaktiviertes Konto an, erzeugt eine Mailbox, importiert die Inhalte und weist dem Feld "msExchMasterAccountSID" den Wert der SID des aktiven Quellkontos zu. Ist das Quellkonto aktiv, dann wird die SID genutzt. Ist das Quellkonto aber auch schon deaktiviert, dann wird von diesem deaktivieren Konto ebenfalls der Inhalt des Felds "msExchMasterAccountSID" genutzt. Dies ist z.B. in Hosted Umgebungen mit Ressourceforest oder NT4-Domänen der Fall. Siehe auch Exchange 2000 mit Windows NT4.

Das Matching bei einer "Einschritt Migration" sieht vereinfacht wie folgt aus.

Aber damit ist der Einsatzbereich von MailMig noch nicht beendet.

Desaster Recovery

Was häufig nicht bekannt ist, sind die Möglichkeiten von MailMig beim Reimport der Mails zurück in die gleiche Organisation. Dies ist nämlich auch möglich. Man kann präventiv mit MailMig Nachrichten als auch die Verzeichnisinformationen (Mailadresse) aus einer bestehenden Exchange Organisation exportieren und einfach auf der Seite liegen lassen.

Sollte zu einem späteren Zeitpunkt z.B. auffallen, aufgrund einer Fehlbedienung dass bei Benutzern Mailadressen verloren gegangen sind, so kann man einfach über MailMig diese Daten wieder herstellen. Natürlich kann man das gleiche auch durch einen Export per LDIFDE und etwas Anpassungen wieder einen Import erreichen.

Achtung: Dabei werden aber nur fehlende Adressen addiert aber die primäre Adresse wird nicht korrigiert. Eventuell hilft ihnen für eine solche Absicherung auch das Skript SMTP Backup Restore.

Auch die Inhalte werden durch MailMig in PST-Dateien exportiert und können später wieder importiert werden. Aber auch hier ist MailMig keine Alternative zu einem guten Backup des Exchange Servers oder einer professionellen Archivlösung.

Mailmig und Quota

MailMig beachtet im Zielpostfach die die Quota-Einstellungen und bricht dem Import des jeweiligen Postfachs ab. Der Abbruch ist am Ende im Eventlog zu finden.

Event Type:       Error
Event Source:     MSExchangeMig
Event Category:   None
Event ID:         13008 User:                    N/A
Description:
The migration of ''Carius, Frank'' has been stopped after 134 messages
The mailbox quota has been exceeded.

Für die Postfächer, die so nicht importiert werden, legt MAILMIG eine neue Importdatei an, so dass der Korrektur des Fehlers der Import für die fehlerhaften Postfächer direkt wieder gestartet werden kann.

Kommandozeilenoptionen

Neben dem direkten Aufruf über das Menü kann MailMig natürlich auch mit verschiedenen Kommandozeilen gestartet werden.

  • /F
    Diagnosefunktionen
    Die DiagnoseMöglichkeiten des Migrationsassistenten sind sehr begrenzt. Allerdings liefert der Schalter nur bei Migrationen aus Exchange Systemen zusätzliche Hinweise. Ansonsten sind Sie auf die Meldungen im Windows Eventlog angewiesen.
  • /M
    Normalerweise läuft MailMig im "COPY" Mode, d.h. die Mails werden in das neue Zielpostfach kopiert. Die Option "/m" aktiviert den Clone Mode, so dass auch die GUID für die OST-Datei mit übernommen wird. Wenn Sie dann auf dem Desktop das Profil mit "EXPROFRE" anpassen, dann kann die OST-Datei weiter verwendet werden.
    Siehe auch http://blogs.technet.com/b/exchange/archive/2004/08/25/220305.aspx
  • /A:domain\Username /P:password
    Erlaubt die Angabe von Anmeldedaten. Hilfreich, wenn Sie MailMig mit abweichenden Berechtigungen oder mehrere parallele Instanzen starten wollen.
  • /c:controlfile
    Sie können MailMig über eine Datei parametrisieren. Details siehe "883408 How to run multiple instances of the Migration Wizard in Microsoft Exchange Server 2003"

Weitere Links