Meilleures pratiques et performances de migration Exchange Online

 

Sapplique à :Exchange Online, Exchange Server, Exchange Server 2013

Dernière rubrique modifiée :2017-04-09

Il existe de nombreuses façons de migrer des données d’une organisation de messagerie sur site de Microsoft Exchange Online vers Office 365. Dans les planifications de migration vers Exchange Online, il est souvent question de savoir comment améliorer les performances de la migration des données et optimiser la vitesse de migration.

RemarqueRemarque :
Les informations de performances répertoriées dans cette rubrique ne s’appliquent pas au service Microsoft Office 365 pour les plans d’abonnement dédiés. Pour plus d’informations sur les plans dédiés, consultez la rubrique Descriptions du service de plans dédiés Office 365.

Exchange Online fait partie d’Office 365 et fournit aux organisations une solution de messagerie informatique basée sur Microsoft Exchange Server. Exchange Online prend en charge plusieurs méthodes de migration des données liées aux messages électroniques, au calendrier et aux contacts à partir de votre environnement de messagerie existant vers Office 365.

Pour plus d’informations sur les performances et la mise en réseau d’Office 365, reportez-vous à notre section sur les performances et l’optimisation.

Méthodes de migration utilisées le plus souvent

Méthode de migration Description Ressources

Migration IMAP

Vous pouvez utiliser le Centre d’administration Exchange (CAE) ou l’environnement de ligne de commande Exchange Management Shell pour migrer le contenu des boîtes aux lettres des utilisateurs d’un système de messagerie IMAP vers leurs boîtes aux lettres Exchange Online. Cette procédure comprend la migration de vos boîtes aux lettres à partir d’autres services de messagerie électronique hébergés, tels que Gmail ou Yahoo Mail.

Pour plus d’informations, voir Migration IMAP.

Migration à basculement

Une migration à basculement vous permet de migrer toutes les boîtes aux lettres sur site vers Exchange Online en quelques jours. Vous pouvez utiliser ce type de migration si vous envisagez de déplacer l’intégralité de votre organisation de messagerie électronique vers Office 365 et de gérer des comptes d’utilisateurs dans Office 365. Vous pouvez migrer au maximum 2 000 boîtes aux lettres à partir de votre organisation Exchange sur site vers Exchange Online à l’aide d’une migration à basculement. Les contacts de messagerie et les groupes de distribution présents dans votre organisation Exchange sur site sont également migrés.

Pour plus d’informations, voir Migration Exchange à basculement.

Migration intermédiaire

Une migration intermédiaire est appropriée si vous prévoyez éventuellement de migrer toutes les boîtes aux lettres de votre organisation vers Exchange Online. Dans ce cas, une migration intermédiaire permet de migrer des lots de boîtes aux lettres sur site vers Exchange Online sur une période de quelques semaines ou mois. Votre objectif est alors de déplacer définitivement votre organisation de messagerie vers Office 365.

Pour plus d’informations, voir Migration Exchange intermédiaire.

Déploiement hybride

Un déploiement hybride offre aux entreprises la possibilité d’étendre l’éventail de fonctionnalités proposé et le contrôle administratif qu’elles exercent dans leur organisation Microsoft Exchange sur site existante vers le nuage. Un déploiement hybride présente l’aspect intégré d’une organisation Exchange unique entre une organisation Exchange Server 2013 ou 2010 sur site et Exchange Online dans Microsoft Office 365. De plus, un déploiement hybride peut servir d’étape intermédiaire avant de passer complètement à une organisation Exchange Online.

Pour plus d’informations, consultez la rubrique Déploiements hybrides Exchange Server :

Migration tierce

Il existe de nombreux outils de fournisseurs tiers. Ils utilisent des protocoles et des approches distincts pour effectuer des migrations de messagerie à partir de plateformes de messagerie telles qu’IBM Lotus Notes et Novell GroupWise.

Voici quelques partenaires et outils de migration tiers pouvant vous aider lors de migrations Exchange à partir de plateformes tierces :

  • Binary Tree   Fournisseur de logiciels de coexistence et de migration de messagerie multi-plateformes, dont les produits permettent l’analyse des environnements de collaboration et de messagerie d’entreprise sur site et en ligne basés sur IBM Lotus Notes et Domino, ainsi que sur Microsoft Exchange et Microsoft SharePoint, et assurent la coexistence et la migration entre ces environnements.

  • BitTitan   Fournisseur de solutions de migration vers Exchange Online.

  • Dell Fournisseur de logiciels de migration et de coexistence sur site et hébergés, permettant notamment l’analyse préalable à la migration et assurant la coexistence complète d’applications et d’utilisateurs. Migrations complètes à partir d’environnements Microsoft Exchange, IBM Domino, Novell GroupWise et Zimbra sur site, entre autres, vers Microsoft Office 365, Exchange Online et SharePoint Online.

  • Metalogix Fournisseur de solutions de migration vers Exchange Online et SharePoint Online.

  • SkyKick Fournisseur de solutions de migration automatisées pour migrer des messageries Exchange, Gmail, POP3, IMAP ou Lotus Notes vers Microsoft Office 365. Les outils de migration de bout en bout aident les partenaires en ce qui concerne les phases de vente, de planification, de migration, de gestion et les phases sur site du projet de migration.

  • TransVault   Fournisseur de solutions de migration vers Exchange Online.

Le tableau suivant compare les résultats de performances observés pour les différentes méthodes de migration de boîtes aux lettres et de données de boîtes aux lettres Exchange Online dans Office 365. Ces résultats sont basés sur des tests internes et les migrations de clients réelles vers Office 365.

ImportantImportant :
En raison de nombreuses différences sur la méthode et la période associées à ces migrations, votre rapidité de migration réelle pourrait être inférieure ou supérieure.

 

Méthode de migration Limitation d’utilisateurs Office 365 Limitation du service de migration Office 365 Limitation basée sur l’intégrité des ressources Office 365 Débit moyen observé par heure et par client (le cas échéant)

Migration IMAP

Non

Oui

Oui

10 à 14 Go (simultanéité = 20)

Migration à basculement

Non

Oui

Oui

10 à 14 Go (simultanéité = 20)

Migration intermédiaire

Non

Oui

Oui

10 à 14 Go (simultanéité = 20)

Migration hybride

Non

Oui

Oui

10 à 14 Go par CAS Exchange 2013 ou 2010 sur site (proxy MRS) avec 20 déplacements simultanés1

Migration MAPI tiers

Oui

Non

Oui

4 à 12 Go (simultanéité = 20) 3

Migration EWS tierce

Non

Oui

Oui

5 à 10 Go (simultanéité = 20) 2

Téléchargement par des clients (à partir d’Outlook PST)

Oui

Non

Oui

0,5 Go

1Le débit observé pour le déplacement d’une seule boîte aux lettres se situe dans la plage 0,3 à 1 Go/h. Un débit supérieur à 1 000 Mo/h par boîte aux lettres peut être obtenu avec un réseau capable de supporter un temps de blocage de défaillance passagère inférieur à 2 % et une latence du réseau inférieure à 100 ms. Davantage de migrations de boîtes aux lettres simultanées peuvent être utilisées pour obtenir des taux de migration des données supérieurs. Le débit du déplacement d’une seule boîte aux lettres sera plus faible lorsque le serveur CAS (proxy MRS) sur site atteindra sa limite matérielle, si la bande passante réseau n’est pas suffisante ou si la latence du réseau est trop élevée. Pensez à ajouter plusieurs serveurs ou à améliorer temporairement la connectivité réseau pour accroître la vitesse de migration.

2Le débit observé pour une seule migration EWS se situe dans la plage 0,2 à 0,5 Go/h. Davantage de migrations simultanées peuvent être utilisées pour obtenir des taux de migration des données supérieurs. Par exemple, avec 100/20 migrations simultanées, le débit total se situera dans la plage 20 à 5010 à 14 Go/h. Le débit d’une seule migration EWS sera plus faible lorsque les serveurs sur site ou le réseau atteindront leur limite.

3Le débit observé pour une seule migration MAPI se situe dans la plage de 0,1 à 0,5 Go/h. Davantage de migrations simultanées peuvent être utilisées pour obtenir des taux de migration des données supérieurs. Le débit d’une seule migration MAPI sera plus faible lorsque les serveurs sur site ou le réseau atteindront leur limite.

La migration de messagerie électronique présente plusieurs facteurs communs susceptibles d’avoir une incidence sur les performances de la migration.

Le tableau suivant fournit une liste de facteurs communs qui ont une incidence sur les performances de migration. Pour obtenir plus de détails, reportez-vous aux sections sur les méthodes de migration individuelles.

 

Facteur Description Exemple

Source de données

Périphérique ou service qui héberge les données à migrer. De nombreuses limitations peuvent s’appliquer à la source de données en raison de spécifications matérielles, de la charge de travail de l’utilisateur final et des tâches de maintenance principales.

Google Mail limite la quantité de données pouvant être extraites durant une période spécifique.

Densité et type de données

Du fait de la nature unique de chaque entreprise, le type et la combinaison d’éléments de messagerie contenus dans les boîtes aux lettres varient sensiblement.

La migration d’une boîte aux lettres de 4 Go avec 400 éléments, chacun avec 10 mégaoctets (Mo) de pièces jointes, sera plus rapide que celui d’une boîte aux lettres de 4 Go avec 100 000 objets plus petits.

Serveur de migration

De nombreuses solutions de migration ont recours à un serveur ou une station de travail de migration pour réaliser la migration.

Les clients ont souvent recours à un ordinateur virtuel aux faibles performances pour héberger le service MRSProxy pour les déploiements hybrides ou un PC client pour les migrations non hybrides.

Moteur de migration

Le moteur de migration chargé de l’extraction des données à partir du serveur source convertit les données en cas de besoin, les transmet par le biais du réseau, puis les injecte dans la boîte aux lettres Exchange Online.

Le service de réplication de boîte aux lettres Microsoft Exchange a ses propres capacités et limites.

Dispositifs réseau sur site

Les performances réseau de bout en bout (de la source de données jusqu’aux serveurs d’accès au client Exchange Online) ont une incidence sur les performances de migration.

Spécifications et configuration du pare-feu de l’organisation sur site.

Service Office 365

Office 365 offre une prise en charge et des fonctionnalités intégrées pour la gestion des charges de travail de migration.

La stratégie de limitation des utilisateurs a des paramètres par défaut et limite le taux de migration des données global.

Cette section décrit les meilleures pratiques pour améliorer les performances réseau durant la migration. Les conseils sont d’ordre général car ce sont le matériel tiers et les fournisseurs de services Internet qui ont le plus fort impact sur les performances réseau durant la migration.

L’outil d’analyse réseau d’Office 365 est déployé pour aider à analyser les problèmes liés au réseau avant le déploiement des services Office 365 : Chaque instance est conçue pour tester une région particulière à l’aide de points de fin de test dans Office 365.

Pour des tests plus directs et détaillés depuis des ordinateurs clients sur votre réseau vers votre service Office 365, vous pouvez installer Microsoft Exchange Client Performance Analyzer et l’exécuter à partir de plusieurs stations de travail et à intervalles réguliers en mode silencieux.

Pour vous aider à diagnostiquer et à résoudre les problèmes liés à Outlook 365 sur votre ordinateur local, vous pouvez télécharger la Résolution des problèmes liés à Outlook et à Office 365 via l’Assistant Support et récupération de Microsoft pour Office 365.

 

Facteur Description Meilleures pratiques

Capacité réseau

La durée nécessaire à la migration de boîtes aux lettres vers Exchange Online est déterminée par la capacité disponible et maximale de votre réseau.

  • Identifiez votre capacité réseau disponible et déterminez la capacité de téléchargement maximale.

  • Contactez votre fournisseur de services Internet afin de vérifier la bande passante qui vous est allouée et d’obtenir des détails concernant les restrictions, telles que la quantité totale de données qui peut être transférée dans un délai donné.

  • Utilisez des outils pour évaluer votre capacité réseau réelle. Veillez à tester le flux de données de bout en bout, de votre source de données sur site jusqu’aux serveurs de passerelles des centres de données Microsoft.

  • Identifiez les autres charges sur votre réseau (par exemple les utilitaires de sauvegarde ou la maintenance planifiée) susceptibles d’affecter votre capacité réseau.

Stabilité du réseau

Un réseau rapide n’est pas toujours synonyme de migration rapide. Si le réseau est instable, le transfert de données est plus long à cause de la correction d’erreur. Selon le type de migration, il se peut que la correction d’erreur affecte les performances de migration de manière significative.

Les problèmes de pilotes et de matériel réseau sont souvent la cause des problèmes de stabilité du réseau. Collaborez avec vos fournisseurs de matériel afin de mieux comprendre le fonctionnement de vos périphériques réseau et appliquez les pilotes et mises à jour logicielles les plus récents recommandés par le fournisseur.

Délais réseau

La fonctionnalité de détection d’intrusion configurée sur un pare-feu réseau provoque souvent d’importants délais réseau et affecte les performances de migration.

La migration de données vers des boîtes aux lettres Exchange Online repose sur votre connexion Internet. Les délais Internet nuisent aux performances de migration globales.

Par ailleurs, il se peut que les utilisateurs d’une même société disposent de boîtes aux lettres en nuage qui résident dans des centres de données à différents emplacements géographiques. Selon le fournisseur de services Internet du client, il se peut que les performances de migration varient.

  • Évaluez les délais réseau vers tous les centres de données Microsoft potentiels pour vous assurer que les résultats sont cohérents. (Cela permet également de garantir une expérience cohérente pour les utilisateurs finaux). Collaborez avec votre fournisseur de services Internet afin de résoudre les problèmes liés à Internet.

  • Ajoutez les adresses IP des serveurs du centre de données Microsoft à votre liste d’autorisations ou contournez tout le trafic lié à la migration à partir de votre pare-feu réseau. Pour plus d’informations sur les plages d’adresses IP Office 365, consultez la rubrique URL et plages d’adresses IP Office 365.

Pour une analyse plus approfondie des migrations au sein de votre environnement, consultez notre billet de blog sur l’analyse des déplacements qui inclut un script permettant d’analyser les demandes de déplacement.

Office 365 utilise différents mécanismes de limitation afin de garantir la sécurité et la disponibilité du service. Les trois types de limitations suivants peuvent avoir une incidence sur les performances de migration :

  • Limitation d’utilisateurs

  • Limitation du service de migration

  • Limitation basée sur l’intégrité des ressources

RemarqueRemarque :
Ces trois types de limitations Office 365 ne concernent pas toutes les méthodes de migration.

La limitation d’utilisateurs concerne la plupart des outils de migration tiers et la méthode de migration de téléchargement par les clients. Ces méthodes de migration font appel à des protocoles d’accès au client, tels que RPC sur HTTP, pour migrer des données de boîtes aux lettres vers des boîtes aux lettres Exchange Online. Ces outils servent en général à migrer des données à partir de plateformes comme IBM Lotus Domino et Novell GroupWise.

La limitation d’utilisateurs est la méthode de limitation la plus restrictive dans Office 365. Étant donné qu’elle est configurée pour opérer sur un utilisateur final spécifique, toute utilisation au niveau de l’application dépassera facilement les valeurs de stratégie de limitation et entraînera un ralentissement de la migration des données.

La limitation du service de migration concerne tous les outils de migration Office 365. Elle gère la simultanéité de migration et l’allocation des ressources de service pour les solutions de migration Office 365.

La limitation du service de migration concerne les migrations effectuées à l’aide des méthodes de migration suivantes :

  • Migration IMAP

  • Migration Exchange à basculement

  • Migration Exchange intermédiaire

  • Migrations hybrides (déplacements basés sur MRSProxy dans un environnement hybride)

Le contrôle du nombre de boîtes aux lettres migrées simultanément durant des migrations IMAP et des migrations Exchange simples constitue un exemple de limitation du service de migration. La valeur par défaut est 10. Cela signifie qu’un maximum de trois boîtes aux lettres sont migrées à tout moment pendant la migration. Vous pouvez augmenter le nombre de migrations de boîtes aux lettres simultanées pour un lot de migrations dans le Panneau de configuration Exchange ou avec Windows PowerShell. Pour en savoir plus sur la façon d’optimiser ce paramètre, consultez la rubrique Gestion des lots de migration dans Exchange Online.

Toutes les méthodes de migration sont sujettes à la gouvernance de limitation de disponibilité, mais la limitation du service Office 365 n’a pas autant d’incidence sur les migrations Office 365 que les autres types de limitations décrits dans les sections précédentes.

La limitation basée sur l’intégrité des ressources est la méthode de limitation la moins agressive. Elle a lieu uniquement en cas de problème de disponibilité du service qui a un impact sur les utilisateurs finaux et les opérations de service critiques.

Par exemple, si un incident de service se produit durant une migration hybride et que le service se dégrade au point que les performances pour les utilisateurs finals diminuent, la migration hybride est mise en file d’attente jusqu’à ce que les performances redeviennent acceptables et que le service revienne à un niveau inférieur au seuil de limitation.

Voici un exemple de rapport de statistiques de migration Exchange qui montre une entrée due à un dépassement du seuil de limitation de service.

  • 25/01/2012 12:56:01 AM [BL2PRD0410CA012] Avancement de la copie: 723/1456 messages, 225,8 Mo (236,732,045 octets)/416,5 Mo (436,712,733 octets).

  • 25/01/2012 12:57:53 AM [BL2PRD0410CA012] Le déplacement de la boîte aux lettres '/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' est bloqué car DataMoveReplicationConstraint ne satisfait pas la base de données 'NAMPRD04DG031-db081' (agent MailboxDatabaseReplication). Raison de l’échec: La base de données edbf0766-1f2a-4552-9115-bb3a53a8380b ne satisfait pas à la contrainte SecondDatacenter. Il n’existe aucune copie de base de données en bon état disponible. Le système attendra jusqu'au 25/01/2012 1:27:53 AM.

  • 1/25/2012 12:58:24 AM [BL2PRD0410CA012] La demande n'est plus bloquée et va continuer.

Solution et pratique

Si vous rencontrez une situation similaire, attendez que la récupération par service Office 365 soit effectuée. Pour plus d’informations, consultez la section sur l’état du service sur le Portail Office 365.

Cette section décrit les facteurs qui ont une incidence sur les migrations à l’aide des méthodes de migration IMAP, à basculement ou intermédiaire et des meilleures pratiques pour améliorer les performances de migration.

Le tableau suivant décrit l’impact des serveurs sources dans votre organisation de messagerie actuelle sur la migration et les meilleures pratiques pour atténuer cet impact.

 

Liste de vérification Description Meilleures pratiques

Performances du système

L’extraction des données est une tâche intensive. Le système source doit disposer de ressources suffisantes (temps processeur et mémoire) afin de fournir des performances de migration optimales. Durant la migration, le système source fonctionne souvent à pleine capacité en termes de charge de travail d’utilisateurs finals ordinaire. Si les ressources système sont inadéquates, la charge de travail supplémentaire qui résulte de la migration peut affecter les utilisateurs finaux.

Surveillez les performances système durant un test de migration pilote. Si le système est occupé, nous déconseillons l’utilisation d’un planning de migration progressive pour le système en question, étant donné les problèmes potentiels de disponibilité du service et de lenteur de migration. Dans la mesure du possible, améliorez les performances du système source en ajoutant des ressources matérielles et en réduisant la charge sur le système en déplaçant des tâches et des utilisateurs vers d’autres serveurs qui ne sont pas concernés par la migration.

Pour plus d’informations, consultez les rubriques suivantes :

Lors de la migration à partir d’une organisation Exchange sur site comportant plusieurs serveurs de boîtes aux lettres, nous vous conseillons de créer une liste d’utilisateurs de migration distribuée de manière égale parmi les différents serveurs de boîtes aux lettres. En fonction des performances de chaque serveur, cette liste peut être affinée en vue d’optimiser le débit.

Par exemple, si le serveur A présente une disponibilité des ressources supérieure de 50 pour cent à celle du serveur B, il est raisonnable de compter 50 pour cent d’utilisateurs du serveur A en plus dans le même lot de migration. Des pratiques similaires peuvent être appliquées à d’autres systèmes sources. Effectuez les migrations lorsque les serveurs disposent d’une disponibilité des ressources maximale, par exemple en dehors des heures de travail ou lors des week-ends ou jours fériés.

Tâches principales

D’autres tâches principales s’exécutent au moment de la migration. Étant donné qu’il est préférable d’effectuer la migration en dehors des heures de travail, les migrations peuvent entrer en conflit avec d’autres tâches de maintenance exécutées sur vos serveurs locaux, telles que les sauvegardes de données.

Examinez les autres tâches système susceptibles de s’exécuter durant la migration. Nous vous recommandons d’effectuer la migration des données lorsqu’aucune autre tâche nécessitant de nombreuses ressources ne s’exécute.

Remarque   Pour les clients qui utilisent Microsoft Exchange localement, les tâches principales courantes sont les solutions de sauvegarde et la Maintenance de la banque d’informations Exchange.

Stratégie de limitation

La protection des systèmes de messagerie à l’aide d’une stratégie de limitation est une pratique courante ; celle-ci définit une limite spécifique quant à la rapidité et la quantité de données pouvant être extraites du système durant une période spécifique.

Vérifiez la stratégie de limitation déployée pour votre système de messagerie. Par exemple, Google Mail limite la quantité de données pouvant être extraites pendant une certaine période.

En fonction de la version, Microsoft Exchange propose des stratégies qui limitent l’accès IMAP au serveur de messagerie sur site (utilisé par les migrations IMAP) et l’accès RPC sur HTTP (utilisé par les migrations Exchange à basculement et les migrations Exchange intermédiaires).

Pour vérifier les paramètres de limitation dans une organisation Exchange 2013, exécutez la cmdlet Get-ThrottlingPolicy. Pour plus d’informations, consultez la page Gestion de la charge de travail Exchange.

Pour plus d’informations sur la limitation IMAP, consultez la rubrique Migration du courrier électronique à partir d'un serveur IMAP vers des boîtes aux lettres Exchange Online.

Pour plus d’informations sur la limitation RPC sur HTTP, consultez les sections suivantes :

Les migrations IMAP, à basculement et intermédiaire sont des méthodes de migration par extraction de données initiée en nuage, donc aucun serveur de migration dédié n’est nécessaire. Cependant, les hôtes de protocole avec accès à Internet (IMAP ou RPC sur HTTP) fonctionnent comme serveurs de migration pour la migration des boîtes aux lettres et de leurs données vers Office 365. Ainsi, les facteurs de performances de migration et les meilleures pratiques décrits dans la section précédente concernant le serveur de source de données de votre organisation de messagerie actuelle, s’appliquent également aux serveurs Edge Internet. Pour les organisations Exchange 2013, 2010 et 2007, le serveur d’accès au client assume la fonction de serveur de migration.

Pour plus d’informations, consultez les rubriques suivantes :

  1. Gestion de la charge de travail Exchange 2013

  2. Exchange 2010 : compteurs de serveurs d’accès au client

  3. Exchange 2007 : surveillance des serveurs d’accès au client

Solution et pratique

Pour améliorer les performances de migration, appliquez les mêmes meilleures pratiques décrites précédemment.

Les migrations Exchange IMAP, à basculement et intermédiaire sont effectuées à l’aide du tableau de bord de migration dans le Centre d’administration Exchange (CAE) Exchange Online. Cet outil est soumis aux limitations du service de migration Office 365.

Solution et pratique

Les clients peuvent désormais spécifier les paramètres de simultanéité de migration (par exemple le nombre de boîtes aux lettres à migrer simultanément) à l’aide de Windows PowerShell. La valeur par défaut est 20. Après avoir créé un lot de migration, vous pouvez utiliser la commande Windows PowerShell suivante pour l’augmenter jusqu’à un maximum de 100.

Set-MigrationEndPoint <Identity> -MaxConcurrentMigrations <value between 1 and 100>

Pour plus d’informations, consultez la rubrique Gestion des lots de migration dans Exchange Online.

RemarqueRemarque :
Si votre source de données ne dispose pas de ressources suffisantes pour gérer toutes les connexions, nous déconseillons d’utiliser une simultanéité élevée. Commencez à 10, puis augmentez ce chiffre tout en surveillant les performances de la source de données afin d’éviter tout problème d’accès pour les utilisateurs finaux.

Tests de vérification

Vous pouvez essayer de réaliser les tests de vérification suivants, selon la méthode de migration employée :

  • Migrations IMAP   Préremplissez une boîte aux lettres source avec des exemples de données. Ensuite, depuis Internet (en dehors de votre réseau sur site), connectez-vous à la boîte aux lettres source à l’aide d’un client de messagerie IMAP standard, tel que Microsoft Outlook, puis mesurez les performances réseau en déterminant la durée nécessaire pour télécharger toutes les données à partir de la boîte aux lettres source. Le débit doit être semblable à celui que les clients peuvent obtenir à l’aide de l’outil de migration IMAP dans Office 365, étant donné l’absence d’autres contraintes.

  • Migrations Exchange à basculement et intermédiaire   Préremplissez une boîte aux lettres source avec des exemples de données. Ensuite, depuis Internet (en dehors de votre réseau sur site), connectez-vous à la boîte aux lettres source avec Microsoft Outlook à l’aide de RPC sur HTTP. Veillez à vous connecter à l’aide du mode mis en cache. Mesurez les performances réseau en vérifiant la durée nécessaire pour synchroniser toutes les données à partir de la boîte aux lettres source. Le débit doit être semblable à celui que les clients peuvent obtenir à l’aide des outils de migration Exchange simples dans Office 365, étant donné l’absence d’autres contraintes.

RemarqueRemarque :
Il existe une surcharge durant une migration Exchange IMAP, à basculement ou intermédiaire réelle, mais le débit réel doit être semblable aux résultats de ces tests de vérification.

La limitation basée sur l’intégrité des ressources Office 365 concerne les migrations qui utilisent les outils de migration simple Office 365 natifs. Reportez-vous à la section relative à la limitation basée sur l’intégrité des ressources Office 365.

La migration du déploiement hybride prend en charge la migration en douceur entre des serveurs Exchange 2003, Exchange 2007, Exchange 2010 et Exchange 2013 sur site et Exchange Online dans Office 365.

La migration du déploiement hybride est de loin la méthode de migration la plus rapide pour la migration de données de boîtes aux lettres vers Office 365. Nous avons constaté un débit allant jusqu’à 100 Go/heure pendant les déploiements clients réels. Le tableau suivant fournit la liste des facteurs qui s’appliquent aux scénarios de migration hybride Office 365 natifs.

 

Liste de vérification Description Meilleures pratiques

Performances du système

L’extraction des données est une tâche intensive. Le système source doit disposer de ressources suffisantes (temps processeur et mémoire) afin de fournir de meilleures performances de migration. Au moment de la migration, le système source approche généralement sa pleine capacité pour une charge de travail d’utilisateurs finaux ordinaire ; une charge de travail de migration supplémentaire réduit même parfois l’accès des utilisateurs finaux en raison d’une insuffisance de ressources système.

Surveillez les performances système lors du test de migration pilote. Si le système est occupé, nous déconseillons l’utilisation d’une planification de migration agressive pour le système en question, car elle pourrait entraîner des problèmes de disponibilité du service et de lenteur de migration. Dans la mesure du possible, améliorez les performances du système source en ajoutant des ressources matérielles et en réduisant la charge sur le système en déplaçant des tâches et des utilisateurs vers d’autres serveurs qui ne sont pas concernés par la migration.

Pour plus d’informations, consultez les rubriques suivantes :

Lors de la migration à partir d’une organisation Exchange sur site comportant plusieurs serveurs de boîtes aux lettres et plusieurs bases de données, nous vous conseillons de créer une liste d’utilisateurs de migration distribuée de manière égale parmi les différents serveurs de boîtes aux lettres et bases de données. En fonction des performances de chaque serveur, cette liste peut être affinée en vue d’optimiser le débit.

Par exemple, si le serveur A présente une disponibilité des ressources supérieure de 50 pour cent à celle du serveur B, il est raisonnable de compter 50 pour cent d’utilisateurs du serveur A en plus dans le même lot de migration. Des pratiques similaires peuvent être appliquées à d’autres systèmes sources.

Effectuez les migrations lorsque les serveurs disposent d’une disponibilité des ressources maximale, par exemple en dehors des heures de travail ou lors des week-ends ou jours fériés.

Tâches principales

D’autres tâches principales s’exécutent au moment de la migration. Étant donné qu’il est préférable d’effectuer la migration en dehors des heures de travail, les migrations peuvent entrer en conflit avec d’autres tâches de maintenance exécutées sur vos serveurs locaux, telles que les sauvegardes de données.

Examinez les autres tâches système susceptibles de s’exécuter durant la migration. Nous vous recommandons d’effectuer la migration des données lorsqu’aucune autre tâche nécessitant de nombreuses ressources ne s’exécute.

Remarque   Pour les clients qui utilisent Microsoft Exchange localement, les tâches principales courantes sont les solutions de sauvegarde et la Maintenance de la banque d’informations Exchange.

La migration du déploiement hybride est une migration par extraction et envoi de données initiée en nuage et un serveur hybride Exchange 2013 ou Exchange 2010 SP3 agit comme serveur de migration. Cet aspect ne reçoit généralement pas l’attention qu’il mérite, et les clients utilisent un ordinateur virtuel peu puissant comme serveur hybride. Cela entraîne des performances de migration médiocres.

Meilleure pratique

En plus de l’application des meilleures pratiques décrites précédemment, nous avons testé les meilleures pratiques suivantes, lesquelles ont permis d’améliorer les performances de migration lors de migrations réelles chez des clients :

  • Utilisez de puissants ordinateurs physiques de classe serveur au lieu d’ordinateurs virtuels pour les serveurs hybrides Exchange 2013 et 2010.

  • Utilisez plusieurs serveurs hybrides placés derrière le mécanisme d’équilibrage de la charge réseau du client.

Par exemple, lors de migrations réelles chez des clients, nous avons obtenu un débit régulier de 30 Go/heure avec la configuration suivante :

  • Réseau   Canal sortant 500 Mo vers Internet ; réseau interne sur 1 Go avec dorsale principale fibre de 10 Go.

  • Matériel   Caractéristiques des deux serveurs (physiques) Accès au client/Concentrateur:

    • UC: Processeur Intel® Xeon® E5520 @ 2,27 GHz 2,26 GHz (deux processeurs).

    • RAM: 24 Go.

    • Disques : huit, 146 Go par disque. Configuration RAID 5 = 960 Go d’espace total brut.

  • MRSProxy   Configuré avec une simultanéité de 100.

La migration du déploiement hybride utilise les outils Office 365 natifs. Elle est soumise à la limitation de service de migration Office 365.

Différences entre Exchange 2003 et Exchange 2007 SP2, Exchange 2010 SP3 et Exchange 2013 SP1

Il existe une différence clé dans l’expérience de l’utilisateur final lors de la migration à partir d’Exchange 2003. À la différence d’Exchange 2007 SP2 et d’Exchange 2010 SP3 et d’Exchange 2013 SP1, les utilisateurs finaux d’Exchange 2003 ne peuvent pas accéder à leurs boîtes aux lettres lors de la migration de leurs données. Par conséquent, les clients d’Exchange 2003 se soucient généralement davantage du moment où les migrations sont planifiées et de la durée nécessaire aux migrations, en particulier quand les performances de migration sont faibles en raison de la lenteur du réseau ou de la taille importante des boîtes aux lettres.

La migration Exchange 2003 est également très sensible aux interruptions. Par exemple, dans une migration de client réelle, durant la migration d’une boîte aux lettres de 10 Go, un incident de service s’est produit à mi-parcours de la migration. Le serveur d’accès au client Office 365, qui traitait la migration des données, a dû être redémarré pour résoudre le problème. La migration de la boîte aux lettres a donc dû être redémarrée et il a fallu recommencer la migration des 10 Go de données. La migration n’a pas pu être reprise à partir du point où elle avait été interrompue. Exchange 2007 SP2, Exchange 2010 SP3 et Exchange 2013 SP1, quant à eux, peuvent reprendre les migrations après des interruptions.

Meilleure pratique

Certains clients choisissent d’effectuer des migrations à deux sauts pour les boîtes aux lettres Exchange 2003 sensibles et de taille importante :

  • Premier saut   Migrez les boîtes aux lettres d’Exchange 2003 vers un serveur Exchange 2010 SP3, qui est généralement le serveur hybride. Le premier saut est un déplacement hors connexion, mais il s’agit en général d’une migration très rapide sur un réseau local.

  • Second saut   Migrez les boîtes aux lettres d’Exchange 2010 SP3 vers Office 365.

Le second saut est un déplacement en ligne, ce qui procure une meilleure expérience utilisateur et une tolérance des pannes. Cette approche en deux sauts requiert une licence Exchange 2010 pour la boîte aux lettres utilisateur Exchange 2010 sur site temporaire.

Proxy du service de réplication de boîtes aux lettres (MRSProxy)

Le proxy MRS est la fonctionnalité de migration sur site qui fonctionne avec le service de réplication de boîtes aux lettres exécuté côté Office 365. Pour plus d’informations, consultez la rubrique Présentation des demandes de déplacement.

Meilleure pratique

Il est possible de configurer la quantité maximale de connexions MRSProxy pour Exchange 2010 SP3 sur site. Exécutez la commande Windows PowerShell suivante.

Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSMaxConnections <number between 0 and unlimited; default is 100>
RemarqueRemarque :
Pour la plupart des migrations de clients, il est inutile de modifier la valeur de MRSMaxConnections par défaut. Si vous devez protéger le serveur source contre la surcharge de migration, vous pouvez réduire le nombre de connexions. Ce paramètre s’applique pour chaque serveur MRSProxy. Si un client a deux serveurs MRSProxy, chacun défini pour 10 connexions, il obtiendra 20 (2x10) comme quantité totale de connexions de MRSProxy. Pour plus d’informations sur la configuration du service MRSProxy dans votre organisation Exchange 2010 sur site, consultez la rubrique Démarrer le service MRSProxy sur un serveur d’accès client distant.

RemarqueRemarque :
Pour la plupart des migrations de clients, il est inutile de modifier la valeur de MRSMaxConnections par défaut. Si vous devez protéger le serveur source contre la surcharge de migration, vous pouvez réduire le nombre de connexions. Ce paramètre s’applique pour chaque serveur MRSProxy. Si un client a deux serveurs MRSProxy, chacun défini pour 10 connexions, il obtiendra 20 (2x10) comme quantité totale de connexions de MRSProxy. Pour plus d’informations sur la configuration du service de proxy MRS dans votre organisation Exchange 2010 sur site, consultez la rubrique Démarrer le service MRSProxy sur un serveur d’accès client distant.

Tests de vérification

Pour les clients Exchange 2013 et 2010, les tests de performances réseau pour les migrations hybrides peuvent être réalisés en effectuant plusieurs migrations de boîtes aux lettres tests. En guise d’alternative, vous pouvez migrer des boîtes aux lettres utilisateur réelles avec l’option -SuspendWhenReadyToComplete pour obtenir une indication des performances de migration. Une fois les tests terminés, supprimez la demande de déplacement afin d’éviter toute incidence sur les utilisateurs finaux.

Pour plus d’informations sur les demandes de déplacement d’Exchange 2013, consultez la rubrique New-MoveRequest.

Pour plus d’informations sur les demandes de déplacement d’Exchange 2010, consultez la rubrique New-MoveRequest.

La limitation basée sur l’intégrité des ressources Office 365 concerne les migrations qui utilisent les migrations du déploiement hybride Office 365. Pour plus d’informations, consultez la section ci-dessus relative à la limitation basée sur l’intégrité des ressources Office 365.

Pour obtenir des informations d’ordre général sur l’obtention d’informations d’état pour les demandes de déplacement, voir Afficher les propriétés d’une demande de déplacement.

Dans le service Office 365, il existe une différence essentielle par rapport aux organisations Exchange 2010 sur site ordinaires lors de l’exécution de demandes de déplacement. Dans Office 365, la file d’attente de migration et les ressources de service allouées pour les migrations sont partagées par les clients. Ceci affecte le mode de gestion des demandes de déplacement à chaque étape du processus de déplacement.

Il existe deux types de demandes de déplacement dans Office 365 :

  • Nouvelles demandes de déplacement   Les nouvelles migrations de clients sont considérées comme de nouvelles demandes de déplacement. Ces demandes ont une priorité ordinaire.

  • Demandes de déplacement interne au centre de données   Il s’agit de demandes de déplacement de boîtes aux lettres initiées par des équipes d’exploitation de centre de données. Ces demandes ont une priorité inférieure car l’expérience de l’utilisateur final n’est pas altérée en cas de retard de la demande de déplacement.

  • Demandes de déplacement mises en file d’attente   Cet état indique que le déplacement a été mis en file d’attente et qu’il attend d’être sélectionné par le service de réplication de boîte aux lettres Microsoft Exchange. Pour les demandes de déplacement Exchange 2003, les utilisateurs peuvent toujours accéder à leurs boîtes aux lettres à cette étape.

    Deux facteurs influencent la sélection de la demande par le service de réplication de boîte aux lettres:

    • Priorité   Les demandes de déplacement mises en file d’attente avec une priorité élevée sont sélectionnées avant les demandes de déplacement de plus faible priorité. Cela permet de s’assurer que les demandes de déplacement pour migration de client sont toujours traitées avant les demandes de déplacement internes au centre de données.

    • Position dans la file d’attente   Si des demandes de déplacement ont la même priorité, celle qui se trouve dans la file d’attente depuis le plus longtemps est sélectionnée par le service de réplication de boîte aux lettres. Étant donné que plusieurs clients peuvent effectuer des migrations de boîtes aux lettres en même temps, il est normal que les nouvelles demandes de déplacement restent dans la file d’attente avant d’être traitées.

      Bien souvent, la durée d’attente des demandes de boîte aux lettres dans la file avant leur traitement n’est pas un paramètre pris en compte durant la planification de la migration. Les clients n’ont dans ce cas pas suffisamment de temps pour terminer toutes les migrations planifiées.

  • Demandes de déplacement en cours   Cet état indique que le déplacement est toujours en cours. S’il s’agit d’un déplacement de boîte aux lettres en ligne, l’utilisateur peut encore avoir accès à la boîte aux lettres. Pour les déplacements de boîtes aux lettres hors connexion, la boîte aux lettres de l’utilisateur est indisponible.

    Dès lors que l’état de la demande de déplacement de boîte aux lettres est « En cours », la priorité n’a plus d’importance et aucune nouvelle demande de déplacement n’est traitée tant qu’aucune demande de déplacement En cours existante n’est terminée, même si la nouvelle demande de déplacement a une priorité plus élevée.

Planification   Comme mentionné précédemment, étant donné que les utilisateurs d’Exchange 2003 perdent l’accès durant une migration hybride, les clients d’Exchange 2003 se soucient généralement davantage du moment où la migration est prévue et de sa durée.

Lors de la planification du nombre de boîtes aux lettres à migrer durant une période spécifique, prenez en compte les recommandations suivantes :

  • Incluez la durée d’attente de la demande de déplacement dans la file d’attente. Pour calculer cette durée, utilisez la formule suivante:

    (nombre total de boîtes aux lettres à migrer) = {(durée totale) – (durée moyenne en file d’attente)} * (débit de migration)

    où le débit de migration est égal à la quantité totale de boîtes aux lettres pouvant être migrées par heure.

    Par exemple, supposons que vous disposez d’une plage de six heures pour migrer les boîtes aux lettres. Si la durée moyenne en file d’attente est d’une heure et que le débit de migration est de 100 boîtes aux lettres par heure, vous pouvez migrer 500 boîtes aux lettres dans les six heures imparties : 500 = (6 – 1) * 100.

  • Commencez la migration plus tôt que prévu initialement afin d’atténuer la durée en file d’attente. Lorsque les boîtes aux lettres sont dans la file d’attente, les utilisateurs d’Exchange 2003 peuvent toujours y accéder.

Détermination de la durée en file d’attente   La durée en file d’attente change constamment car Microsoft ne gère pas les planifications de migration des clients.

Pour déterminer la durée potentielle en file d’attente, un client peut essayer de planifier un déplacement test plusieurs heures avant le début de la migration réelle. Ensuite, en fonction de la durée de présence en file d’attente des demandes observée, il sera plus facile de déterminer quand commencer la migration et combien de boîtes aux lettres pourront être déplacées durant une période spécifique.

Par exemple, supposons qu’une migration test a été effectuée quatre heures avant le début d’une migration planifiée. Le client détermine que la durée en file d’attente pour la migration test était d’environ une heure. Dans ce cas, il est préférable de commencer la migration une heure plus tôt que prévu initialement, afin d’être sûr de disposer d’un délai suffisant pour effectuer toutes les migrations.

Les outils tiers sont principalement utilisés dans les scénarios de migration qui n’impliquent pas Exchange, tels que ceux de Google Mail, IBM Lotus Domino et Novell GroupWise. Cette section se concentre sur les protocoles de migration utilisés par les outils de migration tiers, plutôt que sur les produits et outils de migration réels. Le tableau suivant fournit une liste de facteurs qui s’appliquent à des outils tiers pour les scénarios de migration Office 365.

 

Liste de vérification Description Meilleures pratiques

Performances du système

L’extraction des données est une tâche intensive. Le système source doit disposer de ressources suffisantes (temps processeur et mémoire) afin de fournir des performances de migration optimales. Durant la migration, le système source fonctionne souvent à pleine capacité en matière de charge de travail d’utilisateurs finaux ordinaire. Si les ressources système sont inadéquates, la charge de travail supplémentaire qui résulte de la migration peut affecter les utilisateurs finaux.

Surveillez les performances système lors du test de migration pilote. Si le système est occupé, nous déconseillons l’utilisation d’une planification de migration agressive pour le système en question, car elle pourrait entraîner des problèmes de disponibilité du service et de lenteur de migration. Dans la mesure du possible, améliorez les performances du système source en ajoutant des ressources matérielles ou en réduisant la charge sur le système en déplaçant des tâches et des utilisateurs vers d’autres serveurs qui ne sont pas concernés par la migration.

Pour plus d'informations, consultez les rubriques suivantes :

Lors de la migration à partir d’une organisation Exchange sur site comportant plusieurs serveurs de boîtes aux lettres, nous vous recommandons de créer une liste d’utilisateurs de migration distribuée de manière égale parmi les différents serveurs de boîtes aux lettres. En fonction des performances de chaque serveur, cette liste peut être affinée en vue d’optimiser le débit.

Par exemple, si le serveur A présente une disponibilité des ressources supérieure de 50 pour cent à celle du serveur B, il est raisonnable de compter 50 pour cent d’utilisateurs du serveur A en plus dans le même lot de migration. Des pratiques similaires peuvent être appliquées à d’autres systèmes sources.

Effectuez la migration lorsque le système dispose d’une disponibilité des ressources maximale, par exemple en dehors des heures de travail ou lors des week-ends ou jours fériés.

Tâches principales

D’autres tâches principales sont généralement exécutées au moment de la migration. Étant donné qu’il est préférable d’effectuer la migration en dehors des heures de travail, les migrations peuvent entrer en conflit avec d’autres tâches de maintenance exécutées sur vos serveurs locaux, telles que les sauvegardes de données.

Examinez les autres tâches système qui s’exécutent durant la migration. Nous vous recommandons de réserver un créneau horaire pour la migration des données, à un moment où aucune autre tâche nécessitant de nombreuses ressources ne s’exécute.

Pour les clients qui utilisent Microsoft Exchange sur site, les tâches courantes sont les solutions de sauvegarde. Pour plus d’informations, consultez la rubrique Maintenance de la banque d’informations Exchange.

Stratégie de limitation

La protection des systèmes de messagerie à l’aide d’une stratégie de limitation est une pratique courante ; celle-ci définit une limite spécifique quant à la rapidité et la quantité de données pouvant être extraites du système durant une période spécifique. La protection des systèmes de messagerie s’obtient également en ayant recours à une méthode de migration spécifique.

Vérifiez la stratégie de limitation déployée pour votre système de messagerie. Par exemple, Google Mail limite la quantité de données pouvant être extraites pendant une certaine période.

En fonction de la version, Microsoft Exchange propose des stratégies qui limitent l’accès IMAP au serveur de messagerie sur site (utilisé par les migrations IMAP) et l’accès RPC sur HTTP (utilisé par les migrations Exchange à basculement et les migrations Exchange intermédiaires).

Pour plus d’informations sur la limitation IMAP, consultez la rubrique Migration du courrier électronique à partir d'un serveur IMAP vers des boîtes aux lettres Exchange Online.

Pour plus d’informations sur la limitation RPC sur HTTP, consultez les sections suivantes :

Pour plus d’informations sur la configuration de la limitation EWS, consultez la rubrique Exchange 2010 : présentation des stratégies de limitation du client.

La plupart des outils tiers pour les migrations Office 365 sont initiés par le client et envoient les données vers Office 365. Ces outils exigent généralement l’utilisation d’un serveur de migration. Des facteurs tels que les performances système, les tâches principales et les stratégies de limitation pour les serveurs sources s’appliquent à ces serveurs de migration.

RemarqueRemarque :
Certaines solutions de migration tierces sont hébergées sur Internet en tant que services informatiques et ne nécessitent aucun serveur de migration sur site.

Solution et pratique

Pour améliorer les performances de migration lors de l’utilisation d’un serveur de migration, appliquez les mêmes meilleures pratiques que celles décrites à la section relative aux serveurs de source de données.

Pour les outils de migration tiers, les protocoles les plus couramment utilisés sont Exchange Web Service et RPC sur HTTP.

Services web Exchange

Le protocole des services web Exchange (EWS) est recommandé pour la migration vers Office 365 car il prend en charge les lots de données volumineux et offre une meilleure limitation orientée vers le service. Dans Office 365, les migrations qui utilisent EWS en mode d’emprunt d’identité n’utilisent pas la quantité budgétisée de ressources EWS Office 365 de l’utilisateur, mais une copie des ressources budgétisées.

  • Tous les appels EWS à emprunt d’identité effectués par le même compte d’administration sont calculés séparément du budget appliqué à ce compte d’administration.

  • Pour chaque session d’emprunt d’identité, un cliché instantané du budget de l’utilisateur réel est créé. Toutes les migrations pour cette session en particulier utiliseront ce cliché.

  • La limitation sous emprunt d’identité est isolée pour chaque session de migration utilisateur.

Meilleures pratiques

  • Les performances de migration pour les clients utilisant des outils de migration tiers qui font appel à l’emprunt d’identité EWS sont en concurrence avec les migrations basées sur EWS et l’utilisation des ressources de service par d’autres clients. Par conséquent, les performances de migration varieront.

  • Dans la mesure du possible, les clients doivent utiliser des outils de migration tiers qui ont recours à l’emprunt d’identité EWS, car cela est plus rapide et plus efficace que d’utiliser des protocoles clients tels que RPC sur HTTP.

RPC sur HTTP

De nombreuses solutions de migration traditionnelles utilisent le protocole RPC sur HTTP. Cette méthode est entièrement basée sur un modèle d’accès au client tel que celui d’Outlook et les performances et l’extensibilité sont limitées car le service Office 365 limite l’accès en partant du principe que l’utilisation est due à un utilisateur plutôt qu’à une application.

Meilleures pratiques

  • Pour les outils de migration qui utilisent le protocole RPC sur HTTP, il est courant d’augmenter le débit de migration en ajoutant des serveurs de migration et en ayant recours à des comptes d’utilisateurs d’administration Office 365. Cette pratique peut permettre de gagner en parallélisme d’injection des données et permettre un débit de données plus élevé, car chaque utilisateur d’administration est sujet à la limitation d’utilisateur O365. De nombreuses entreprises clientes nous ont signalé avoir été obligées de configurer plus de 40 serveurs de migration pour obtenir un débit de migration de 20 à 30 Go par heure.

  • Lors de la phase de développement d’un outil de migration, il est essentiel de prendre en compte le nombre d’opérations RPC nécessaires pour migrer un message. Pour illustrer cette caractéristique, nous avons collecté des journaux capturés par les services Office 365 pour deux solutions de migration tierces (développées par des sociétés tierces) utilisées par les clients pour migrer des boîtes aux lettres vers Office 365. Nous avons comparé deux solutions de migration développées par des sociétés tierces. Nous avons comparé la migration de deux boîtes aux lettres pour chaque solution de migration. De plus, nous avons également comparé ces solutions pour le téléchargement d’un fichier PST dans Microsoft Outlook. Voici les résultats.

     

    Méthode Taille de boîte aux lettres nombre d'éléments Durée de migration Nombre total de transactions RPC Latence de client moyenne (ms) AvgCasRPCProcessingTime (ms)

    Solution A (boîte aux lettres 1)

    376,9 Mo

    4,115

    4:24:33

    132,040

    48.4395

    18.0807

    Solution A (boîte aux lettres 2)

    249,3 Mo

    12,779

    10:50:50

    423,188

    44.1678

    4.8444

    Solution B (boîte aux lettres 1)

    618,1 Mo

    4,322

    1:54:58

    12,196

    37.2931

    8.3441

    Solution B (boîte aux lettres 2)

    56,7 Mo

    2,748

    0:47:08

    5,806

    42.1930

    7.4439

    Outlook

    201.9MB

    3,297

    0:29:47

    15,775

    36.9987

    5.6447

    Notez que les durées de traitement de service et client sont similaires, mais que la solution A nécessite beaucoup plus d’opérations RPC pour migrer les données. Chaque opération consommant du temps de latence client et du temps de traitement serveur, la solution A est beaucoup plus longue à migrer la même quantité de données, comparé à la solution B et à Outlook.

Meilleure pratique

Pour les solutions de migration tierces qui utilisent le protocole RPC sur HTTP, voici un excellent moyen de mesurer les performances de migration potentielles :

  1. À partir du serveur de migration, connectez-vous à la boîte aux lettres Office 365 avec Microsoft Outlook en utilisant le protocole RPC sur HTTP ; veillez à ne pas vous connecter en mode mis en cache.

  2. Importez un fichier PST volumineux contenant des exemples de données vers la boîte aux lettres Exchange Online.

  3. Mesurez les performances de migration en chronométrant la durée nécessaire au téléchargement du fichier PST. Le débit de migration doit être semblable à celui que peuvent obtenir les clients avec un outil de migration tiers qui utilise RPC sur HTTP en l’absence d’autres contraintes. Il se peut que le débit varie légèrement à cause de la surcharge durant la migration.

La limitation basée sur l’intégrité des ressources Office 365 concerne les migrations qui utilisent des outils de migration tiers. Pour plus d’informations, consultez la section ci-dessus sur la limitation basée sur l’intégrité des ressources Office 365.

 
Afficher: