Meilleures pratiques et performances pour la migration d’Office 365

Il existe de nombreux chemins d’accès pour migrer les données d’une organisation de courrier locale vers Microsoft Office 365. Lorsque vous planifiez une migration vers Office 365, une question courante est comment améliorer les performances de la migration des données et optimiser la vitesse de migration.

Remarque : Les informations de performances décrites dans cette rubrique ne s’appliquent pas au service Office 365 pour les offres d’abonnement dédiées. Pour plus d’informations sur les offres dédiées, voir Descriptions des services d’offres de plans dédiés Office 365.

Contenu de cet article

Vue d’ensemble de la migration du courrier électronique vers Office 365

Office 365 prend en charge plusieurs méthodes pour migrer des courriers électroniques, des calendriers et des données de contact de votre environnement de courrier existant vers Office 365 comme décrit dans Méthodes de migration des comptes de courrier vers Office 365.

Pour plus d’informations sur la mise en réseau et les performances dans Office 365, voir Planification réseau et optimisation des performances pour Office 365.

Méthodes de migration fréquemment utilisées

Méthode de migration

Description

Ressources

Migration de IMAP (Internet Message Access Protocol)

Vous pouvez utiliser le Centre d’administration Exchange ou le Management Shell d’Exchange pour migrer le contenu des boîtes aux lettres des utilisateurs à partir d’un système de courrier IMAP vers leurs boîtes aux lettres Office 365. Cela inclut la migration de vos boîtes aux lettres à partir d’autres services de courrier hébergés, tels que Gmail ou Yahoo Mail.

Déplacer vos boîtes aux lettres IMAP vers Office 365

Migration à basculement

À l’aide d’une migration à basculement, vous migrez toutes les boîtes aux lettres locales vers Office 365 en quelques jours. Utilisez la migration à basculement si vous prévoyez de déplacer l’ensemble de votre organisation de courrier vers Office 365 et de gérer les comptes d’utilisateur dans Office 365. Vous pouvez migrer au maximum 2 000 boîtes aux lettres à partir de votre organisation Exchange vers Office 365 à l’aide d’une migration à basculement. En revanche, le nombre recommandé de boîtes aux lettres correspond à 150   . Une baisse des performances est observée avec un nombre supérieur à celui-ci. Les contacts de courrier et les groupes de distribution dans votre organisation Exchange locale sont également migrés.

Migration à basculement vers Office 365

Migration intermédiaire

Vous utilisez une migration intermédiaire si vous prévoyez de finir par migrer les boîtes aux lettres de l’ensemble de l’entreprise vers Office 365. À l’aide d’une migration intermédiaire, vous migrez des lots de boîtes aux lettres locales vers Office 365 sur une période de quelques semaines ou mois.

Ce que vous devez savoir sur une migration de courrier intermédiaire vers Office 365

Déploiement hybride

Un déploiement hybride permet aux organisations d’étendre l’expérience riche en fonctionnalités et le contrôle administratif dont ils disposent avec leur organisation Exchange locale existante dans le cloud. Un déploiement hybride offre l’aspect fluide d’une organisation Exchange unique entre un Exchange Server 2013 ou Microsoft Exchange Server 2010 sur site et Office 365. En outre, un déploiement hybride peut être une étape intermédiaire avant de migrer complètement vers une organisation Office 365.

Déploiements hybrides Exchange Server 2013

Migration tierce

De nombreux outils sont proposés par des tiers. Ils utilisent des protocoles et des approches identifiables pour effectuer les migrations de courrier à partir de plateformes de courrier telles qu’IBM Lotus Notes et Novell GroupWise.

Voici quelques outils de migration tiers et partenaires pouvant aider pendant les migrations d’Exchange à partir de plateformes de tiers :

  • Binary Tree : fournit des logiciels de coexistence et de migration de courrier multiplateforme offrant des fonctionnalités d’analyse, de coexistence et de migration entre les environnements de courrier et de collaboration d’entreprise en ligne et locaux basés sur IBM Lotus Notes et Domino, ainsi que Exchange et SharePoint.

  • BitTitan : fournisseur de solutions de migration vers Office 365.

  • Dell : fournisseur de logiciels de migration et de coexistence sur site et hébergés, y compris les analyse préalables à la migration et la coexistence intégrale entre utilisateurs et applications. Migrations complètes depuis Exchange local, IBM Domino, Novell GroupWise, Zimbra et d’autres environnements vers Office 365 et SharePoint Online.

  • Metalogix : fournisseur de solutions de migration vers Office 365 et SharePoint Online.

  • SkyKick : fournisseur de solutions de migration automatisées pour Exchange local, Gmail, POP3, IMAP, Lotus Notes vers Office 365. Les outils de migration de bout en bout fournissent une aide aux partenaires en ce qui concerne les ventes, la planification, la migration, la gestion et les phases sur site du projet de migration.

  • TransVault : fournisseur de solutions de migration vers Office 365.

Performances des méthodes de migration

Le tableau suivant compare les résultats observés en matière de performances pour les différentes méthodes de migration en ce qui concerne la migration des boîtes aux lettres et des données de boîte aux lettres sur Office 365. Ces résultats sont basés sur des tests internes et les migrations client réelles vers Office 365.

Important : Étant donné les différences en ce qui concerne le mode d’exécution des migrations et le moment où elles sont accomplies, votre vitesse de migration réelle peut être plus lente ou plus rapide.

Méthode de migration

Limitation des 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 (si applicable)

Migration de IMAP

Non

Oui

Oui

10-14 gigaoctets (Go) (20 accès concurrentiels)

Migration à basculement

Non

Oui

Oui

10-14 Go (20 accès concurrentiels)

Migration intermédiaire

Non

Oui

Oui

10-14 Go (20 accès concurrentiels)

Migration hybride

Non

Oui

Oui

10-14 Go par Exchange 2013 local ou 2010 CAS(service de réplication de boîte aux lettres Microsoft Exchange (service MRSProxy)) avec 20 déplacements concurrents 1

Migration MAPI tierce

Oui

Non

Oui

4-12 Go (20 accès concurrentiels) 2

Migration de services Web Exchange tiers

Non

Oui

Oui

5-10 Go (20 accès concurrentiels) 3

Téléchargement de client (à partir de fichiers .pst Outlook)

Oui

Non

Oui

0,5 Go

1 le débit de déplacement de boîtes aux lettres observé se trouve dans la plage 0,3-1,0 Go/heure. Un débit par boîte aux lettres supérieur à 1 000 Mo/h, peut être obtenu avec un réseau pouvant supporter un temps de blocage éphémère inférieur à 2 % et une latence de réseau inférieure à 100 ms. Des migrations de boîtes aux lettres plus concurrentes peuvent servir à atteindre des taux de migration des données plus élevés. Un débit de déplacement de boîte aux lettres unique ralentit quand le serveur CAS local (service MRSProxy) en local a atteint sa limite de capacité matérielle, si la bande passante réseau n’est pas suffisante ou si la latence du réseau est trop élevée. Envisagez d’ajouter des serveurs ou d’améliorer temporairement la connectivité du réseau pour augmenter la vitesse de migration.

2 Le débit de migration MAPI unique observé se trouve dans la plage 0,1-0,5 Go/heure. Un nombre supérieur de migrations simultanées permet d’atteindre des taux de migration des données plus élevés. Un débit de migration MAPI unique ralentit lorsque les serveurs sur site ou le réseau ont atteint leur capacité.

3 Le débit de migration des services Web Exchange unique observé se trouve dans la plage 0,2-0,5 Go/heure. Un nombre supérieur de migrations simultanées permet d’atteindre des taux de migration des données plus élevés. Par exemple, avec 20 migrations simultanées, le débit global sera dans la plage de 4 à 10 Go/heure. Un débit de migration des services Web Exchange unique ralentit lorsque les serveurs sur site ou le réseau ont atteint leur capacité.

Facteurs de performances de migration

La migration de courrier présente plusieurs facteurs communs pouvant affecter les performances de migration.

Facteurs courants pour les performances de la migration

Le tableau suivant fournit une liste de facteurs courants qui affectent les performances de la migration. Plus de détails sont fournis dans les sections décrivant les méthodes de migration individuelles.

Facteur

Description

Exemple

Source de données

Le périphérique ou le service qui héberge les données à migrer. Nombre de limitations peuvent s’appliquer à la source de données en raison de spécifications matérielles, de la charge de travail des utilisateurs finaux et des tâches de maintenance du serveur principal.

Gmail limite la quantité de données pouvant être extraites pendant une période spécifique.

Type de données et densité

En raison de la nature unique de l’entreprise d’un client, le type et la combinaison d’éléments de courrier au sein des boîtes aux lettres varient considérablement.

Une boîte aux lettres de 4 Go avec 400 éléments, chacun avec 10 mégaoctets (Mo) de pièces jointes, migrera plus vite qu’une boîte aux lettres de 4 Go avec 100 000 éléments plus petits.

Serveur de migration

De nombreuses solutions de migration utilisent un serveur de migration ou de poste de travail de type « boîte de renvoi » pour effectuer la migration.

Les clients utilisent souvent une machine virtuelle avec de faibles performances afin d’héberger le service MRSProxy pour des déploiements hybrides ou pour des migrations non hybrides de PC clients.

Moteur de migration

Le moteur de migration de données responsable de l’extraction des données à partir du serveur source convertit les données, si nécessaire. Ensuite, le moteur transmet les données sur le réseau et injecte les données dans la boîte aux lettres Office 365.

Le service MRSProxy possède ses propres fonctionnalités et limitations.

Équipements du réseau local

Les performances réseau de bout en bout, depuis la source de données jusqu’au serveurs d’accès client Exchange Online, affecte les performances de la migration.

Configuration du pare-feu et caractéristiques de l’organisation locale.

Service Office 365

Office 365 intègre la prise en charge et les fonctionnalités permettant de gérer la charge de travail de migration.

La stratégie de limitation des utilisateurs a des paramètres par défaut et limite la vitesse de transfert maximale totale des données.

Facteurs de performances réseau

Cette section décrit les meilleures pratiques permettant d’améliorer les performances du réseau lors de la migration. La discussion est d’ordre général, car l’impact le plus important sur les performances du réseau lors de la migration est lié au matériel tiers et aux fournisseurs de services Internet.

L’outil d’analyse réseau Office 365 est déployé pour vous aider à analyser les problèmes liés au réseau - avant de déployer les services Office 365. Chacune de ces instances est conçue pour tester une région particulière à l’aide de points de terminaison de test dans Office 365.

L’analyseur Exchange permet d’obtenir une meilleure compréhension de votre connectivité réseau avec Office 365. Pour exécuter les tests de l’analyseur Exchange dans Assistant Support et récupération, accédez à Diagnostics avancés > Exchange Online > Vérifier la connectivité réseau Exchange Online > Oui. Lire Résoudre les problèmes liés à Outlook et à Office 365 avec l’Assistant Support et récupération pour Office 365 pour en savoir plus sur l’Assistant Support et récupération.

Facteur

Description

Meilleures pratiques

Capacité réseau

La durée nécessaire pour migrer les boîtes aux lettres vers Office 365 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é maximale de téléchargement.

  • Contactez votre fournisseur de services Internet pour confirmer la bande passante allouée et pour obtenir des détails sur les restrictions, telles que le montant total des données qui peuvent être transférées au cours d’une période spécifique.

  • Utilisez les outils pour évaluer la capacité réelle de votre réseau. Vérifiez que vous testez le flux de données de bout en bout à partir de votre source de données locale vers les serveurs de passerelle du centre de données Microsoft.

  • Identifiez les autres charges de votre réseau (par exemple, les utilitaires de sauvegarde et la maintenance planifiée) qui peuvent affecter la capacité de votre réseau.

Stabilité du réseau

Un réseau rapide ne permet pas toujours d’effectuer des migrations rapides. Si le réseau n’est pas stable, le transfert de données est plus long en raison de la correction des erreurs. Selon le type de migration, la correction des erreurs peut considérablement affecter les performances de la migration.

Les problèmes liés au matériel réseau et aux pilotes entraînent souvent des problèmes de stabilité du réseau. Travaillez avec vos fournisseurs de matériel pour comprendre vos périphériques réseau et appliquer les pilotes les plus récents des fournisseurs et les mises à jour logicielles.

Retards de réseau

La fonctionnalité de détection des intrusions configurée sur un pare-feu réseau provoque souvent des retards importants sur le réseau et affecte les performances de la migration.

La migration des données vers les boîtes aux lettres Office 365 dépend de votre connexion Internet. Les retards sur Internet affectent les performances générales de migration.

En outre, les utilisateurs de la même société peuvent avoir des boîtes aux lettres dans le cloud se trouvant dans des centres de données à différents emplacements géographiques. Selon le fournisseur de services Internet du client, les performances de migration peut varier.

  • Évaluez les délais de réseau vers tous les centres de données Microsoft potentiels pour garantir la cohérence du résultat. (Cela permet également d’assurer une expérience cohérente pour les utilisateurs finaux.) Travaillez avec votre fournisseur de services Internet pour corriger les problèmes liés à Internet.

  • Ajoutez des adresses IP pour les serveurs de centre de données Microsoft à votre liste verte ou ignorez l’ensemble du trafic lié à la migration depuis votre pare-feu de réseau. Pour plus d’informations sur les plages d’adresses IP Office 365, voir URL et plages d’adresses IP Office 365.

Pour une analyse approfondie des migrations dans votre environnement, consultez notre billet de blog sur le déplacement des analyses. Le billet inclut un script pour vous aider à analyser les demandes de déplacement.

Limitation Office 365

Office 365 utilise divers mécanismes de limitation pour garantir la sécurité et la disponibilité du service. Les trois types suivants de limitation peuvent affecter les performances de la migration :

  • Limitation des utilisateurs

  • Limitation du service de migration

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

Remarque : Les trois types de limitation Office 365 n’affectent pas toutes les méthodes de migration.

Limitation des utilisateurs Office 365

La limitation des utilisateurs a une incidence sur la plupart des outils de migration tiers et la méthode de migration de téléchargement de client. Ces méthodes de migration utilisent des protocoles d’accès client, telles que le protocole RPC sur HTTP, pour migrer les données de boîte aux lettres vers des boîtes aux lettres Office 365. Ces outils sont utilisés pour migrer les données à partir de plateformes telles qu’IBM Lotus Domino et Novell GroupWise.

La limitation des utilisateurs est la méthode de limitation la plus restrictive dans Office 365. Étant donné que la limitation des utilisateurs est configurée pour opérer par rapport à un utilisateur individuel, toute utilisation de niveau application dépassera facilement la stratégie de limitation et entraînera une migration plus lente des données.

Limitation du service de migration Office 365

La limitation du service de migration affecte tous les outils de migration Office 365. La limitation du service de migration gère les accès concurrentiels de migration et l’affectation des ressources de service pour les solutions de migration Office 365.

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

  • Migration de IMAP

  • Migration à basculement Exchange

  • Migration intermédiaire Exchange

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

Un exemple de limitation du service de migration est le contrôle du nombre de boîtes aux lettres qui sont déplacées simultanément lors de migrations Exchange simples et de migrations IMAP. La valeur par défaut est 10. Cela signifie qu’au maximum 10 boîtes aux lettres de tous les lots de migration sont migrées à un moment donné. Vous pouvez augmenter le nombre de migrations simultanées pour un lot de migration dans le panneau de configuration Exchange ou Windows PowerShell. Pour plus d’informations sur l’optimisation de ce paramètre, voir Gérer les lots de migration dans Office 365.

Limitation basée sur l’intégrité des ressources Office 365

Toutes les méthodes de migration sont soumises à la gouvernance de la limitation de disponibilité. La limitation de service Office 365, toutefois, n’affecte pas les migrations Office 365 autant que les autres types de limitations décrits précédemment.

La limitation basée sur l’intégrité des ressources est la méthode de limitation la moins restrictive. Elle se produit uniquement en présence d’un problème de disponibilité du service qui affecte les utilisateurs finaux et les opérations de service critiques.

Si un incident de service se produit au cours d’une migration hybride, par exemple, et que le service se détériore au point où les performances de l’utilisateur final sont également détériorées. La migration hybride sera mise en attente jusqu’à ce que les performances soient récupérées et le service renvoie à un niveau inférieur au seuil de limitation.

Voici un exemple de rapport statistique de migration Exchange. Il affiche une entrée créée lorsque le seuil de limitation de service est dépassé.

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

  • 25/01/2012 12:57:53 [BL2PRD0410CA012] Le déplacement de la boîte aux lettres '/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' est bloqué, car les conditions du paramètre DataMoveReplicationConstraint ne sont pas satisfaites pour la base de données 'NAMPRD04DG031-db081' (agent MailboxDatabaseReplication). Motif de l’erreur : La base de données edbf0766-1f2a-4552-9115-bb3a53a8380b ne respecte pas la contrainte SecondDatacenter. Aucune copie de base de données saine n’est disponible. Attendra jusqu’au 25/1/2012 1:27:53.

  • 25/1/2012 12:58:24 AM [BL2PRD0410CA012] La requête n’est plus bloquée et son exécution va se poursuivre.

Solution et exercice pratique   

Si vous rencontrez une situation similaire, attendez que le service Office 365 récupère. Pour plus d’informations, voir la section État d’intégrité des services sur le portail Office 365.

Facteurs de performances et meilleures pratiques pour les migrations de déploiement non hybrides

Cette section décrit les facteurs qui affectent les migrations à l’aide des méthodes de migration IMAP, à basculement ou intermédiaire. Elle identifie également les meilleures pratiques permettant d’améliorer les performances de la migration.

Facteur 1 : Source de données

Le tableau suivant décrit l’impact sur la migration par les serveurs sources dans votre organisation de courrier actuelle et les meilleures pratiques permettant d’atténuer l’impact sur la migration.

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, tels que le temps processeur et la mémoire, pour fournir des performances de migration optimales. Pendant la migration, le système source est souvent proche de sa capacité maximale en ce qui concerne la charge de travail normale des utilisateurs finaux. Si les ressources système sont insuffisantes, la charge de travail supplémentaire résultant de la migration peut affecter les utilisateurs finaux.

Surveillez les performances du système lors d’un test de migration pilote. Si le système est occupé, nous vous recommandons d’éviter une planification de migration restrictive pour le système spécifique en raison de la lenteur potentielle de la migration et des problèmes de disponibilité de service. Si possible, améliorez les performances du système source en ajoutant des ressources matérielles, et réduisez la charge sur le système en déplaçant les tâches et les utilisateurs vers d’autres serveurs qui ne sont pas impliqués dans la migration.

Pour plus d’informations, voir :

Lors de la migration à partir d’une organisation Exchange locale lorsqu’il y a plusieurs serveurs de boîte aux lettres, nous vous recommandons de créer une liste des utilisateurs de la migration qui soit répartie de façon uniforme entre plusieurs serveurs de boîte aux lettres. Sur la base des performances individuelles du serveur, la liste peut être davantage affinée pour optimiser le débit.

Par exemple, si un serveur A présente une disponibilité des ressources supérieure de 50 % par rapport au serveur B, il est judicieux d’avoir plus 50 % d’utilisateurs en plus provenant du serveur A 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é maximale des ressources comme après les heures de travail ou pendant les week-ends et les jours fériés.

Tâches principales

Autres tâches principales en cours d’exécution au moment de la migration. Car il est recommandé d’effectuer les migrations après les heures de travail, il est fréquent que celles-ci entrent en conflit avec les tâches de maintenance, telles que la sauvegarde de données, en cours d’exécution sur vos serveurs locaux.

Passez en revue les autres tâches système qui peuvent être en cours d’exécution pendant la migration. Nous vous conseillons d’effectuer la migration des données lorsque aucune autre tâche gourmande en ressources n’est en cours d’exécution.

Remarque    : pour les clients utilisant Exchange en local, les tâches principales courantes sont les solutions de sauvegarde et la maintenance de la banque d’informations Exchange.

Stratégie de limitation

Il est fréquent de protéger les systèmes de courrier avec une stratégie de limitation qui définit une limite spécifique sur la vitesse et la quantité de données pouvant être extraites du système pendant un certain temps.

Vérifiez quelle stratégie d’accélération est déployée pour votre système de courrier. Par exemple, Google Mail limite la quantité de données pouvant être extraite lors d’une période donnée.

Selon la version, Exchange dispose de stratégies qui limitent l’accès de IMAP au serveur de courrier local (utilisé par les migrations IMAP) et au protocole 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 l’applet de commande Get-ThrottlingPolicy. Pour plus d’informations, voir Gestion de la charge de travail Exchange.

Pour plus d’informations sur la limitation IMAP, voir Déplacer vos boîtes aux lettres IMAP vers Office 365

Pour plus d’informations sur la limitation du protocole RPC sur HTTP, voir :

Facteur 2 : Serveur de migration

Les migrations IMAP, à basculement et intermédiaires sont des méthodes de migration à extraction des données initiées par le cloud, il n’est donc pas nécessaire d’avoir un serveur de migration dédié. Toutefois, les hôtes de protocole Internet (IMAP ou le protocole RPC sur HTTP) fonctionnent en tant que serveur de migration pour la migration des boîtes aux lettres et des données de boîte aux lettres vers Office 365. Par conséquent, les facteurs de performances de migration et les meilleures pratiques décrites dans la section précédente relative au serveur de source de données pour votre organisation de courrier actuelle, s’appliquent également aux serveurs Edge Internet. Pour les organisations Exchange 2007, Exchange 2010 et Exchange 2013, le serveur d’accès client fonctionne en tant que serveur de migration.

Pour plus d’informations, voir :

Facteur 3 : Moteur de migration

Les migrations IMAP, à basculement et intermédiaire Exchange sont effectuées à l’aide du tableau de bord de migration dans le Centre d’administration Exchange . Soumis à la limitation du service de migration Office 365.

Solution et exercice pratique   

Les clients peuvent désormais indiquer les accès concurrentiels de migration (par exemple, le nombre de boîtes aux lettres devant être déplacées simultanément) à l’aide de Windows PowerShell. La valeur par défaut est de 20 boîtes aux lettres. Après avoir créé un lot de migration, vous pouvez utiliser l’applet de commande Windows PowerShell suivante pour arriver au maximum de 100.

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

Pour plus d’informations, voir Gérer les lots de migration dans Office 365.

Remarque : Si votre source de données ne dispose pas des ressources suffisantes pour gérer toutes les connexions, nous vous recommandons d’éviter un taux élevé d’accès concurrentiels. Commencez par une petite valeur d’accès concurrentiels, par exemple, 10. Augmentez ce nombre tout en analysant les performances des source de données afin d’éviter les problèmes d’accès des utilisateurs finaux.

Facteur 4 : Réseau

Tests de vérification   

Selon la méthode de migration, vous pouvez essayer les tests de vérification suivants :

  • Migrations IMAP    : préremplissez une boîte aux lettres source avec des exemples de données. Ensuite, à partir d’Internet (à l’extérieur de votre réseau local), connectez-vous à la boîte aux lettres source à l’aide d’un client de courrier IMAP standard tel que Microsoft Outlook, puis mesurez les performances réseau en déterminant le temps nécessaire pour télécharger toutes les données à partir de la boîte aux lettres source. Le débit doit être similaire à celui que les clients peuvent obtenir en utilisant l’outil de migration IMAP dans Office 365, étant donné qu’il n’existe pas d’autres contraintes.

  • Migrations à basculement et intermédiaire Exchange    : préremplissez une boîte aux lettres source avec des exemples de données. Ensuite, à partir d’Internet (en dehors de votre réseau local), connectez-vous à la boîte aux lettres source avec Outlook par le biais du protocole RPC sur HTTP. Vérifiez que vous vous connectez à l’aide du mode cache. Mesurez les performances réseau en vérifiant le temps nécessaire pour synchroniser toutes les données de la boîte aux lettres source. Le débit doit être similaire à celui que les clients peuvent obtenir en utilisant les outils de migration simples Exchange dans Office 365, étant donné qu’il n’existe pas d’autres contraintes.

Remarque : Il y a une surcharge pendant une migration IMAP réelle, à basculement ou intermédiaire d’Exchange. Le débit réel, toutefois, doit être similaire aux résultats de ces tests de vérification.

Facteur 5 : service Office 365

La limitation basée sur l’intégrité des ressources Office 365 affecte les migrations au moyen des outils de migration simples Office 365 natives. Voir la section Limitation basée sur l’intégrité des ressources Office 365.

Déplacer des requêtes dans le service Office 365

Pour des informations générales sur l’obtention d’informations sur l’état des demandes de déplacement, voir Afficher les propriétés des demandes de déplacement.

Dans le service Office 365, à la différence de Exchange 2010 local, la file d’attente de migration et les ressources de service allouées pour les migrations sont partagées entre les clients. Ce partage affecte la façon dont les demandes sont gérées à chaque étape du processus de déplacement.

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

  • Demandes de déplacements d’intégration    : les nouvelles migrations clientes sont considérées comme étant des demandes de déplacement d’intégration. Ces demandes ont une priorité normale.

  • Demandes de déplacement internes du centre de données    : il s’agit de demandes de déplacement de boîtes aux lettres initiées par les équipes de production du centre de données. Ces demandes ont une priorité inférieure car l’expérience utilisateur final n’est pas affectée si la demande de déplacement est retardée.

Impact potentiel et retards de déplacement des requêtes avec l’état « En attente » et « En cours »

  • Demandes de déplacement en file d’attente    : ce statut indique que le déplacement a été mis en attente et attend d’être choisi par le Service de réplication de boîte aux lettres Exchange. Pour les demandes de déplacement Exchange 2003, les utilisateurs peuvent toujours accéder à leur boîte aux lettres à ce stade.

    Deux facteurs influencent la demande qui sera choisie par le Service de réplication de boîte aux lettres :

    • Priorité    : les demandes de déplacement en file d’attente avec une priorité plus élevée sont choisies avant les demandes de déplacement à priorité inférieure. Cela permet de s’assurer que les demandes de déplacement de migrations clientes soient toujours traitées avant les demandes de déplacement internes du centre de données.

    • Position dans la file d’attente    : si les demandes de déplacement ont la même priorité, plus la demande arrive tôt dans la file d’attente, plus vite elle sera choisie par le Service de réplication de boîte aux lettres. Dans la mesure où plusieurs clients peuvent exécuter des migrations de boîtes aux lettres en même temps, il est normal que les nouvelles demandes de déplacement soient conservés dans la file d’attente avant d’être traitées.

      Souvent, la durée pendant laquelle les demandes restent dans la file d’attente avant d’être traitées n’est pas prise en compte lors de la planification de la migration. Il en résulte que les clients ne se voient pas attribuer suffisamment de temps pour effectuer toutes les migrations planifiées.

  • Demandes de déplacement en cours    : ce statut spécifie que le déplacement est toujours en cours. S’il s’agit d’un déplacement de boîtes aux lettres en ligne, l’utilisateur pourra toujours accéder à sa boîte aux lettres. Pour les déplacements de boîtes aux lettres en mode hors connexion, la boîte aux lettres de l’utilisateur ne sera pas disponible.

    Une fois que la demande de déplacement de boîtes aux lettres a le statut « En cours », la priorité n’a plus d’importance et aucune nouvelle demande de déplacement ne sera traitée jusqu’à ce qu’une demande de déplacement « en cours » existante soit effectuée, même si la nouvelle demande de déplacement a une priorité plus élevée.

Meilleures pratiques

Planification    : comme indiqué précédemment, parce que les utilisateurs Exchange 2003 perdent leur accès pendant une migration hybride, les clients Exchange 2003 se soucient généralement plus de connaître le calendrier des migrations et leur durée d’exécution.

Lors de la planification du nombre de boîtes aux lettres à migrer pendant une période donnée, envisagez ce qui suit :

  • Incluez la durée pendant laquelle la demande de déplacement attend dans la file d’attente. Pour calculer ce nombre, tapez ceci :

    (nombre total de boîtes aux lettres à migrer) = ((durée totale) – (temps d’attente moyen dans la file)) * (débit de migration)

    où le débit de migration est égal au nombre total de boîtes aux lettres qui peuvent être migrées par heure.

    Par exemple, supposons que vous disposiez d’une fenêtre de six heures pour migrer des boîtes aux lettres. Si le temps d’attente moyen dans la file est d’une heure et que vous avez un débit de migration de 100 boîtes aux lettres par heure, vous pouvez migrer 500 boîtes aux lettres en six heures : 500 = (6 – 1) * 100.

  • Commencez la migration plus vite que prévu initialement pour réduire le temps dans la file d’attente. Lorsque les boîtes aux lettres sont en file attente, les utilisateurs Exchange 2003 peuvent continuer d’accéder à leur boîte aux lettres.

Déterminer le temps d’attente    : le temps d’attente change constamment, parce que Microsoft ne gère pas les calendriers de migration des clients.

Pour déterminer le temps d’attente potentiel, un client peut tenter de planifier un déplacement test plusieurs heures avant le début effectif de la migration. Ensuite, en fonction de la durée observée pendant laquelle la demande est dans la file d’attente, le client peut mieux estimer le moment où commencer la migration et le nombre de boîtes aux lettres qui peuvent être déplacées dans un laps de temps spécifique.

Par exemple, si une migration test a été achevée quatre heures avant le début d’une migration planifiée. Le client détermine que le temps d’attente pour la migration test a été environ d’une heure. Ensuite, le client doit envisager de commencer la migration une heure avant le moment prévu initialement afin qu’il y ait suffisamment de temps pour effectuer toutes les migrations.

Outils tiers pour les migrations Office 365

Les outils tiers s’utilisent principalement 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 des outils de migration tiers, plutôt que sur les produits et les outils de migration réels. Le tableau suivant fournit une liste des facteurs qui s’appliquent à des outils tiers pour les scénarios de migration Office 365.

Facteur 1 : Source de données

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, tels que le temps processeur et la mémoire, pour fournir des performances de migration optimales. Pendant la migration, le système source est souvent proche de sa capacité maximale en ce qui concerne la charge de travail normale des utilisateurs finaux. Si les ressources système sont insuffisantes, la charge de travail supplémentaire résultant de la migration peut affecter les utilisateurs finaux.

Surveillez les performances du système lors d’un test de migration pilote. Si le système est occupé, nous vous recommandons d’éviter une planification de migration restrictive pour le système spécifique en raison de la lenteur potentielle de la migration et des problèmes de disponibilité de service. Si 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. Le chargement du système peut être réduit en déplaçant des tâches et des utilisateurs vers d’autres serveurs qui ne font pas partie de la migration.

Pour plus d’informations, voir :

Lors de la migration à partir d’une organisation Exchange locale lorsqu’il y a plusieurs serveurs de boîte aux lettres, nous vous recommandons de créer une liste des utilisateurs de la migration qui soit répartie de façon uniforme entre plusieurs serveurs de boîte aux lettres. Sur la base des performances individuelles du serveur, la liste peut être davantage affinée pour optimiser le débit.

Par exemple, si un serveur A présente une disponibilité des ressources supérieure de 50 % par rapport au serveur B, il est judicieux d’avoir plus 50 % d’utilisateurs en plus provenant du serveur A dans le même lot de migration. Une pratique similaire peut être appliquée à d’autres systèmes sources.

Effectuez les migrations lorsque le système offre une disponibilité maximale des ressources comme après les heures de travail ou pendant les week-ends et les jours fériés.

Tâches principales

Autres tâches principales généralement exécutées au moment de la migration. Car il est recommandé d’effectuer les migrations après les heures de travail, il est fréquent que celles-ci entrent en conflit avec les tâches de maintenance en cours d’exécution sur vos serveurs locaux, telles que la sauvegarde de données.

Passez en revue les autres tâches système en cours d’exécution pendant la migration. Nous vous conseillons de créer une fenêtre de temps réservée à la migration des données, dans laquelle il n’y a aucune autre tâche sollicitant les ressources de façon intensive.

Pour les clients locaux Exchange, les tâches courantes sont les solutions de sauvegarde. Pour plus d’informations, voir Maintenance de la banque d’informations Exchange.

Stratégie de limitation

Il est fréquent de protéger les systèmes de courrier avec une stratégie de limitation qui définit une limite spécifique sur la vitesse et la quantité de données pouvant être extraites du système dans un laps de temps spécifique et au moyen d’une méthode de migration spécifique.

Vérifiez quelle stratégie d’accélération est déployée pour votre système de courrier. Par exemple, Google Mail limite la quantité de données pouvant être extraite lors d’une période donnée.

Selon la version, Exchange dispose de stratégies qui limitent l’accès de IMAP au serveur de courrier local (utilisé par les migrations IMAP) et au protocole RPC sur HTTP (utilisé par les migrations Exchange à basculement et les migrations Exchange intermédiaires).

Pour plus d’informations sur la limitation IMAP, voir Conseils pour l’optimisation de migrations IMAP.

Pour plus d’informations sur la limitation du protocole RPC sur HTTP, voir :

Pour plus d’informations sur la configuration de la limitation des services Web Exchange, voir Exchange 2010 : Présentation des stratégies de limitation du client.

Facteur 2 : Serveur de migration

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

Remarque : Certaines solutions de migration tierces sont hébergées sur Internet comme les services cloud et ne nécessitent pas un serveur de migration en local.

Solution et exercice pratique   

Pour améliorer les performances de migration lorsque vous utilisez un serveur de migration, appliquez les mêmes recommandations que celles décrites dans la section Facteur 1 : source de données.

Facteur 3 : Moteur de migration

Pour les outils de migration tiers, les protocoles les plus fréquemment utilisés sont les services Web Exchange et le protocole RPC sur HTTP.

ExchangeServices web   

ExchangeLes Services Web sont le protocole recommandé pour migrer vers Office 365 , car il prend en charge des lots de données volumineuses et dispose d’une meilleure limitation orientée services. Dans Office 365, lorsqu’elles sont utilisés en mode d’emprunt d’identité, les migrations faisant appel aux Services Web Exchange n’utilisent pas le montant budgété de l’utilisateur des ressources des Services Web Office 365Exchange, mais utilisent à la place une copie des ressources budgétées :

  • Tous les appels d’emprunt d’identité des Services Web Exchange effectués par le même compte d’administrateur sont calculés séparément du budget appliqué à ce compte d’administrateur.

  • 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 particulière utiliseront ce cliché instantané

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

Pratiques recommandées   

  • Les performances de migration pour les clients utilisant des outils de migration tiers faisant appel à l’emprunt d’identité EWA entrent en concurrence avec les migrations basée sur les Services Web Exchange et l’utilisation des ressources de service par les autres clients. Par conséquent, les performances de migration peuvent varier.

  • Dès que possible, les clients doivent utiliser des outils de migration tiers qui utilisent l’emprunt d’identité des Services Web Exchange, car c’est généralement plus rapide et plus efficace que d’utiliser des protocoles client tels que le protocole RPC sur HTTP.

Protocole 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 client tels que celui de Outlook, et l’évolutivité et les performances sont limitées parce que le service Office 365 limite les accès en fonction de l’hypothèse selon laquelle l’utilisation est faite par un utilisateur plutôt que par une application.

Pratiques recommandées   

  • 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 utilisant plusieurs comptes d’utilisateur d’administration Office 365. Cette pratique permet d’obtenir l’injection de données en parallèle et d’atteindre un débit des données plus élevé parce que chaque utilisateur administratif est soumis à la limitation des utilisateurs Office 365. Nous avons reçu des rapports indiquant que de nombreuses entreprises devaient configurer plus de 40 serveurs de migration pour obtenir un débit de migration de 20 à 30 Go/heure.

  • Lors d’une phase de développement d’outils de migration, il est essentiel de prendre en compte le nombre d’opérations RPC requises pour migrer un message. Pour illustrer cela, nous avons rassemblé 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 les 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, et nous les avons également comparées au téléchargement d’un fichier .pst dans Outlook. Voici les résultats.

    Méthode

    Taille de la boîte aux lettres

    Nombre d’éléments

    Heure de la migration

    Nombre total de transactions RPC

    Latence moyenne du client (ms)

    DuréeTraitementRPCCASMoy (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,9 Mo

    3 297

    0:29:47

    15 775

    36,9987

    5,6447

    Notez que les durées des processus du client et du service sont similaires mais la solution A nécessite beaucoup plus d’opérations RPC pour migrer les données. Étant donné que chaque opération consomme du temps de latence sur le client et du temps de traitement sur le serveur, la solution A est beaucoup plus lente pour la migration de la même quantité de données en comparaison avec la Solution B et Outlook.

Facteur 4 : Réseau

Meilleure pratique   

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

  1. À partir du serveur de migration, connectez-vous à la boîte aux lettres Office 365 avec Outlook au moyen du protocole RPC sur HTTP. Vérifiez que vous ne vous connectez pas en utilisant le mode cache.

  2. Importez un fichier .pst de grande taille avec des exemples de données dans la boîte aux lettres Office 365.

  3. Mesurez les performances de migration en déterminant le temps nécessaire pour télécharger le fichier .pst. Le débit de migration doit être similaire à ce que les clients peuvent obtenir d’un outil de migration tiers qui utilise le protocole RPC sur HTTP, en l’absence d’autres contraintes. Étant donné qu’une surcharge se produit lors d’une migration réelle, le débit peut être légèrement différent.

Facteur 5 : service Office 365

La limitation basée sur l’intégrité des ressources Office 365 affecte les migrations effectuées au moyen d’outils de migration tiers. Voir Limitation basée sur l’intégrité des ressources Office 365 pour plus d’informations.

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoignez le programme Office Insider

Ces informations vous ont-elles été utiles ?

Nous vous remercions pour vos commentaires.

Merci pour vos commentaires. Il serait vraisemblablement utile pour vous de contacter l’un de nos agents du support Office.

×