Bei einer Postfach-Migration von Exchange Server zu Exchange Online können euch ganz unterschiedliche und spannende Fehlermeldung begegnen. Nicht immer sind die Fehlermeldungen zu 100% intuitiv verständlich.
In diesem Artikel geht es um eine Fehlerkombination, die einem in einer normal genutzten Exchange Umgebung bei einer MIgration zu MIcrosoft 365 eher selten begegnet.
Das Problem
Während einer Migration von Exchange Server zu Exchange Online, ließ sich ein Postfach partout nicht zu Exchange Online verschieben. Die Fehlermeldung des zugehörigen Move Request lautete “Fatal error QuotaExceededException has occurred“.
Eine Prüfung der MigrationUserStatistics ergab Folgendes:
EstimatedTotalTransferSize : 37.98 GB (40,779,563,240 bytes) EstimatedTotalTransferCount : 1619726 BytesTransferred : 49.53 GB (53,187,719,154 bytes)
Die Quota-Einstellungen des MailUser-Objektes, Ziel der Postfach Migration, deuteten nicht auf ein Quota-Problem des Postfaches selbst hin.
ProhibitSendQuota : 99 GB (106,300,440,576 bytes) ProhibitSendReceiveQuota : 100 GB (107,374,182,400 bytes) IssueWarningQuota : 98 GB (105,226,698,752 bytes)
Die Lösung
Die geschätze Gesamtanzahl der übertragenen Objekte, 1619726, war jedoch ein Indiz, dass es ein Problem mit Anzahl der Objekte im Postfach gab. Nur welches genau, das war die eigentliche Frage.
Hier half der folgende Befehl in der Exchange Online Management Shell weiter:
Get-MoveRequestStatistics JohnDoe@varunagroup.de -IncludeReport -DiagnosticInfo "ShowTimeSlots, Verbose" | Export-CliXml -Path "C:\tmp\movereport.xml"Eine Suche nach QuotaExceededException in der exportierten Xml-Datei führte unmittelbar zum richtigen Abschnitt, um weitere Fehlerinformationen zu ermitteln. Zur besseren Lesbarkeit habe ich den Xml-Overhead entfernt und die kryptischen Fehlertexte eingekürzt..
FailureType : QuotaExceededException
FailureHash : 80cd
FailureCode : -2146233088
MapiLowLevelError : 1252
FailureSide : Target
FailureSideInt : 2
ExceptionTypes : {StorageQuotaExceeded, Storage, DataProviderPermanent, Exchange, MapiMaxObjectsExceeded, Mapi}
ExceptionTypesInt : {86, 70, 102, 1, 50, 30}
WorkItem : IncrementalSync
Message : Cannot save changes made to an item to store. --> MapiExceptionMessagePerFolderCountQuotaExceeded: Unable to save changes. (hr=0x80004005, ec=1252)
0.35250:4F130000, 1.36674:7A000000, 1.61250:00000000, 1.45378:02000000, 1.44866:00140000, 1.36674:0A000000,
[....]
255.31418:40000A67, 0.21457:E0110000, 4.19665:E4040000, 0.37632:0B00F410, 4.37888:E4040000
MessageData :
DataContext : --------
Operation: IStreamableMapiFxProxy.ProcessRequest
[...]
EntryIDs: [count:4, [len=70,
[...]
Folder: type Generic, wkf: None, RegularStorageSourceMailbox, entryId [len=46,
data=00000000342DA49047067C428F6C04707C1B2A0301008CEAB1B8FB262A4FA445B03FA076F8C10000000F7CD70000], parentId [len=46,
data=00000000342DA49047067C428F6C04707C1B2A0301008CEAB1B8FB262A4FA445B03FA076F8C10000000001080000]
Erst in der Xml-Auswertung sieht man die eindeutige Fehlermeldung: MapiExceptionMessagePerFolderCountQuotaExceeded.
In der vorletzten Zeile der InnerException wird die MAPI ID des Ordners angegeben: 00000000342DA49047067C428F6C04707C1B2A0301008CEAB1B8FB262A4FA445B03FA076F8C10000000F7CD70000
Der Ordner Typ wkf deutet darauf hin, dass es sich um einen vom Benutzer erstellten Ordner handeln muss und nicht um einen MAPI-Standardordner.
Mit dem folgenden Befehl konnte ich zwar nicht genau den Ordner mit der angegebenen FolderId finden. Aber das war auch nciht schlimm. MIt großer Wahrscheinlichkeit hat solch ein Anwender mehr als einen Ordner mit zu vielen Objekten. Hier hilft die folgende Abfrage:
Get-MailboxFolderStatistics JohnDoe@varunagroup.de -FolderScope All | Sort-Object ItemsInFolder -Descending | ft Name, FolderPath, ItemsInFolderDie Details dieser Ausgabe sind nicht für den Blog bestimmt. Aber wir konnten einen E-Mail-Ordner identifizieren, der mehr als 1 Million Objekte enthielt. Bei den Objekten handelte es sich um automatisierte Statusnachrichten einer Monitoring-Lösung, die regelbasiert in diesen Ordner verschoben wurden.
Wichtig ist, dass die zuvor genannte Abfrage auch Systemordner anzeigt, wie z.B. Recoverable Items, Audits, Deletions oder Purges. Diese gilt es zu ignorieren.
Der Postfachinhaber hatte nun die Aufgabe, diesen Ordner aufzuräumen und Nachrichten zu löschen. Diese Art von Fehler muss im lokalen Postfach behoben werden. Die Anzahl der Objekte im Ordner muss weniger als 1 Million Objekte sein.
Im Gegensatz zu anderen Fehlern, lässt sich der fehlerhafte Migrationsbatch nicht einfach durch ein Resume zum Weitermachen überreden. Das Batch für das betroffene Benuterobjekt muss gelöscht und neu erstellt werden. Der Grund hierfür ist, dass durch den Fehler die initiale Synchronisation nicht abgeschlossen werden konnte.
Links
Viel Spaß mit Exchange Server & Exchange Online.
