Über den Fehler StalledDueToSource_DiskLatency bei Exchange Migrationen habe ich schon einmal berichtet. Damals konnte ich den Fehler beheben, indem ich ein Spanned Volume über mehrere Disks aufgelöst habe. Bei einer weiteres Exchange Server 2016 zu Exchange 2019 Migration ist nun das Problem wieder aufgetreten. Auch hier trat der Fehler StalledDueToSource_DiskLatency nur bei den Moverequests der größeren Postfächer auf:
Alle kleineren Postfächer ließen sich ohne Probleme verschieben, nur die 5 größten Postfächer lieferten ständig den Fehler StalledDueToSource_DiskLatency. Auch hier waren die Performance Werte der SSDs und der beiden Exchange Server völlig normal. Diesmal war es auch kein Spanned Volume, sondern nur eine einzelne Datenbank auf einer SSD. Die SSD gehörte jetzt zwar nicht zum Spitzenmodell, aber eine Datenbank, 5 Postfächer und gut 100GB Daten, bringen die SSD jetzt auch nicht auf dem Tritt. Wie bereits erwähnt, waren hier auch wieder alle Performance Counter völlig unauffällig. In diesem Fall lief die Prozentanzeige des Moverequests teilweise bis 90% abgeschlossen, nur um dann wieder neu zu beginnen. Auch das Warten über ein ganzes Wochenende, hat hier nichts gebracht.
Ich bin dann auf den folgenden Microsoft Artikel aufmerksam geworden:
In dem Artikel wird empfohlen die Limits für das Workload Management schrittweise bis maximal 100 zu erhöhen. Ich habe die folgenden Befehle benutzt um das WLM Limit auf den Wert 90 anzupassen:
$limit = 90
New-SettingOverride -Name "MdbReplication" -Component WorkloadManagement -Section MdbReplication -Parameters @("MaxConcurrency=$limit") -Reason "Allow more simultaneous mailbox moves"
New-SettingOverride -Name "CiAgeOfLastNotification" -Component WorkloadManagement -Section CiAgeOfLastNotification -Parameters @("MaxConcurrency=$limit") -Reason "Allow more simultaneous mailbox moves"
New-SettingOverride -Name "MdbAvailability" -Component WorkloadManagement -Section MdbAvailability -Parameters @("MaxConcurrency=$limit") -Reason "Allow more simultaneous mailbox moves"
New-SettingOverride -Name "DiskLatency" -Component WorkloadManagement -Section DiskLatency -Parameters @("MaxConcurrency=$limit") -Reason "Allow more simultaneous mailbox moves"
Den letzten Eintrag aus dem Microsoft Artikel gibt es in meiner Umgebung übrigens nicht, ich erhalte da nur eine Fehlermeldung:
Ich denke es handelt sich in dem Artikel nur um einen Schreibfehler (DiskLatency und MdbDiskLatency). Ich habe daher nur die ersten 4 Werte angepasst.
Danach noch einmal alle MoveRequests gelöscht und habe die 5 letzten größeren Postfächer eins nach dem anderen in die neue Datenbank verschoben. Immerhin ließen sich jetzt die Postfächer verschieben, sobald aber mehrere Postfächer verschoben wurden, kam es wieder zum StalledDueToSource_DiskLatency Fehler. Das 27 GB Postfach aus dem Screenshot oben, hat den ganzen Tag gebraucht, aber immerhin ist es jetzt migriert. Ich hoffe mal, das ich dieses Problem nicht noch häufiger sehe…
Moin,
meiner Meinung nach ist das ein normales Verhalten und kein wirklicher „Fehler“. Die Move-Requests werden Exchange intern mit einer sehr niedrigen Priorität behandelt, um das System nicht zu belasten. Dennoch ein guter Hinweis, dass man die throttling Werte anpassen kann. Danke!
Beste Grüße
Wenn bei einer Wochenend-Migration die letzten Mailbox Moves von großen Mailboxen lahmen, dann kann man mit
Get-MoveRequest | Set-MoveRequest -priority emergency
das Ganze beschleunigen, um vor Montag Moregn fertig sein. Das hat schon mehrfach geholfen.