Hello fellow Exchange Admins, Yesterday I exported a 30GB Mailbox as a .pst file to our SFTP server. At about 90% the MailboxExportRequest stalled with StalledDueToSource_DiskLatency.
No other exports were running from the source server. I even disabled all scheduled tasks that could have an impact on the database where the mailbox is mounted.
However, the export request always switched to: StalledDueToSource_DiskLatency
As a consequence, the export started to loop. It just created a new folder hierarchy and started to export the items again.
Therefore the export .pst was growing much bigger than the initial mailbox size. In other words, this can blow up your storage capacities if you have a large mailbox and leave the export overnight! Not to mention that the export is useless afterward.
In this post, I want to share how I worked around the StalledDueToSource_DiskLatency condition.
Let’s start at the beginning:
So the export request is being prioritized over other jobs.
You can find more useful details on monitoring export requests here:
The pain started whenever the export reached completion of 100%.
The job was relinquished due to large delays and unfavorable server health on the source server-side.
As can be seen in the image below the export status stayed inProgress.
While SyncStage was CopyingMessages and StatusDetail was StalledDueToSource_DiskLatency:
Therefore the export job was relinquished:
Eventually, the export started all over again. StatusDetail: CreatingFolderHerarchy:
Then PercentComplete was 10% again:
As a result, the size of the export PST grew much bigger than the initial mailbox size.
After all, the solution for me was to switch the mailbox database that hosts the mailbox to another copy within the DAG:
Work around StalledDueToSource_DiskLatency
First, check which mailbox database hosts the mailbox you want to export:
ServerName shows the server where StalledDueToSource_DiskLatency originates from.
Next, check to which servers the passive database copies are seeded:
The output lists the active mailbox database ( Status: Mounted ), the passive copies ( Status: Healthy ), and the lagged mailbox database copy. ( Status: Healthy with ReplayQueueLenghth greater than the others )
Now switch the active mailbox database with Status: Mounted to one of the passive copies with Status: Healthy:
As has been noted before take care that you don’t try to activate the mailbox database on the server that hosts the lagged database copy!
After the database is switched to another server try to export the mailbox with a new export request.
Given that the new server has no performance or disk issues the export should complete in a normal manner.
After I activated the mailbox database that hosts the mailbox on another server the ServerName did not change when querying the mailbox.
The output of the command above will still show the old server under ServerName. But this is just visual. However, you can find a good explanation for that here.
Have a nice day