Earlier this week I was struggling to export a users mailbox and the solution turned out to be pretty simple. I started with the usual powershell export command:
New-MailboxExportRequest -Mailbox MVERGER -filepath \\SERVER01\Backup$\MVerger.pst
The export would run for ~10 minutes and then report a failure. I’ve had exports fail now and then so I kicked the command off one more time. Again the export failed at the 10 minute mark. Checking the export directory showed two files from the failed exports that were the same size. I assumed that the mailbox had some corruption which was causing the export to fail. I ran the following command to get the identity of the failed export request.
Get-MailboxExportRequest -Status Failed | Select Mailbox, Name, Identity | FL Mailbox : Test.Lab.Local/Users/Mason Verger Name : MailboxExport Identity : Test.Lab.Local/Users/Mason Verger\MailboxExport
Using the identity of the failed request you can pull up a log of the export request. I culled the log down to show the pertinent part.
Get-MailboxExportRequestStatistics -Identity "Test.Lab.Local/Users/Mason Verger\MailboxExport" -IncludeReport | fl 8/5/2017 12:12:47 PM [EXCH01] A corrupted item was encountered during the move operation. The item wasn't copied to the destination mailbox. <baditem errorType="MapiExceptionInvalidParameter" errorCode="0x80070057" <errorMessage>MapiExceptionInvalidParameter: Unable to copy to target. (hr=0x80070057, ec=-2147024809)
At least my suspicion was confirmed, there is some corruption in the mailbox causing the export to fail. Time was of the essence so I decided to bypass any corrupted messages using this command.
New-MailboxExportRequest -Mailbox MVERGER -filepath \\SERVER01\Backup$\MVerger.pst -BadItemLimit 50 -AcceptLargeDataLoss WARNING: When an item can't be read from the source location or can't be written to the target location, it will be considered corrupted. By specifying a non-zero BadItemLimit, you're requesting that Exchange not copy such items to the target location. When the request is complete, such corrupted items won't be available at the target. When the source is deleted, these items will be completely lost.
When specifying a BadItemLimit of anything but zero, exchange will give you a warning letting you know that any message that cannot be read from the source or written to the destination will be skipped. I was fine with this and proceeded with the export. Twenty minutes later the export completed successfully. I repeated the steps from above except this time I wanted to see the report from the successful export so I could examine the corruption. Luckily, all the failures in my export were really old Read receipts so I did not bother with trying to recover them. My last step was to remove the MailboxExportRequest using this command.
Get-MailboxExportRequest | Remove-MailboxExportRequest Confirm Are you sure you want to perform this action? Removing completed request 'Test.Lab.Local/Users/Mason Verger\MailboxExport'. [Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is "Y"): Y
Of course you can add -Confirm $true to the end of the Remove-MailboxExportRequest and the request will be removed without prompting you first, but I like to see which request is being removed.