Risque de perte de données lors de la migration de dossiers publics Exchange 2013, 2016 d’Exchange ou Exchange Online

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 3161916
Symptômes
Si vous utilisez migration de lotou série migration pour migrer des dossiers publics à partir de Microsoft Exchange Server 2007 ou Microsoft Exchange Server 2010, 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.

Diagramme illustrant ce dossier F1 et F2 à partir de la source est copiée vers la destination durant la synchronisation initiale.
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. Le statut de lot affiché 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).

Diagramme montrant les données incrémentielles au dossier F1 est copié et les modifications apportées au dossier F2 ne sont pas copiées. Données dans le dossier nouvellement ajouté F3 n’est pas copié, mais le dossier apparaissent 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.
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.

FORUM AUX QUESTIONS

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 à l’état prêt à terminer de reachthe. 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.

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 3161916 - Dernière mise à jour : 06/24/2016 07:58:00 - Révision : 4.0

Exchange Server 2016 Enterprise Edition, Exchange Server 2016 Standard Edition, Microsoft Exchange Server 2013 Enterprise, Microsoft Exchange Server 2013 Standard, Microsoft Exchange Online

  • kbsurveynew kbbug o365 kbgraphic kbgraphxlink kbmt KB3161916 KbMtfr
Commentaires