Hallo zusammen,
bei mir steht eine Migration von 140 Postfächern an, die ein Gesamtvolumen von 450GB haben. Die Anzahl der Elemente gehen wohl in die Millionen. Der Umzug ist über die Osterfeiertage geplant. Ich habe also 4 Tage Zeit. Wir werden das Tool Kernel Migrator for Exchange - Express Edition einsetzen um alles zu migrieren. Um möglichst zügig die Postfächer durchzumigrieren habe ich an 20 Virtuelle Maschinen gedacht auf die ich die Postfächer aufteile. So kann ich parallel migrieren.
Ich habe Sorge das mir die Datenbank um die Ohren fliegen wird. Ich verteile die Postfächer gleichmäßig auf zwei Datenbanken. Seht ihr da Probleme vor diesen Massen an Elementen? In Betrieb sind zwei Exchange 2019 Server, die beide im DAG Verbund arbeiten und sich also permanent abgleichen.
Bei ersten Belastungstests mit 20 GB Postfächern und 75.000 Elementen habe ich bemerkt, dass die Länge der Kopiewarteschlange/CopyQueue in die tausende geht. Wird das im großen Stil irgendwann kritisch? Macht hier Umlaufprotokollierung Sinn? Ich habe überlegt, in den ersten beiden Tagen die Daten zu migrieren und den letzten beiden Tagen dem Server Zeit zu geben, um sich zu beruhigen und die CopyQueue abzuarbeiten.
Bin auf eure Erfahrungen und Ratschläge gespannt ?
Liebe Grüße
Hi,
nun, es gibt unterschiedliche Auffassungen von großen Migrationen :). Allerdings schreibst du nicht, wie genau du planst zu migrieren, zumindest erschließt es sich mir nicht.
Machst du eine Cross Org Migration, in der Quelle und Ziel per Trust angebunden sind, dann könnte man ja bequem mit Moverequests arbeiten. Ich kenne das Tool nicht, was du einsetzen willst, es klingt aber eher danach, als wolltest du eine Stichtagsmigration machen, aber auch dann wäre interessant, ob die Quelle ebenfalls ein Exchange Server ist.
In jedem Fall würde ich für den Zeitraum der Migration im Ziel die Umlaufprotokollierung einschalten, sonst läuft dir auch mal schnell die Log Partition voll.
Hast du Enterprise oder Standard lizensiert? Wenn Standard, dann geht in der DAG nicht mehr wie deine 2 DB's inkl. einer Kopie, das ist richtig. Insofern kommt es dann auf schnelle Platten bzw gescheites RAID an. Wenn du Enterprise hast, dann auf jeden Fall mit mehr DB's arbeiten, um die Moves besser verteilen zu können.
Solltest du wie gesagt die Möglichkeit eines Trusts haben und die Quelle auch ein Exchange sein, würde ich in jedem Fall mit Crossorg Moverequests arbeiten. Hie rhast du die Möglichkeit, das ganze im Hintergrund vorzusyncen und dann immer nur die Deltas zu syncen. An Umstellungstag kannst du locker alle Maiboxen final umstellen und wenn was nicht klappt, auch wieder zurückmigrieren (Worstcase, solltest du vorher nicht getestet haben).
Wie gesagt, schreib ein wenig mehr, was in Quelle und Zeil vorhanden ist und auch die Verbindung zwischen den beiden kann ein limitierender Faktor sein (VPN Anbindung etc).
Gruß,
Ralf
Hallo Ralf,
hupsi, da habe ich wohl eine Menge Infos vergessen.
Der Plan ist von einem Hosted Exchange Anbieter zu einem selbst gehosteten Exchange umzuziehen. Demnach also Cross Forest Migration.
Da wir beim Hosted Exchange Anbieter nur sehr eingeschränkt handeln können, gestaltet sich der Umzug auch etwas schwieriger. Wir migrieren tatsächlich mit einer Liste an E-Mail Adresse+Passwort, da wir auf der Quell-Seite keinen Admin Account haben. Auch gibt es zwischen Quelle und Ziel keine direkte Verbindung. Die Überlegung mit Vormigrieren ist wirklich clever. Ich glaube das werde ich favorisieren.
Ich bin wirklich nicht begeistert von Hosted Exchange sobald die Zahl der Postfächer größer wird. Der Verwaltungsaufwand über ein lahme Weboberfläche des Anbieters ersetzt keine simple Verwaltung über die Powershell. ?
Beste Grüße
Ich habe Sorge das mir die Datenbank um die Ohren fliegen wird. Ich verteile die Postfächer gleichmäßig auf zwei Datenbanken. Seht ihr da Probleme vor diesen Massen an Elementen?
Die Exchange DBs interessiert das nicht. Während der Migrationsphase einfach die umlaufprotokollierung aktivieren. Danach wieder deaktivieren. 450GB ist jetzt nicht so groß.
Wenn Standard, dann geht in der DAG nicht mehr wie deine 2 DB's inkl. einer Kopie, das ist richtig.
Nein das ist nicht richtig. Die Standard Edition kann pro Server 5DBs. Ob das aktive oder passive sind ist egal. Also kann man 5 DBs in einer DAG aus Standard Servern haben. Die Anzahl der Kopien ist egal. Aufpassen, bei Standard ist die DB Grösse „nur“ 1TB und danach lässt sich die DB nicht mehr mounten. Hatte schon den Fall beim Kunden. ;)
Demnach also Cross Forest Migration.
Nein dann hättet ihr einen Trust und alles wäre einfacher. ;)
das was ihr macht ist quasi cutover mittels 3rd party tool. Die meisten Tools die ich kenne, bieten allerdings die Option den Sync zyklisch durchzuführen, und dann ist der Datentransfer am umschalttermin ausreichend gering.
@Norbert,
du hast recht wegen den 5 DB's in DAG, ich hab es falsch in Erinnerung. Heißt aber für Gallahead auch, er kann seine Last auf bis zu 5 DB's aufteilen im Ziel.
Ich würde definitiv vormigrieren, wenn es irgendwie geht. Gerade, wenn die Usermailboxen sehr viele kleine Elemente haben, ist das manchmal bei Stichtag schlimmer, als wenn es große Mailboxen mit verhältnismäßig wenigen Elementen, dafür aber große Mails sind. Keine Ahnung, ob das Tool per IMAP, EWS oder sonstigem die Verbindung aufbaut. Vielleicht, wenn per EWS, dann auf die Throttling Policy des/der Migrationsuser achten, nicht das Exchange die Zugriffe einschränkt.
Gruß,
Ralf
@Gallahead,
wenn du eh von den Usern die Daten hast, dann migriere vorab in PST's bis zum Datum XY, das kannst du dann bereits auf dem Ziel importieren per PS. Am Stichtag dann nur noch die letzten X Tage als Delta und dann biste auch zügig fertig. 450 GB sind a quasi nix ... :)
Ralf
Hallo,
habt ihr schon mal ein Migrations-Tool verwendet? Ich habe mit zwei Tools ausgiebig rumgetestet und bin recht enttäuscht von dem Tool "edbMails" und "Kernel Migrator for Exchange". Bei so einer Sache erwarte ich ein Fehlerfreies Werkzeug. Leider schaffen es beide Tools nicht alle Elemente vollständig und Fehlerfrei zu übertragen. Das Tool von Kernel vergisst einfach Teilnehmer beim Meeting zu migrieren und bekommt es seit zwei Monaten nicht behoben. Nachverfolgungsfähnchen fehlen auch einfach so. ?
Dadurch, dass ich beim Quell-Server keinen zentralen Admin Account habe bin ich recht eingeschränkt. Viele Tools bauen auf Administrator-Konten auf. Ich habe lediglich eine Liste mit den Zugangsdaten, die ich nach Möglichkeit einfach importieren kann, Quelle & Ziel Postfach mappen und die Übertragung starten. Ich finde eure Idee mit dem Vorsyncen recht gut, also müsste das Tool auch entsprechend inkrementell arbeiten können. Ich bin überrascht, dass viele Tools auf dem Markt so sehr eingeschränkt sind oder unglaublich kompliziert aufgebaut sind. Habt ihr mit solchen Tools Erfahrung?
Natürlich darf ein gutes Werkzeug auch Geld kosten ?
Liebe Grüße
ich habe mit dem hier gearbeitet, wenn keine Migration mit Boardmitteln möglich war.
https://www.quest.com/products/migration-manager-for-exchange/
Das kostet auf jeden Fall Geld und man sollte sich überlegen, ob es das inklusive einer sauberen Implementierung wert ist für den überschaubaren Rahmen (bezogen auf die zu migrierende Datenmenge).
Gruß,
Ralf