Irgendwann hat ein Exchange Server ausgedient und es steht eine Migration auf einen neuen Server an. Ein neuer Server oder eine neue virtuelle Maschine wird erstellt und nach den richtigen Vorgaben eingerichtet und alle Updates werden eingespielt. Das Betriebssystem läuft einwandfrei und der neue Exchange Server ist konfiguriert und vollständig aktualisiert. Bis zu diesem Zeitpunkt ist der Server natürlich noch nicht betriebsbereit, da Sie die Postfächer mit einem neuen Migrationsstapel umziehen müssten. Sie beginnen mit einigen Testpostfächern, um die Geschwindigkeit und Leistung beider Server zu testen, da Sie während der Migration die Leistung des Live-Servers nicht beeinträchtigen wollen, bis die Migration abgeschlossen ist. Vielleicht bemerken Sie die Fehlermeldung ‘Stalled to Target Latency’. In einem Testszenario würde Sie das nicht stören, aber während der Migration ist es etwas, das Sie nicht haben möchten.
Nehmen wir ein Beispiel für ein Setup, bei dem eine Migration von einem Exchange Server 2013 auf einen Exchange Server 2016 durchgeführt wird. Der neue Server wird auf einer neuen dedizierten virtuellen Maschine auf einem neuen SAN mit 32 GB RAM und 4x CPU auf einem 10K SAS-Laufwerk RAID 5 Pack betrieben.
In einem solchen Fall können Sie eine Fehlersuche durchführen und das Problem beheben, was eine Weile dauern kann. Sie können jedoch auch eine EDB zu PST Konverter Software wie Stellar Converter for EDB verwenden, um Postfächer vom alten Server auf den neuen zu migrieren, ohne dass dieses Problem auftritt. Die Software kann Ihnen helfen, die Postfächer aus der Datenbank auf dem alten Exchange-Server in die Datenbank auf dem neuen Exchange-Server in ein paar Klicks zu exportieren.
Lösung zur Behebung des Fehlers “Mailbox-Export aufgrund von Latenz der Quellfestplatte blockiert”
Sie beginnen die Migration mit einem Testpostfach mit 1 GB Hauptpostfach und 500 GB Archiv. Sie beginnen mit dem Erstellen des neuen Stapels mit dem PowerShell-Cmdlet New-MoveRequest und nach einer Stunde sehen Sie mit dem Cmdlet Get-MoveRequestStatistics, dass der Fortschritt als StalledDueToTargeDiskLatency markiert ist und der Prozess nie abgeschlossen wird oder übermäßig lange dauert, bis er beendet ist.
Dies kann entweder bei der oben beschriebenen Migration auf einen neuen Exchange Server der Fall sein, aber auch bei der Migration auf eine neue Postfachdatenbank auf demselben Server oder beim Exportieren eines Postfachs in eine PST-Datei.
Es gibt viele Dinge, die in jedem Szenario zu berücksichtigen sind, aber das Offensichtlichste ist die Leistung Ihrer Festplatte oder Ihres Datenspeichers im Falle einer virtuellen Maschine. Die Antwortzeit von der Quelle ist hier sehr hoch und die Migrationsstapel oder der Export werden zeitlich begrenzt.
Prüfen Sie als erstes die Leistung des Datenträgers, indem Sie Ihre RAID- oder Festplattenverwaltungssoftware oder den Status des Datenspeichers in Ihrem Hypervisor überprüfen. Wenn dies nicht der Fall ist. Wenn die Festplatten aufgrund ihrer Geschwindigkeit nicht gut funktionieren, sollten Sie den Wechsel zu einem neuen RAID-Verbund mit SAS- oder SSD-Laufwerken in Betracht ziehen. Auf der anderen Seite sollten Sie prüfen, ob Sie eine Festplatte haben, die bald ausfallen wird. Normalerweise sind diese Festplatten im SAN oder RAID-Manager markiert.
Ob es sich um eine physische oder virtuelle Festplatte handelt, kann man mit dem Leistungsmonitor auf dem Windows Server, der die Quell-Postfachdatenbank hostet, überprüfen, indem man MSExchange Replikation und MSExchange Replikationsserver zusammen mit der Average Disk Sec für Write und Read überwacht.
Nachdem Sie die unten stehenden Einstellungen vorgenommen haben, führen Sie die Umzugsaufträge aus und Sie können die Daten und den Speicher analysieren. Außerdem sollten Sie prüfen, ob noch alte Umzugsaufträge vorhanden sind, die bereinigt werden müssen. Dies wurde von Microsoft vorgeschlagen, da es steckengebliebene oder alte Aufträge geben könnte, die die Leistung Ihres Exchange Servers behindern. Der Vorschlag ist, die Anforderungen mit dem PowerShell-Cmdlet Remove-MoveRequest zu entfernen und dann die neue Umzugsanforderung mit den Prioritäten parametern wie in den folgenden Beispielen hinzuzufügen.
Remove-MoveRequest –Identity “user1@ex01.lan”
New-MoveRequest –Identity “user1@ex01.lan” –BatchName “TestMigration” –Höchste Priorität
Damit wird die Umzugsanforderung mit der höchsten Priorität ausgeführt. Wenn Sie eine Reihe von Umzugsanforderungen haben, können Sie auch versuchen, die blockierten Postfächer zunächst anzuhalten und nach etwa 10 Minuten wieder aufzunehmen. Dies kann mit dem PowerShell-Cmdlet Suspend-MoveRequest und Resume-MoveRequest wie in den folgenden Beispielen durchgeführt werden.
Suspend-MoveRequest –Identity “user1@ex01.lan”
Resume-Moverequest –Identity “user1@ex01.lan”
Wenn das Untenstehende nicht funktioniert, können wir prüfen, ob wir alle Verschiebeanforderungen entfernen und die Leistung des Servers überprüfen können.
Wenn Sie ein Problem mit dem Exportieren oder Migrieren von Daten haben, dann wäre die einzige Lösung, sich nach Anwendungen von Drittanbietern umzusehen, die Ihnen helfen können, das zu erreichen, was Sie mit den nativen Anwendungen nicht erreichen können. Mit Stellar Converter for EDB können Sie jedes Format der EDB-Datei exportieren, d.h. von Exchange 5.5 bis zum neuesten Exchange Server, sie durchsuchen und mit einem Klick in PST exportieren und dann problemlos in Ihren Exchange Server importieren.
Darüber hinaus kann diese EDB zu PST Konverter-Anwendung aus einer EDB-Datei lesen und direkt auf einen Live Exchange Server oder Office 365 Tenant ohne Probleme importieren.
Was this article helpful?
