During an Exchange 2016 to Exchange 2019 migration, no mailboxes could be moved to the new Exchange 2019 databases. The MoveRequests got stuck at 0% and showed the error StalledDueToSource_DiskLatency:
No matter how large or small the mailbox was: No mailbox could be moved. Directly after creating the MoveRequest, the error StalledDueToSource_DiskLatency was displayed. Even after a longer wait, the status did not change. The following command provided a hint as to what could be the cause of the problem:
Get-MoveRequest | Get-MoveRequestStatistics -IncludeReport -Diagnostic | fl
The error report indicates a problem with the storage and also directly shows the corresponding volume, which has too high a latency:
The volume from the error report is the volume that stores the database:
I then checked the performance values of the volume (Windows performance counter, vmware performance counter, storage values), but could not find any problem. This Exchange Server was a vmware VM with sufficient storage on a dedicated datastore. The vmware datastore is located on a high-performance Pure All-Flash Array. All latencies that I could find, from the storage to the VM, were unremarkable and delivered values of less than 1ms.
The troubleshooting here was quite frustrating, all performance counters delivered optimal values, there was no indication of a performance problem. Moving the VM to other datastores from another storage array did not help either.
Due to an older storage migration of the Exchange Server, however, there was an inconvenience: The volumes for the databases were spread over several disks (spanned volumes). This can be seen in this screenshot, where a volume spans several disks:
As already mentioned, the performance counters of each individual disk were also unremarkable, but this was the last straw. So I dissolved the spanned disks and configured a large simple volume for the database. Fortunately, there was enough free space on the storage and, thanks to virtualization, the database move was completed quickly. Spanned volumes and Exchange servers are actually not that unusual. With a physical server with a JBOD, the procedure would be similar.
After the database volume was saved again on a large disk with a volume, the StalledDueToSource_DiskLatency error disappeared. All mailboxes could be migrated without any problems. Also for other databases which were stored on spanned volumes, the migration of the mailboxes worked after switching to a large disk. The StalledDueToSource_DiskLatency error did not occur again afterwards.
By the way, I created the large single disk for the database on the same storage and the same vmware datastore. Ultimately, I could not determine the reason for the StalledDueToSource_DiskLatency error, but it seems to be related to the Spanned Volumes.
Perhaps this will also help others, if you have already had this error, please write it in the comments.
Wir hatten gerade ein ähnliches Phänomen in einer kleineren Umgebung.
ca. 20 Postfächer werden in PST exportiert, 19 laufen, 1 bringt die Meldung „StalledDueToSource_DiskLatency“. Während der Recherche (bin auch hier gelandet) hat sich das Problem aber selbständig bereinigt und er ist ohne weiteres Zutun auf „CopyingMessages“ gesprungen.
Bei uns hat also das reine Abwarten geholfen!
Interessant zu lesen und schön, dass du es gelöst hast! Aber ich denke, das ist schon eine ziemliche Seltenheit.
Der im Screenshot zu sehende Wust aus Disks und Volumes halte ich schon für sehr ungewöhnlich. Bei meinen selbst aufgebauten und betreuten Umgebungen nutze ich keine Spanned Volumes und bei neu hinzugekommenen, teils auch sehr wilden Installationen, ist mir so ein Fall auch noch nicht untergekommen.
Bei mir habe ich einen neuen Exchange2019 aufgesetzt, die ersten 50 Postfächer liessen sich migrieren, danach nichts mehr. Alle Werte unauffällig, das Volume für die DB ist 2TB groß und in einer HP MSA befindlich. Also 1 Volume, und StalledDueToTarget_DiskLatency, ganz gleich wie groß die Postfächer sind…..