Quest Migration Manager für Exchange

Für die Migration von Postfächern zwischen Organisationen müssen mehrere Dinge harmonisch zusammen spielen, da ansonsten Mails unzustellbar, Daten vergessen oder im schlimmsten Fall verloren gehen. Wenn eine Migration nicht innerhalb weniger Stunden durchgezogen werden kann, dann muss die Koexistenz längere Zeit aufrecht erhalten werden, was nicht trivial ist. Bis zu einem bestimmten Grad können Sie mit Exchange Bordmitteln und PowerShell Skripten arbeiten. Ein recht weit verbreitetes Migrationswerkzeug im Markt ist der Quest Migration Manager.

Auf dieser Seite möchte ich exemplarisch darstellen, welche Leistungen eine Drittsoftware gegenüber Bordmitteln erbringen kann. Die Wirtschaftlichkeitsrechnung ist aber immer eine individuelle Bewertung und Entscheidung.

Abgrenzung zur "Bordmittelmigration

Eine Migration mit Quest ist dann zu überlegen, wenn die Migration zwischen Organisationen ansteht. Eine Migration innerhalb der gleichen Exchange Organisation ist hingegen kein Ziel. Auch wenn Microsoft bei der Migration immer "besser" wird und speziell mit Office 365 einige neue interessante Ideen bereit stellt, so kann Quest z.B.: an vielen Stellen durch Mehrwerte punkten. Welche Gewichtung und und letztlich Kosten und Nutzen dies im individuellen Fall bedeutet, ist situationsabhängig.

  • DirSync der Elemente
    Bordmittel ersetzen kein FIM oder IIFP und Prepare-MoveMailbox von Exchange 2010 verwaltet nur Mailboxen aber keine Kontakte, PublicFolder, Verteiler.
  • Inhaltsreplikation mit Konsolidierung über Standortgrenzen
    Zwar kennt Exchange 2010 mittlerweile auch einen "Move-Mailbox mit SuspendMove", aber das ist nicht vergleichbar zu einer granularen und steuerbaren Belastung durch elementweise Replikation mit Drosselung und Zeitplanung
  • PublicFolder
    Mal abgesehen von EXMERGE und IOREPL gibt es keine Hilfsmittel, um Inhalte aus öffentlichen Ordnern zu übertragen. Die Übertragung von Berechtigungen ist vom Einsatz von Exfolders und PFDavAdmin abhängig und Mailadressen von Ordnern werden nicht bedient. Da kann Quest natürlich punkten.
  • Parallelbetrieb
    Viele kleine Funktionen von Quest sind auch auf eine längere parallelen Betriebszeit ausgelegt. Wenn die Migration also nicht innerhalb eines klar begrenzten Zeitraums über die Bühne gehen soll, sondern womöglich jahrelang zwei oder mehr Organisationen parallel existieren, dann werden Sie Quest oder andere Zusatzprodukte suchen.
  • Firewalls und LANs
    Viele Prozesse der Bordmittel nutzen RPC und umfangreiche Ports. Quest beschränkt sich natürlich für den DirSync auf LDAP und die Daten werden per "Filecopy" zwischen bestimmten Servern übertragen.
  • MAPI Profil Umstellung
    Gerate auf älteren Clients ohne Autodiscover ein kniffliges Thema. Wer mit Profile Tools nicht zurecht kommt, wird die Hilfsmittel des QMM schätzen.
  • Migration von alten Quell-Versionen und anderen Systemen
    Mit Exchange 2010 unterstützt Microsoft nur noch die Migration von Exchange 2003/2007/2010 nach Exchange 2010. Wer von Exchange 2000 oder älter oder anderen Systemen wie z. B. Notes migrieren muss, muss entweder Exchange 2007 mit betreiben oder Drittprodukte einsetzen.
  • Verwaltung und Monitoring
    Auch wenn die Funktion mit den Microsoft Portmitteln vergleichbar ist so liefert Quest natürlich eine integrierte Console für die Verwaltung der Bausteine und ein Reporting. All das sind bei Bordmitteln dann natürlich wieder Handarbeit (Listen) oder PowerShell Auswertungen

Und das sind erst mal nur die Punkte, die leicht zu beschreiben und zu verstehen sind.

Arbeitsweise Quest Migration Manager

QMM erlaubt die langsame Migration und Koexistenz von zwei Exchange Organisationen, indem drei wesentliche Funktionen integriert bereit gestellt werden:

  • Verzeichnisabgleich mit Weiterleitung
    Zu jedem Postfach in der Quelle wird Initial ein Kontakt im Ziel angelegt, der mit dem Start der Replikation zu einem Postfach konvertiert wird. Dies kann ein deaktiviertes Konto sein, so dass auch später nach der Umstellung der Anwender mit dem alten Anmeldekonto arbeiten kann. Alternativ kann auch ein bestehender Anmeldebenutzer „Postfachaktiviert“ werden. In beiden Fällen werden vorhandene Postfächer im Ziel gelöscht und die Weiterleitung an die Quellmailbox über das Feld „TargetAddress“ eingestellt. Welche sonstigen Felder aus der Quelle nicht übernommen werden kann eingestellt werden. Die Daten eines eventuell vorhandenen Kontakts, der bisher das Postfach in der Quelle aus dem Ziel erreichbar gemacht hat, werden zusammengeführt, sofern QMM den Kontakt als solches zuordnen kann.
  • Verteilerabgleich mit Mitgliedern
    Zusätzlich werden alle Gruppen der Quelle ebenfalls im Ziel angelegt und die Mitglieder anhand der synchronisierten Postfächer gefüllt. Die Daten eines eventuell vorhandenen Kontakts, der bisher einen Verteiler in der Quelle aus dem Ziel erreichbar gemacht hat, werden zusammengeführt, sofern QMM den Kontakt als solches zuordnen kann.
  • Replikation von Postfachinhalten, Kalenderdaten und öffentlichen Ordnern
    Nach erfolgtem Abgleich werden einstellbar die Inhalte aus Postfächern, Kalendern und öffentlichen Ordnern von der Quelle in das Ziel repliziert. Die Mitarbeiter können weiter in der Quelle arbeiten und QMM führt das Ziel etwas verzögert mit. PostfachÄnderungen im Ziel sollten aber unterbleiben. Ebenso werden öffentliche Ordner Inhalte repliziert.
    Termine im Kalender werden direkt abgeglichen, um den Zeitverzug gering zu halten.

Nach einiger Zeit sind alle Informationen parallel in der ZielUmgebung aufgebaut worden, so dass Postfachweise oder auch als Block die Benutzer auf den neuen Server umgestellt werden können. Hierbei unterstützt QMM mit einer Clientsoftware (EMWProf), welche das Outlook Profil anpasst, sobald es den Befehl zum „Switch“ in der Quellmailbox findet.

So ist eine schleichende, ressourcenschonende und risikoarme Migration möglich, bei der zudem auch Berechtigungen, Stellvertreter etc. sauber übertragen werden und eine Migration sogar über Standortgrenzen hinweg mit beschränkter Bandbreite erfolgen kann (-> Konsolidierung).

Blick hinter die Kulissen

QMM nutzt für die Aufgaben eine verteilte Struktur von Agenten, welche weitestgehend autark arbeiten. Die Steuerung und Konsolidierung der Ergebnisse übernimmt eine zentrale Konsole, die auf einem PC oder Server installiert wird und sowohl eine ADAM als auch eine SQL-Datenbank betreibt. Auf die Quell- und Zielserver werden von der Konsole aus Agenten verteilt. die eine lokale AccessDatenbank als Konfigurationsquelle nutzen und ansonsten an der zentralen Konsole vorbei mit den jeweiligen Partnern kommunizieren.

Folgende Agenten arbeiten zusammen:

  • DSA - Directory Service Agent
    Dieser zentrale Agent läuft meist auf der Konsole mit und verbindet sich per LDAP mit beiden Verzeichnisdiensten, um die Objekte abzugleichen. Dazu nutzt er eine lokale ADAM-Datenbank als Synchronisationshilfsmitteln
  • MSA - Mail Source Agent
    Diese Komponente extrahiert die konfigurierten Postfächer und speichert den Export in PST-Dateien lokal ab
  • PFE - Public Folder Exportagent
    Analog zu den Postfächern extrahiert dieser Agent die Inhalte von öffentlichen Ordnern in PST Dateien und legt diese ab
  • TA - Transport Agent
    Dessen Aufgabe ist es die PST-Dateien des MSA und PFE an den richtigen Zielserver zu übertragen und dann lokal zu löschen. Auf den Zielservern gibt es dazu entsprechende Dateifreigabe, QMM nutzt einfach SMB zur Übertragung
  • MTA - Mail Target Agent
    Auf dem Zielserver ist dieser Prozess dafür zuständig, die erhaltenen PST-Dateien in die jeweiligen Postfächer einzufügen
  • PFI - Public Folder Import Agent
    Analog verfährt der PFI mit den Inhalten aus öffentlichen Ordnern
  • CAL - Calender Agent
    Eine Sonderstellung hat der Agent, der explizit nur die Kalendereinträge der konfigurierten Postfächer überträgt. Da dies "schnell" gehen muss, kommuniziert dieser Agent ähnlich wie IOREPL direkt per MAPI mit den beiden Servern.

Die zentrale SQL-Datenbank enthält die Lizenz, die Konfiguration und dient als Quelle für Reports. Die Agenten greifen aber nur zur Prüfung der Lizenz auf den SQL-Server zu. Konfiguration und Statistik werden lokal in Access Datenbanken abgelegt. Die zentrale Konsole pusht die Konfiguration über LAN in die Accessdatenbank und stoppt dazu vorher die lokalen Dienste auf dem Server.

Verzeichnisse und Dateien

Am Beispiel der Synchronisation von Postfächern möchte ich die Stationen der Inhalte aufzeigen. Dann können Sie auch schnell überprüfen, wo vielleicht ihre Dateien gerade hängen. Die Abkürzungen bedeuten:  MSA = Mail Source Agent,  NTA=Transfer Agent,  MTA=Mail Target Agent. Diese Namen und Abkürzungen nutzt Quest selbst auch wenn die Bezeichnung als MTA immer etwas irreführend ist.

  1. Quelle:MSA exportiert nach \Mail Source Agent\PST\<UNiqueID>.PST
  2. Quelle:MSA packt PST in PRV mit zusätzlichen Metadaten
  3. Quelle:MSA verschiebt nach Transport Agent Verzeichnis \Mail Transmission Agent\OUT\<Zielservername>
  4. Quelle:NTA verschiebt \Mail Transmission Agent\Out\Zielserver -> Zielserver \Mail Transmission Agent\In\Quellservername
  5. Ziel:MTA überwacht PRV-Dateien in \Mail Transmission Agent\In\Quellservername
  6. Ziel:MTA Importiert PST in Zielpostfach

Die Datei wändert also quasi durch das Dateisystem. Es ist eine gute Idee, die Verzeichnisse zu überwachen z.B.: auf die Anzahl der Objekte, die Größe und natürlich das Alter, so dass Sie bei Unterbrechungen oder Verzögerungen sehr schnell bescheid bekommen.

Wichtige Information an Administratoren auf beiden Seiten

Der Verzeichnisabgleich und die Replikation von Mailboxen und öffentlichen Ordnern erfordert einige Abstimmungen mit den Administratoren. Während der Koexistenz dürfen bestimmte Dinge nicht verändert werden bzw. müssen bei der Konfiguration beachte werden, z.B.:

  • Quelle: AD-Objekte
    Beim DirSync werden OUs ausgewählt und optional ausgeschlossen, die in den Abgleich mit einbezogen werden. Werden OU-Strukturen „geändert“, dann muss der DirSync-Job entsprechend angepasst werden, d.h. ohne Rücksprache sollten z.B. keine user verschoben, gelöscht oder OUs angelegt werden
  • Quelle: Public Folder
    Synchronisierte Ordner dürfen in der Struktur nicht verschoben werden, da die Replikation am „Pfad“ und nicht an internen GUID festgemacht wird.
  • Ziel: Keine Mirror-Mailboxen verschieben
    Solange die Postfächer repliziert werden, dürfen diese Mailboxen nicht auf andere Datenbanken im Ziel verschoben werden. Dies löscht bis Exchange 2010 RTM zum einen die wichtige Weiterleitung per TargetAddress und der DirSync wird die Mailbox beim nächsten Abgleich wieder in die Datenbank zurückschieben, die in der Kollektion hinterlegt ist.

Insofern müssen nach der Integration in die Umgebung entsprechende Vorgehensweisen berücksichtigt werden.

QMM und ADMT

Wer die Benutzer nicht mit dem "Migration Manager für Active Directory" migriert, sondern stattdessen ADMT verwendet, kann beim Verzeichnisabgleich in Probleme laufen. ADMT migriert by Default leider auch Felder wie "MailNickname, HomeMTA, HomeMDB" und einige andere mit. (Siehe auch ADMT). Der Verzeichnisabgleich von Quest funktioniert aber derart, dass er Benutzer im Ziel anhand der Mailadresse, SamAccountName oder SIDHistory findet und dann auf einer Datenbank mit einer Mailbox samt Weiterleitung (TargetAddress) versieht. Wenn das Zielkonto aber Augenscheinlich schon ein Postfach hat (auch wenn die Felder vollkommen ins Nirvana zeigen), dann schreibt der Verzeichnisabgleich nicht mehr die korrekten Werte.

Auch das Setzen von ForbidDelMailbox bzw. ForbidDelMailbox (Siehe SOL66901 Existing target mailboxes may be deleted by the Mail Target Agent) hilft nicht, da diese Einstellungen erst später beim Übertragen der Inhalte vom Mailbox Target Agent ausgewertet werden.

Auf jeden Fall ausgeschlossen werden sollte daher "mailnickname,publicdelegate,publicdelegatebl,homemdb,legacyexchangedn". Diese Felder werden von Quest besser gesetzt.

Einschätzung

Ich würde QMM nicht beschreiben, wenn ich es nicht selbst einsetzen würde. Diese Seite kann nur einen kurzen Abriss der Möglichkeiten geben und nicht wirklich die Bandbreite des Produkts darstellen. Zudem gibt es ja nicht nur "die eine Migration" sondern manche Firmen migrieren zu erst die Benutzerkonten (ADMT) und dann Exchange, andere müssen zuerst Exchange harmonisieren und die Benutzer nachmigrieren. Eine Migration ist also immer ein individuelles Projekt.

Und QMM ist ein sehr leistungsfähiges Werkzeug, welches seine Kosten auch wieder einspielen kann, wenn es richtig eingesetzt wird. Und da habe ich oft den Eindruck, dass einige Firmen sich hier verschätzen. QMM löst viele Aufgabenstellungen sehr elegant aber allein die Installation reicht nicht aus. Die Migration muss durch Personen "betrieben" werden. Wenn diese Personen mit der passenden Einweisung die Umstellung vornehmen, dann ist das Ergebnis sehr hochwertig. Wer daher nicht selbst migrieren kann, sollte einen passenden Dienstleister auswählen. Quest gibt hier sicher entsprechende Hinweise.

Weitere Links