There comes a time where an Exchange Server has done it’s time and a migration to a new server is in the pipeline. A new server or a new virtual machine is created and setup to the right specifications and all updates are applied. The operating system is running great and the new Exchange Server is configured and fully updated. Till now the server is not operational of course as you would need to move the mailboxes with a new migration batch. You start off with some test mailboxes to test the speed and performance of both servers as during the migration you don’t want to hinder the performance of the live server until the migration is done. You might notice the error saying ‘Stalled to Target Latency’. For a test scenario you wouldn’t mind but during the migration it is something that you wouldn’t want to have.
Taking an example of a setup where a migration is being done between an Exchange Server 2013 to an Exchange Server 2016. The new server is operational on a new dedicated virtual machine on a new SAN with 32GB of RAM and 4x CPU assigned on 10K SAS drive RAID 5 pack.
You start off the migration with a test mailbox of 1GB main mailbox and 500GB of archive. You start off by creating the new batch using the New-MoveRequest PowerShell cmdlet and after an hour you use the Get-MoveRequestStatistics cmdlet to see the progress marked as StalledDueToTargeDiskLatency and the process never completes or it takes excessively long to finish.
Now this can be seen in either a migration to a new Exchange Server described above but it could also be encountered when migrating to a new mailbox database on the same server or exporting a mailbox to a PST file.
There are many things to factor in any scenario but the most obvious is the performance of your disk or data store in case of a virtual machine. The response time from the source this is very high and the migration batches or export is timed out.
First thing to check is the dis performance by checking from your RAID or disk management software or by checking the data store status from your hypervisor. If this is not the case. If the hard drive are not performing well due to the speed of them then you would need to consider moving to a new RAID pack having either SAS or SSD drives. On the other hand you might want to check if you have a hard drive which soon to fail. Usually these disks are marked on the SAN or RAID manager.
Being physical or virtual, one can check using the Performance Monitor on the Windows Server hosting the source mailbox database by monitoring MSExchange Replication and MSExchange Replication Server along with the Average Disk Sec for Write and Read.
After you setup the below, run the move requests and you can analyse the data and storage. Another thing to do is to check if there are still any old move requests which need to be cleaned out. This has been suggested from Microsoft as there could be stuck requests or old requests which are hindering your Exchange Server performance. The suggestion is to remove the requests using the Remove-MoveRequest PowerShell cmdlet and then adding the new move request using the –Priority parameter as the below examples.
This will execute the move request with highest priority. If you have a number of move requests you can also try to first suspend the stalled mailboxes and after about 10 minutes resume them. This can be done by using the command Suspend-MoveRequest and Resume-MoveRequest PowerShell cmdlet as per examples below.
If the below does not work then we might look into removing all the move requests and check the performance of the server.
If you have a problem with exporting or migrating data then the only solution would be to look to third party applications that can help you achieve what you cannot with the native applications. With Stellar Converter for EDB, you will be able to export any format of EDB file meaning from Exchange 5.5 to the latest Exchange Server, browse through it and export to PST with a click and then import them to your Exchange Server with ease. Adding to this, this EDB to PST Converter application can read from an EDB file and import directly to a live Exchange Server or Office 365 tenant with no issues.