Symptômes
Si vous utilisez la migration de lot ou de série pour la migration de dossiers publics à partir de Microsoft Exchange Server 2007 ou Microsoft Exchange Server 2010 pour Exchange Server 2013, Exchange Server 2016 ou Exchange Online, perte de données peut se produire si tous les réplicas de dossier ne sont pas dans la base de données principal (le serveur de base de données primaire auquel se connecte le service de migration). Toutes les données au premier présents dans les dossiers qui sont migrés sont copiées, mais toutes les modifications incrémentielles sont validées après la synchronisation initiale peuvent être perdues.
Exemple de scénario
Supposons que vous avez deux dossiers publics bases de données, PFDB1 et PFDB2, qui sont exécutent sur des serveurs Exchange 2007 ou Exchange 2010. En outre, vous avez deux dossiers, F1 et F2. Dossier F1 dispose d’un réplica sur PFDB1 et dossier F2 dispose d’un réplica sur PFDB2.
Lorsque vous démarrez la migration et que vous spécifiez PFDB1 comme la base de données pour se connecter à dans le Nouveau -MigrationEndpoint applet de commande, toutes les données à partir de dossiers F1 et F2 est copié au cours de la synchronisation initiale (comme illustré dans la Figure 1). Cela se produit même si PFDB1 n’a pas un réplica local du dossier F2.
Après cette première synchronisation, vous préparez la synchronisation finale et d’exécuter le lot. Vous attendez que toutes les données sont ajoutées au dossier F1 et F2 après la première synchronisation doit être copiée au cours de la dernière synchronisation.
La figure 1. Dossier F1 et F2 à partir de la source est copiée vers la destination au cours de la première synchronisation.
Problème
Durant la synchronisation incrémentielle et finale, les données incrémentielles à partir de F2 de dossier n’est pas copiées vers les dossiers publics modernes (comme illustré à la Figure 2). C’est parce que PFDB1 est spécifié comme le point de terminaison. L’état du lot s’affiche comme synchronisées. Toutefois, toutes les nouvelles données qui a été ajoutées au dossier F2 après la première synchronisation n’est pas copiées vers les dossiers publics modernes.
En outre, s’il y a tous les nouveaux dossiers ajoutés à PFDB2 après la première synchronisation (dossier F3 dans la Figure 2), le contenu de ces dossiers ne seront pas copiée. (Cela est vrai même si le dossier F3 est affiché dans la hiérarchie).
La figure 2. Les données incrémentielles au dossier F1 sont copiées et modifications apportées au dossier F2 ne sont pas copiées. Bien que les données dans le dossier nouvellement ajouté F3 ne sont pas copiées, le dossier apparaît dans la hiérarchie.
Résolution
Les correctifs sont disponibles en 13 de mise à jour Cumulative pour Exchange Server 2013et Cumulative Update 3 pour Exchange 2016.
Solution de contournement
Avant de commencer la migration de traitement par lots, vérifiez que tous les dossiers publics ont un réplica sur la base de données de dossiers publics qui est spécifiée comme la source pour la migration. En outre, assurez-vous que la réplication publique est synchronisée.
Solution de contournement pour l’exemple de scénario
Pour contourner ce problème, ajoutez un réplica de dossiers F2 et F3 sur PFDB1 et assurez-vous que la réplication de dossier public est synchronisée puis démarrez migration de traitement par lots. Cela permet de garantir que les données incrémentielles sont copiées (quel que soit le réplica qu’il est écrit à l’origine dans).
Nous sommes conscients que cette solution de contournement ne fonctionne pas pour certains clients en raison de la taille du déploiement de dossiers publics. Si vous êtes dans ce cas, nous vous conseillons d’attendre jusqu'à ce que le problème est résolu avant de procéder à une migration.
FAQ
Q: Lorsque ce problème commence à apparaître ?
A: ce problème a été observé tout d’abord le 1 de mise à jour Cumulative d’Exchange Server 2013 RTM d’Exchange Server 2016 et Exchange Online.
Q: les données I perdre ?
A: dans la Mme rapport pour « modifications de hiérarchie de dossiers signalés dans la source, » sélectionnez le premier élément « les modifications de hiérarchie de dossiers signalés dans source » qui figure dans la liste de recherche et puis sélectionnez la date et l’heure du journal associé. Toutes les données sont ajoutées au dossier F2 ou tous les dossiers qui sont ajoutés à PFDB2 après cette heure sont perdues.
Q: subsiste mes bases de données de dossiers publics Exchange Server 2007 ou Exchange Server 2010 dans leur état verrouillé depuis que nous avons migré vers Exchange Server 2013, 2016 d’Exchange Server ou Exchange en ligne. Puis-je toujours migrer mes données perdues ?
A: seule une copie manuelle des données est possible.
Q: Ma migration prenait auparavant des semaines pour parvenir à l’état prêt à terminer. Dois-je recommencer depuis le début ?
A: non, il est inutile de redémarrer la migration de dossiers publics. Lorsque les corrections sont effectuées et les mises à jour sont installées sur votre serveur (ou sur les serveurs Exchange en ligne, si vous effectuez une migration vers Exchange Online), la migration peut être collectée sur où il est présent et il migre les données restantes. Vous devrez peut-être redémarrer le lot de migration. Toutefois, lorsque vous effectuez cette opération, le processus de recherche des modifications et ne démarre pas sur. Un lot de migration démarre sur uniquement si vous supprimez puis le recréer.
