Il arrive un moment où un serveur Exchange a fait son temps et où une migration vers un nouveau serveur est envisagée. Un nouveau serveur ou une nouvelle machine virtuelle est créé(e) et configuré(e) selon les bonnes spécifications et toutes les mises à jour sont appliquées. Le système d’exploitation fonctionne parfaitement et le nouveau serveur Exchange est configuré et entièrement mis à jour. Jusqu’à présent, le serveur n’est pas opérationnel, bien sûr, car vous devez déplacer les messageries avec un nouveau lot de migration. Vous commencez par quelques messageries de test pour tester la vitesse et les performances des deux serveurs, car pendant la migration, vous ne voulez pas entraver les performances du serveur actif jusqu’à ce que la migration soit terminée. Vous remarquerez peut-être l’erreur « Bloqué à la latence cible ». Pour un scénario de test, cela ne vous dérange pas, mais pendant la migration, c’est quelque chose que vous ne souhaiteriez pas.
Prenons l’exemple d’une configuration où une migration est effectuée entre un Exchange Server 2013 et un Exchange Server 2016. Le nouveau serveur est opérationnel sur une nouvelle machine virtuelle dédiée sur un nouveau SAN avec 32GB de RAM et 4x CPU assignés sur un pack RAID 5 de disques SAS 10K
Dans ce cas, vous pouvez dépanner le problème et le résoudre, ce qui peut prendre un certain temps. Cependant, vous pouvez également utiliser un logiciel de conversion EDB en PST, tel que Stellar Converter for EDB, pour migrer les messageries de l’ancien serveur vers le nouveau sans avoir à faire face à ce problème. Le logiciel peut vous aider à exporter les éléments de la messagerie de la base de données de l’ancien serveur Exchange vers la base de données du nouveau serveur Exchange en quelques clics.
Solution pour réparer l’erreur d’exportation de messageries bloquée en raison de la latence du disque source
Vous commencez la migration avec une messagerie test de 1 Go de messagerie principale et 500 Go d’archives. Vous commencez par créer le nouveau lot à l’aide de la cmdlet PowerShell New-MoveRequest et après une heure, vous utilisez la cmdlet Get-MoveRequestStatistics pour voir que la progression est marquée comme StalledDueToTargeDiskLatency et que le processus ne se termine jamais ou prend un temps excessif pour se terminer.
Ce problème peut être rencontré lors de la migration vers un nouveau serveur Exchange décrite ci-dessus, mais aussi lors de la migration vers une nouvelle base de données de messageries sur le même serveur ou lors de l’exportation d’une messagerie vers un fichier PST.
Il y a de nombreux éléments à prendre en compte dans tout scénario, mais le plus évident est la performance de votre disque ou de votre magasin de données dans le cas d’une machine virtuelle. Le temps de réponse de la source est très élevé et les lots de migration ou l’exportation sont interrompus.
La première chose à vérifier est la performance du disque en vérifiant à partir de votre RAID ou de votre logiciel de gestion de disque, ou en vérifiant le statut du magasin de données à partir de votre hyperviseur. Si ce n’est pas le cas. Si les disques durs ne sont pas performants en raison de leur vitesse, vous devez envisager de passer à un nouveau pack RAID comportant des disques SAS ou SSD. D’autre part, vous pouvez vérifier si vous avez un disque dur qui va bientôt tomber en panne. En général, ces disques sont marqués sur le gestionnaire SAN ou RAID.
Qu’il s’agisse d’un système physique ou virtuel, on peut vérifier en utilisant le Performance Monitor sur le serveur Windows hébergeant la base de données de la messagerie source en surveillant MSExchange Replication et MSExchange Replication Server ainsi que la Sec. disque moyenne pour l’écriture et la lecture.
Après avoir configuré les éléments ci-dessous, exécutez les demandes de migration et vous pourrez analyser les données et le stockage. Une autre chose à faire est de vérifier s’il y a encore d’anciennes demandes de migration qui doivent être nettoyées. Ceci a été suggéré par Microsoft car il peut y avoir des demandes bloquées ou d’anciennes demandes qui entravent les performances de votre serveur Exchange. La suggestion est de supprimer les demandes à l’aide de la cmdlet PowerShell Remove-MoveRequest, puis d’ajouter la nouvelle demande de déplacement en utilisant le paramètre –Priorité comme dans les exemples ci-dessous.
Remove-MoveRequest –Identity “user1@ex01.lan”New-MoveRequest –Identity “user1@ex01.lan” –BatchName “TestMigration” –Priorité la plus élevée
Ceci exécutera la demande de migration ayant la plus haute priorité. Si vous avez un certain nombre de demandes de migration, vous pouvez également essayer de suspendre d’abord les messageries bloquées et de les reprendre après environ 10 minutes. Cela peut être fait en utilisant la commande Suspend-MoveRequest et Resume-MoveRequest PowerShell cmdlet comme dans les exemples ci-dessous.
Suspend-MoveRequest –Identity “user1@ex01.lan”
Resume-Moverequest –Identity “user1@ex01.lan” Si la méthode ci-dessous ne fonctionne pas, nous pourrions envisager de supprimer toutes les demandes de migration et vérifier les performances du serveur.
Si vous avez un problème d’exportation ou de migration de données, la seule solution est de vous tourner vers des applications tierces qui peuvent vous aider à réaliser ce que vous ne pouvez pas faire avec les applications natives. Avec Stellar Converter for EDB, vous serez en mesure d’exporter n’importe quel format de fichier EDB, depuis Exchange 5.5 jusqu’au dernier serveur Exchange, de le parcourir et de l’exporter vers PST en un clic, puis de l’importer facilement sur votre serveur Exchange. De plus, cette application convertisseur EDB vers PST peut lire un fichier EDB et l’importer directement sur un serveur Exchange ou un locataire Office 365 sans aucun pr
