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.

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:

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:

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 wandert 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.:

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 for 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

Keywords:Quest Migration