In Teil 3 der Artikelserie “Migration von Exchange 2016 zu Exchange 2019” ist nun die Migration der Daten dran. Ganz konkret geht es um das Verschieben der verschiedenen Postfächer und öffentlichen Ordner von Exchange 2016 zu Exchange 2019.
Ich verschiebe hier die verschiedenen Postfachtypen einzeln, wenn keine Öffentlichen Ordner oder Shared Mailboxes (Freigaben)eingesetzt werden, können die entsprechenden Punkte natürlich übersprungen werden. Wichtig ist jedoch die Migration der Systempostfächer und natürlich der Benutzerpostfächer.
Wenn es nur wenige Postfächer gibt, können auch alle Postfächer in einem Rutsch migriert werden. Dazu können dann die entsprechenden Befehle einfach nacheinander eingegeben werden. Die im folgenden beschriebenen MoveRequests werden dann entsprechend abgearbeitet.
Migration der Systempostfächer
Bevor die Postfächer der Benutzer und Öffentlichen Ordner verschoben werden, müssen zunächst die Exchange Systempostfächer in die neue Datenbank verschoben werden. Mit dem folgenden Befehl lassen sich die Postfächer der Exchange 2016 Datenbank anzeigen:
get-mailbox -Database DB2016 -Arbitration
Diese Postfächer müssen nun in die Exchange 2019 Datenbank verschoben werden. Dafür kann der folgende Befehl verwendet werden:
get-mailbox -Database DB2016 -Arbitration | New-MoveRequest -TargetDatabase DB2019
Der Status lässt sich mit folgendem Befehl prüfen:
Get-MoveRequest
Nach kurzer Zeit, sollten sich alle MoveRequest im „Status “Completed” befinden:
Da die Systempostfächer nun schon verschoben wurden, können die Moverequests entfernt werden:
Get-MoveRequest | Remove-MoveRequest
Weiter geht es mit den Benutzerpostfächern.
Migration der Benutzerpostfächer
Nachdem die Systempostfächer verschoben wurden, kann mit dem Verschieben der Benutzerpostfächer begonnen werden.
Ich empfehle hier die Trennung zwischen Benutzer- und Shared Mailboxes (auch Raum und Gerätepostfächer). In der Regel gibt es weniger Probleme, wenn Benutzer mit Postfach auf der neueren Exchange Version auf Shared Mailboxes der älteren Exchange Version zugreifen. Daher verschiebe ich die Shared Mailboxes erst nach den Benutzerpostfächern.
Postfächer lassen sich grundsätzlich via Exchange Management Shell und Exchange Admin Center (EAC) verschieben. Ich nutze bisher immer noch das CMDLet “New-MoveRequest” anstelle der Migration Batches, da ich den Eindruck habe, dass die MoveRequest deutlich schneller sind als die Migration Batches (diese werden standardmäßig von der EAC erstellt, können aber auch via Shell erstellt werden). In diesem Beispielen verwende ich die Shell und das CMDLet “New-MoveRequest”, ein weiteres Beispiel für Migration Batches findet sich am Ende des Abschnitts.
Mit dem folgenden Befehl lassen sich alle Benutzerpostfächer in der Exchange 2016 Datenbank anzeigen:
Get-Mailbox -Database DB2016 -RecipientTypeDetails UserMailbox
Wenn nun alle Benutzerpostfächer in einem Rutsch aus der Exchange 2016 Datenbank “DB2016” in die Exchange 2019 Datenbank “DB2019” verschoben werden sollen, kann dazu der folgende Befehl verwendet werden:
Get-Mailbox -Database DB2016 -RecipientTypeDetails UserMailbox | New-MoveRequest -TargetDatabase DB2019
Alternativ lässt sich natürlich auch etwas filtern, sollen beispielsweise nur Benutzerpostfächer aus einer bestimmten OU verschoben werden, kann dazu der folgende Befehl verwendet werden:
Get-Mailbox -Database DB2016 -RecipientTypeDetails UserMailbox | where {$_.OrganizationalUnit -match "frankysweblab.de/FrankysWeb"} | New-MoveRequest -TargetDatabase DB2019
Mittels des WHERE-CMDLets lassen sich hier nahezu beliebige Konstellationen an MoveRequests zusammen stellen.
Wie auch immer die MoveRequests aufgebaut werden, alle Benutzerpostfächer der Exchange 2016 Datenbanken müssen in die Exchange 2019 Datenbanken verschoben werden und dann auch den Status “Completed” aufweisen:
In einer frischen Testumgebung funktioniert das Verschieben meist problemlos, in produktiven Umgebungen gibt es jedoch immer mal wieder fehlerhafte Elemente in den Postfächern. Ohne den Parameter “BadItemLimit” bricht ein MoveRequest beim ersten fehlerhaften Element einfach ab und das Postfach wird nicht verschoben.
Mit dem Parameter “BadItemLimit” lässt sich die Anzahl an tolerierbaren Fehlern festlegen, fehlerhafte Elemente werden dann nicht mit in die neue Datenbank kopiert. Defekte Elemente sind also im Zielpostfach nicht mehr verfügbar und müssen ggf. aus der Datensicherung wiederhergestellt werden. Da aber defekte Elemente ohnehin nicht in die neue Datenbank verschoben werden können, hilft hier meist nur die Angabe des Parameters “BadItemLimit” (Anzahl tolerierbarer Fehler):
Get-Mailbox -Database DB2016 -RecipientTypeDetails UserMailbox | New-MoveRequest -TargetDatabase DB2019 -BadItemLimit 50
Ich habe nun alle Benutzerpostfächer per Shell in die Exchange 2019 Datenbank verschoben, alternativ lasen sich die Postfächer auch per EAC verschieben.
Nachdem die MoveRequests abgeschlossen wurden, können sie gelöscht werden:
Get-MoveRequest | where {$_.status -eq "Completed"} | Remove-MoveRequest
Alternative: Migration Batches via EAC
Postfächer lassen sich auch per Exchange Admin Center (EAC) in die neue Datenbank verschieben. Hier mal ein kleines Beispiel:
Aus der Liste der Postfächer können nun die zu verschiebenden Postfächer ausgewählt werden. Bei vielen Postfächern ist dies natürlich recht mühsam (es ist daher einfacher Migration Batches oder MoveRequests via Shell zu erstellen):
Der neue Migration Batch benötigt einen frei wählbaren Namen und die Zieldatenbank:
Zum Schluss kann noch ausgewählt werden, welcher Benutzer einen Bericht des Migrationbatches erhalten soll. EAC weist schon darauf hin, dass der Migrationbatch nichts für Ungeduldige ist:
Der neue Migration Batch erhält zunächst den Status “Synchronisierung”, hier ist dann Geduld gefragt:
Nach Abschluss wechselt der Migration Batch dann in den Status “Abgeschlossen”:
Sobald der Migration Batch abgeschlossen ist, kann er gelöscht werden.
Migration der Shared Mailboxes (auch Räume und Geräte)
Nachdem die Benutzer Postfächer verschoben wurden, können auch Shared Mailboxes, Raumpostfächer und Gerätepostfächer verschoben werden. Das Vorgehen ist hier fast identisch zu den Benutzerpostfächern. Hier der Befehl zum Anzeigen der entsprechenden Postfächer:
get-mailbox -Database DB2016 -RecipientTypeDetails Shared, Roommailbox, EquipmentMailbox
In diesem Fall ist es nur ein Postfach, auch für dieses Postfach lässt sich nun wieder ein MoveRequest erstellen:
get-mailbox -Database DB2016 -RecipientTypeDetails Shared, Roommailbox, EquipmentMailbox | New-MoveRequest -TargetDatabase DB2019
Wie gehabt lässt sich auch hier wieder bei Bedarf filtern oder die Postfächer via EAC verschieben, genau wie bei den Benutzerpostfächern.
Auch die MoveRequests für die Shared Mailboxes sollten den Status “Completed” haben, wenn sie erfolgreich verschoben wurden:
Die entsprechenden MoveRequest können nun wieder entfernt werden:
Get-MoveRequest | where {$_.status -eq "Completed"} | Remove-MoveRequest
Weiter geht es mit den Öffentlichen Ordnern.
Migration der Öffentlichen Ordner
Das Gute vorweg, seitdem es keine Öffentliche Ordner Datenbank mehr gibt, sondern mit Exchange 2013 Öffentliche Ordner Postfächer eingeführt wurden, muss keine lästige Replikation der Öffentlichen Ordner mehr eingerichtet werden. Die Postfächer für Öffentliche Ordner lassen sich nun auch ganz einfach per MoveRequest oder Migration Batch verschieben.
Das Vorgehen ist nahezu identisch zu Benutzer- und Shared Mailboxes. Hier der Befehl zum Anzeigen:
get-mailbox -Database DB2016 -PublicFolder
Und hier der Befehl zum Verschieben:
get-mailbox -Database DB2016 -PublicFolder | New-MoveRequest -TargetDatabase DB2019
Auch dieser MoveRequest erhält den Status “Completed” sobald alle Daten migriert wurden:
Sobald dies erfolgreich war, kann auch dieser Request gelöscht werden:
Get-MoveRequest | where {$_.status -eq "Completed"} | Remove-MoveRequest
Jetzt fehlt nur doch die Discovery Search Mailbox.
Migration Discovery Search Mailbox
Auch für die Discovery Search Mailbox ist das Vorgehen nahezu identisch zu den anderen Postfächern, hier wieder der Befehl zum Anzeigen:
get-mailbox -Database DB2016 -RecipientTypeDetails DiscoveryMailbox
Und der Befehl zum Verschieben:
get-mailbox -Database DB2016 -RecipientTypeDetails DiscoveryMailbox | New-MoveRequest -TargetDatabase DB2019
Sobald auch hier der MoveRequest abgeschlossen wurde, kann die Anforderung entfernt werden:
Get-MoveRequest | where {$_.status -eq "Completed"} | Remove-MoveRequest
Jetzt sollten alle Postfächer des Exchange 2016 Servers verschoben sein.
Nachtrag
Das Verschieben der Postfächer lief bei mir natürlich sehr schnell, einfach weil kaum Daten in den Postfächern lagen. Im Normalfall dauert natürlich gerade das Verschieben der Benutzer, Shared und ggf. Öffentlichen Ordner Postfächer recht lange. Dies ist abhängig von den Elementen im Postfach und der Größe des Postfachs. Damit man die Geschwindigkeit ungefähr einschätzen kann, sollten zunächst ein paar große Testmailbox verschoben werden. So lässt sich die Dauer besser abschätzen die insgesamt benötigt wird.
Mit dem folgenden Befehl erhält man auch weitere Statistiken zu den MoveRequests:
Get-MoveRequest | Get-MoveRequestStatistics
Es ist auch nicht weiter ungewöhnlich, dass gerade große Postfächer defekte Elemente enthalten, mittels dem Schalter “-BadItemLimit” lässt sich die tolerierbare Anzahl an defekten Elementen einstellen. Ich würde hier für jeden MoveRequest den Parameter auf 10 Elemente setzen (siehe Abschnitt “Migration der Benutzerpostfächer”). Der Wert lässt sich übrigens auch im Nachhinein noch festlegen, dies ist aber Bestandteil des letzten Teils dieser Artikelserie (folgt in Kürze).
Hallo,
Danke für die Anleitung! Leider hänge ich gerade in einer Migration an dem Punkt das ich die Datenbank am 2016 nicht abhängen kann da angeblich noch ein Publicfoldermigration anfoderung zugeordnet wäre.
auf ein stop-migrationbatch meldet er aber:
der Migrationsbatch „eine ID) wurde nicht gefunden.
was kann ich tun?
Hallo,
Danke für die Anleitung! Leider hänge ich gerade in einer Migration an dem Punkt das ich die Datenbank am 2016 nicht abhängen kann da angeblich noch ein Publicfoldermigration anfoderung zugeordnet wäre.
auf ein stop-migrationbatch meldet er aber:
der Migrationsbatch „eine ID) wurde nicht gefunden.
was kann ich tun?
Hallo,
wie sieht das eigentlich mit der Autovervollständigung der E-Mails im Outlook aus, wird das mit übertragen?
Hallo Ansgar,
ja, da ändert sich nichts und alle Einstellungen (auch Autovervollständigung) bleibt erhalten.
Beste Grüße,
Frank
Bei meiner Migration eines alten Exchange-2016-CU8-Servers auf einen Exchange-2019-CU9 bin ich auf eine Hürde gestoßen: Bis nach der Migration des ersten Postfachs lief alles im grünen Bereich.
Ich habe zwei Datenbanken: „Mailbox Database 2016“ auf dem 2016er (in der bis auf eines alle Postfächer enthalten sind), „DB2019A“ auf dem 2019er (in der sich genau ein Postfach befindet). Versuche ich nun Mails von den Postfächern auf dem 2016er an das Postfach auf dem 2019er zu senden, dann landen diese mit dem Fehler „Zurzeit ist keine Route zur Postfachdatenbank vorhanden.“ in der Queue „Unreachable“. Die Gegenrichtung, also 2019 -> 2016 funktioniert allerdings. Das fehlende Routing schlägt auch bei Externen Mails durch, die vom PopBeamer abgeholt und an den 2019er-Server übergeben werden.
Ich gebe zu, dass ich ein wenig auf dem Schlauch stehe und jetzt keinen Ansatzpunkt finde, hätte irgendjemand eine Idee?
Bei mir hat ein Server Neustart beider Exchange geholfen.
Müssen Monitoring Mailboxen (Get-Mailbox -Monitoring) auch auf den neuen Exchange umgezogen bzw. migriert werden?
Moin,
als erstes vielen Dank für die tollen Anleitungen und Erklärungen zu Exchange Themen. Ich habe nun die Migration von 2013 zu 2019 angefangen. Nun besteht das Problem darin, dass ich die Datenbanken des 2019er im ECP sehen kann und diese auch als eingebunden angezeigt werden, jedoch kann ich sie nicht aufrufen. Es erschein: „Ihre Anforderung konnte nicht abgeschlossen werden. Versuchen Sie es in einigen Minuten noch mal.“ Auch beim Anlegen neuer Datenbanken gibt es eine Fehlermeldung, angelegt werden diese aber. Per Shell ist auch alles gut, aber man kann nicht wirklich drauf zugreifen. Ich scheine irgendwo etwas übersehen zu haben, hat jemand ne Idee?
Gruß,
Daniel
@Daniel
Die ECP Seite zwischen Exchange 2013 + 2016/2019 unterscheidet sich in der Version. Mit der 2013er Version kann man nicht auf einige Funktionen von 2016 / 2019 zugreifen. Gib im Browser mal https://exchange2016/2019/ecp?ExchClientVer=15.1 für 2016 bzw. 15.2 für 2019 ein. Dann sollte alles korrekt angezeigt werden. Exchange 2013 verwendet 15.0, damit klappt es nicht!
Servus,
bei Office365 ist es das Gleiche Problem, und hier werde ich von Microsoft hingeleitet. Gibt es hier auch ein HowTo?
Zum Exchange 2019: Was mache ich wenn ECP von extern erreichbar ist? Wir haben es hinter einer Sophos UTM in der WAF integriert…
Grüße
Norbert
Moin,
ich habe das Problem irgendwie gelöst, kann mich aber gerade nicht dran erinnern wie. Es hatte etwas mit den DNS Einträgen zu tun die man über Powershell Befehle explizit setzten muss. Finde die leider gerade nicht wieder.
Aber ich kann Deine Frage nicht ganz nachvollziehen, von wo nach wo möchtest Du migrieren?
Viele Grüße,
Daniel
@Daniel
Hast du das Problem mit der 2013er Migration lösen können? Wenn ja, wie genau?
Danke für das Feedback
Moin Max,
ja, ich habe die Migration erfolgreich abgeschlossen. An sich genau der Anleitung nach. Wenn ich es richtig in Erinnerung haben, dann hatte ich das falsche ECP verwendet um die Datenbanken zu bearbeiten/aufzurufen.
An welcher Stelle hakt es denn bei Dir?
Gruß,
Daniel
Hi Franky,
du meinst bestimmt EAC und nicht ECA?
Mfg
Stephan
Hallo Stephan,
danke für den Hinweis, ich hab es korrigiert. Wobei ich mich gerade frage, wieso ich das so häufig falsch geschrieben habe!? :-)
Gruß,
Frank
Klasse, danke.