Bei einer Exchange Migration kam es zuletzt zu einem Fehler (Microsoft System Attendant kann nicht geöffnet werden), wo sich ein einzelnes Postfach nach einer fehlgeschlagenen Verschiebeanforderung nicht erneut verschieben ließ.
New-MoveRequest „Ben.Utzer“ -TargetDatabase „ExchDB01“
PowerShell: New-MoveRequest (New-MoveRequest (ExchangePowerShell) | Microsoft Docs)
Das Postfach /o=Domain/ou=Exchange Administrative Group
(FYDIBOHF23SPDLT)/ cn=Configuration/cn=Servers/cn=neuer Exchange Server/cn=Microsoft System Attendant kann nicht geöffnet werden.
+ CategoryInfo : NotSpecified: (:) [New-MoveRequest], RemoteTransientException
+ FullyQualifiedErrorId : [Server=neuer Exchange Server,RequestId=672ea66a-5b1a-4a81-b0f3-7f76efaecf03,TimeStamp=23.06.2022 1
2:09:11] [FailureCategory=Cmdlet-RemoteTransientException] 67F6D7CA,Microsoft.Exchange.Management.Migration.Mailbo
xReplication.MoveRequest.NewMoveRequest
+ PSComputerName : neuer Exchange Server.Domain.tld
Dieser Fehler kann unter anderem auftreten, sofern die Arbitration Mailbox „Microsoft Exchange Migration“ (Migration.8f3e7716-2011-43e4-96b1-aba62d229136) einen Defekt hat oder gelöscht wurde. Sofern die Mailbox gelöscht wurde, wird hier von Microsoft beschrieben, wie die Migration Mailbox neu erstellt werden kann: Recreating arbitration mailboxes: Exchange 2013 Help | Microsoft Docs
Ist das Postfach noch vorhanden und es wird ein Defekt vermutet, lässt sich folgendermaßen vorgehen:
Disable-Mailbox -Identity "Migration.8f3e7716-2011-43e4-96b1-aba62d229136" `
-Arbitration
.\Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF /CustomerFeedbackEnabled:False
Enable-Mailbox -Identity "Migration.8f3e7716-2011-43e4-96b1-aba62d229136" `
-Arbitration
Set-Mailbox "Migration.8f3e7716-2011-43e4-96b1-aba62d229136" `
-Arbitration `
-Management:$True `
-Force
„Leider“ war in meinem Fall die Arbitration Mailbox für die Postfach-Migration noch vorhanden und auch nicht defekt. Eine Verschiebeanforderung des problematischen Postfachs in eine neue, leere Datenbank auf dem alten Exchange Server war ebenfalls möglich. Ebenfalls konnte die Mailbox noch geöffnet werden – ein kaputtes Postfach lag also auch nicht vor. So langsam wurde guter Rat teuer bzw. gingen meine Ideen zur Neige. Zufällig kam mir beim Troubleshooting-Brainstorming die Mailbox Quarantäne in den Sinn – Jackpot. Yay. 🙂
# Auf dem neuen Exchange Server:
Get-MailboxStatistics -Server $env:COMPUTERNAME |
Select DisplayName, IsQuarantined |
Format-Table -AutoSize
Das neue „Problem“: Die Mailbox befindet sich noch auf dem alten Server und ist auf dem neuen in der Quarantäne. Daher konnte ein
Disable-MailboxQuarantine "Ben.Utzer" `
-Confirm:$false
WARNUNG: Der Befehl wurde erfolgreich ausgeführt, aber es wurden keine Quarantäneeinstellungen des Postfachs
"57618610-f5b0-47d9-b01a-718fe4198d28" auf dem Server "alter Exchange Server" geändert.
nicht helfen. Also auf in die Registry am neuen Exchange Server und dort unter „HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\Private-{DB GuId}\QuarantinedMailboxes“ den Schlüssel „57618610-f5b0-47d9-b01a-718fe4198d28“ (entspricht der Mailbox GuId) löschen sowie den Informationsspeicher Dienst neu starten.
Der nächste Versuch, das Postfach in die neue Datenbank auf dem neuen Exchange Server zu verschieben, war erfolgreich. Der Move Request wurde in die Warteschlange aufgenommen, abgearbeitet und schließlich finalisiert.
Schreibe einen Kommentar