Die Migration auf einen neuen Exchangeserver kann manchmal echt frustrierend sein. Dabei ist die eigentliche Installation häufig nicht das Problem. Das Verschieben von Postfächern in die neue Datenbank bereitet Schwierigkeiten. Ein mögliches Szenario kann dabei sein, dass ein Migrationbatch nicht über den Status Synchronisieren hinauskommt.

Egal wie lange man auch wartet, die Verschiebeanforderung startet nicht. Gleiches Fehlerbild erhält man, wenn man den Move-Request via Shell absetzt. Dort hängt der Move-Request im Status Queued. Vielleicht helfen Euch hierzu unten stehende Lösungsansätze, damit es wieder funktioniert.

Lösungsansatz 1

Eine mögliche Ursache kann sein, dass die Systempostfächer bzw. die Discovery Search Mailbox nicht schon vorab schon umgezogen worden sind. Dies könnt Ihr relativ einfach mit folgenden Anweisungen durchführen:

Get-Mailbox -Arbitration | New-MoveRequest -TargetDatabase [neue Datenbank]
Get-Mailbox -RecipientTypeDetails DiscoveryMailbox | New-MoveRequest -TargetDatabase [neue Datenbank]

Lösungsansatz 2

Ihr könntet es in seltenen Fällen mit einem defekten Migrationsbenutzer zu tun haben. Damit Ihr diesen wiederherstellen könnt, benötigt Ihr das Installationsmedium des Exchangeservers. Geht folgendermaßen vor:

1. Löschung des User Accounts „Migration.8f3e7716-2011-43e4-96b1-aba62d229136“ im AD Users Container
2. Setup ausführen: „E:\Setup.exe /IAcceptExchangeServerLicenseTerms /PrepareAD“ (kann während des Betriebs ausgeführt werden, kein Ausfall, kein Neustart)
3. Enable-Mailbox -Arbitration -Identity „Migration.8f3e7716-2011-43e4-96b1-aba62d229136“
4. Set-Mailbox -Identity „Migration.8f3e7716-2011-43e4-96b1-aba62d229136“ -Arbitration -Management $true -Force

Weitere Informationen hierzu findet Ihr hier: docs.microsoft.com.

Lösungsansatz 3

Eine bis jetzt letzte Fehlerursache könnte auch ein defekter Index der Zieldatenbank sein. Prüft dies mit Get-MailboxDatabaseCopyStatus:

Wenn der Status Failed oder FailedSuspend ist, verwendet die Anleitung von Martin: Repairing a Failed Content Index in Exchange Server 2013 & 2016. Sollte nach diesem Prozedere der Status noch immer nicht Healthy sein, hängt die betroffene Datenbank einmal aus und wieder ein.​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​

Falls Ihr noch weitere Fehlerursachen kennt, informiert mich, damit ich den Artikel erweitern kann. Solltet Ihr weitere Fragen haben, dann hinterlasst einen Kommentar oder schreibt mir eine E-Mail.

Update: Fehler im Artikel wurde begradigt. Danke an Tobias!

Update: Weiterer Fehler wurde begradigt. Danke!