Plan de résolution des problèmes de performances pour Office 365

Important :  Cet article a été traduit automatiquement, voir l’avertissement. Vous pouvez consulter la version en anglais de cet article ici.

Vous devez connaître les étapes à suivre pour identifier et résoudre les retards, se bloque et baisse des performances entre SharePoint Online, OneDrive entreprise, Exchange Online ou Skype entreprise Online et votre ordinateur client ? Avant de contacter le support, cet article peut vous aider à résoudre les problèmes de performances d’Office 365 et même résoudre certains des problèmes courants.

Il constitue un exemple de plan d’action que vous pouvez utiliser pour capturer des données utiles sur le problème de performance que vous rencontrez. Certains problèmes courants sont également mentionnés ici.

Si vous n’êtes pas familiarisé avec les problèmes de performance réseau et cherchez à établir un plan à long terme pour surveiller les performances entre vos ordinateurs client et Office 365, consultez la rubrique Optimisation des performances et résolution des problèmes d’Office 365 - Administrateur et professionnel de l’informatique.

Exemple de plan d’action de résolution des problèmes de performance

Ce plan d’action se déroule en deux parties : une phase de préparation et une phase de journalisation. Si vous rencontrez actuellement un problème de performance et que vous devez recueillir des données, vous pouvez utiliser ce plan immédiatement.

Préparation de l’ordinateur client

  • Recherchez un ordinateur client capable de reproduire le problème de performance. Cet ordinateur sera utilisé au cours du processus de dépannage.

  • Notez les étapes qui occasionnent le problème de manière à être prêt au moment d’effectuer le test.

  • Installez les outils permettant de recueillir et d’enregistrer les informations :

    • Installez Netmon 3.4 (ou utilisez un outil de suivi réseau possédant les mêmes fonctionnalités).

    • Installez l’édition Basic de HTTPWatch (ou utilisez un outil de suivi réseau possédant les mêmes fonctionnalités).

    • Utilisez un enregistreur à l’écran ou exécutez l’utilitaire Enregistreur d’actions (PSR.exe) fourni avec Windows Vista et version ultérieure afin de garder une trace des étapes suivies lors de la phase de test.

Journalisation du problème de performance

  • Fermez tous les navigateurs Internet superflus.

  • Démarrez l’utilitaire Enregistreur d’actions ou un autre enregistreur à l’écran.

  • Démarrez la capture avec Netmon (ou un autre outil de suivi réseau).

  • Effacez le cache DNS sur l’ordinateur client à partir de la ligne de commande en tapant ipconfig /flushdns.

  • Démarrez une nouvelle session de navigateur et activez HTTPWatch.

  • Facultatif : si vous testez Exchange Online, exécutez l’outil Analyseur de performances du client Exchange (ECPA) à partir de la console Administrateur Office 365.

  • Reproduisez les étapes exactes qui occasionnent le problème de performance.

  • Arrêtez le suivi de Netmon ou d’un autre outil.

  • Dans la ligne de commande, exécutez un itinéraire de suivi vers votre abonnement Office 365. Pour ce faire, tapez la commande suivante, puis appuyez sur Entrée :

    tracert <nom_abonnement>.onmicrosoft.com

  • Arrêtez l’Enregistreur d’actions et enregistrez la vidéo. N’oubliez pas d’inclure la date et l’heure de la capture et indiquez si les performances sont médiocres ou acceptables.

  • Enregistrez les fichiers de trace. De nouveau, n’oubliez pas d’inclure la date et l’heure de la capture et d’indiquer si les performances sont médiocres ou acceptables.

Ne vous inquiétez pas si vous n’êtes pas familiarisé à l’exécution des outils mentionnés dans cet article, car nous vous décrivons les étapes suivantes. En revanche, si vous avez l’habitude d’effectuer des captures réseau, vous pouvez passer directement à la section Comment lire vos traces qui explique comment filtrer et lire les journaux.

Effacer tout d’abord le cache DNS

Pourquoi ? En effaçant le cache DNS, vous démarrez vos tests de zéro. De plus, vous rétablissez les entrées les plus à jour dans le contenu de résolution DNS. N’oubliez pas que le fait d’effacer le cache ne supprime pas les entrées de fichiers HOST. Si vous utilisez les entrées de fichiers HOST de manière intensive, nous vous conseillons de copier ces entrées dans un fichier stocké dans un autre répertoire, puis de vider le fichier HOST.

Vider le cache DNS

  1. Ouvrez l’invite de commandes (cliquez sur Démarrer > Exécuter > cmd ou Touche Windows > cmd).

  2. Tapez la commande suivante, puis appuyez sur Entrée :

    ipconfig /flushdns

Netmon

Outil d’analyse de réseau de Microsoft (Netmon) analyse les paquets, qui se trouve le trafic, qui passe entre des ordinateurs sur les réseaux. À l’aide de Netmon pour repérer le trafic avec Office 365 vous pouvez capturer, affichage et lire les en-têtes de paquets, identifiez les périphériques intermédiaires, vérifiez les paramètres importants de matériel réseau, recherchez la perte de paquets, puis suivez l’acheminement du trafic entre des ordinateurs sur votre réseau d’entreprise et Office 365. Étant donné que le corps du trafic réel est chiffré, c'est-à-dire qu’il (voyages sur le port 443 via le protocole SSL/TLS, vous ne pouvez pas lire les fichiers envoyés. À la place, vous obtenez une trace filtrée le chemin d’accès qui prend la paquet qui peut vous aider à analyser le problème.

Veillez à ne pas appliquer de filtre à ce stade. Répétez plutôt les étapes et décrivez le problème avant d’arrêter le suivi et de procéder à l’enregistrement.

Après avoir installé Netmon 3.4, ouvrez l’outil et suivez ces étapes :

Une trace Netmon et reproduire le problème

  1. Lancez Netmon 3.4.

    Il existe trois volets sur la page de démarrage: Capture récents, Sélectionnez les réseaux et la mise en route avec Microsoft réseau moniteur 3.4 . Notification de. Le panneau de sélectionner des réseaux vous donne également une liste des réseaux par défaut à partir duquel vous pouvez capturer. N’oubliez pas que les cartes réseau sont sélectionnées ici.

  2. Cliquez sur New Capture au-dessus de Start Page. Cela a pour effet d’ajouter le nouvel onglet Capture 1 à côté de l’onglet Start Page.

    Interface utilisateur de Netmon avec les boutons New Capture, Start et Stop sélectionnés

  3. Pour simplement prendre une capture, cliquez sur Start dans la barre d’outils.

  4. Reproduisez les étapes qui occasionnent un problème de performance.

  5. Cliquez sur Stop > File > Save As. N’oubliez pas d’inclure la date, l’heure et le fuseau horaire dans le titre en indiquant également si les performances enregistrées sont médiocres ou acceptables.

HTTPWatch

HTTPWatch est fourni facturés et une édition gratuite. L’édition de base gratuite couvre tout ce dont vous avez besoin pour ce test. HTTPWatch moniteurs du temps de chargement de page et le trafic réseau directement à partir de la fenêtre du navigateur. HTTPWatch est un plug-in Internet Explorer décrivant graphiquement des performances. L’analyse peut être enregistré et consulté dans HTTPWatch Studio.

Remarques : 

  • Si vous utilisez un autre navigateur (Firefox, Google Chrome, etc.) ou si vous ne parvenez pas à installer HTTPWatch dans Internet Explorer, ouvrez une nouvelle fenêtre de navigateur et appuyez sur la touche F12 de votre clavier. La fenêtre contextuelle Outils de développement s’affiche en bas de votre navigateur. Si vous utilisez Opera, appuyez sur Ctrl+Maj+I pour ouvrir l’inspecteur web, puis cliquez sur l’onglet Réseau et effectuez le test décrit ci-dessous. Les informations seront légèrement différentes, mais les temps de chargement seront toujours affichés en millisecondes.

  • L’utilisation de HTTPWatch est aussi très utile pour déterminer les temps de chargement des pages SharePoint Online.

Exécuter HTTPWatch et reproduire le problème

  1. HTTPWatch est un plug-in de navigateur. Les étapes permettant d’afficher l’outil dans le navigateur diffèrent légèrement selon la version d’Internet Explorer. En règle générale, HTTPWatch se trouve sous la barre de commandes dans le navigateur Internet Explorer.

    Si le plug-in HTTPWatch ne figure pas dans votre fenêtre de navigateur, vérifiez la version de votre navigateur en cliquant sur Aide > À propos, ou, dans les dernières versions d’Internet Explorer, en cliquant sur le symbole d’engrenage, puis sur À propos de Internet Explorer. Pour afficher la barre de commandes, cliquez avec le bouton droit sur la barre de menus dans Internet Explorer, puis cliquez sur Barre de commandes. Auparavant, HTTPWatch était associé à la barre de commandes et au volet d’exploration. Par conséquent, si vous ne voyez pas immédiatement l’icône après avoir effectué l’installation (même après un redémarrage), recherchez l’icône dans Outils et vos barres d’outils. N’oubliez pas que les barres d’outils peuvent être personnalisées de manière à accueillir de nouvelles options.

    Barre d’outils de commandes d’Internet Explorer avec l’icône HTTPWatch affichée

  2. Lancez l’outil HTTPWatch dans une fenêtre de navigateur Internet Explorer. Il apparaîtra ancré au navigateur en bas de cette fenêtre. Cliquez sur Record.

  3. Reproduisez les étapes exactes occasionnant le problème de performance. Cliquez sur le bouton Stop dans HTTPWatch.

  4. Enregistrez la capture HTTPWatch ou envoyez-la par courrier électronique. N’oubliez pas d’attribuer un nom au fichier qui inclut les informations de date et d’heure ainsi qu’une indication sur la qualité des performances enregistrées par votre Watch.

    HTTPWatch montrant l’onglet Réseau pour un chargement de la page d’accueil Office 365

    Cette capture d’écran est issue de la version Professional de HTTPWatch. Vous pouvez ouvrir des traces capturées dans la version Basic sur un ordinateur qui exécute la version Professional et les lire avec cette dernière. Des informations supplémentaires peuvent être disponibles à partir de la trace en utilisant cette méthode.

Enregistreur d’actions utilisateur

L’enregistreur d’actions (PSR.exe) vous permet d’enregistrer les problèmes lorsqu’ils se produisent. Cet outil est très utile et simple à exécuter.

Exécuter l’enregistreur d’actions (PSR.exe) pour enregistrer votre travail

  1. Cliquez sur Démarrer > Exécuter > tapez PSR.exe > OK, ou cliquez sur la touche Windows > tapez PSR.exe, puis appuyez sur Entrée.

  2. Lorsque la petite fenêtre PSR.exe s’affiche, cliquez sur Start Record et effectuez les étapes qui permettent de reproduire le problème de performance.

    Vous pouvez ajouter des commentaires au besoin, en cliquant sur Ajouter un commentaire.

  3. Cliquez sur Arrêter un enregistrement lorsque vous avez terminé les étapes. Si le problème de performance est un rendu de page, attendez que la page à rendre avant d’arrêter l’enregistrement.

  4. Cliquez sur Enregistrer.

Capture d’écran de l’Enregistreur d’actions (PSR.exe)

Pour vous, la date et l’heure est enregistrée. Votre qui à votre trace Netmon et HTTPWatch dans le temps et sélectionnez aide à la résolution des problèmes de précision. La date et l’heure de l’enregistrement qui peuvent afficher qu’une minute passé entre la connexion et la navigation de l’URL et le rendu partiel du site d’administration, par exemple.

Lire vos traces

Il n’est pas possible de décrire toutes les connaissances utiles sur le dépannage des problèmes réseau et de performance dans un article. L’optimisation des performances demande de l’expérience et une connaissance approfondie du fonctionnement et des performances habituelles de votre réseau. Il reste toutefois possible de dresser la liste des principaux problèmes rencontrés et de montrer la façon dont les outils vous permettent de supprimer les problèmes courants.

Si vous voulez choisir les compétences de lecture des traces réseau de vos sites Office 365, il n’existe aucune enseignant mieux que la création régulièrement les traces de chargement des pages et acquérir de l’expérience de les lire. Par exemple, lorsque vous avez la possibilité, charger un service Office 365 et suivre le processus. Filtrer la trace pour le trafic DNS, ou recherchez le FrameData pour le nom du service recherché. Passez en revue la trace pour avoir une idée des étapes qui se produisent lors du chargement du service. Cela vous aidera à découvrir quels normal chargement de la page doit ressembler à, et dans le cas de résolution des problèmes, particulièrement autour de performances, comparaison traces satisfaisant à insuffisant vous peut d’apprendre un grand nombre.

Netmon utilise Microsoft Intellisense dans le champ de filtre d’affichage. IntelliSense ou saisie semi-automatique du code intelligent, est cette astuce dans lequel vous tapez dans une période et toutes les options disponibles sont affichées dans une zone de sélection de menu déroulant. Si, par exemple, vous avez peur à propos de fenêtre TCP mise à l’échelle, vous pouvez naviguer à un filtre (par exemple, .protocol.tcp.window < 100) par celle-ci signifie que.

Capture d’écran de Netmon montrant que le champ Display Filter utilise IntelliSense

Trace Netmon peut avoir un grand nombre de trafic qu’ils. Si vous n’êtes pas expérimenté en matière de les lire, il est probable que vous serez dépassé ouvrant la trace la première fois. La première chose à faire est séparer le signal le bruit de fond dans la trace. Vous avez testé par rapport à Office 365, et qui est le trafic que vous voulez afficher. Si vous permettent de parcourir les traces, vous devrez pas cette liste.

Le trafic entre votre client et Office 365 est transmise via TLS. En d’autres termes, le corps du trafic est chiffré et ne peut être lu dans une trace Netmon générique. Dans le cadre de l’analyse des performances, vous n’avez pas besoin de connaître les caractéristiques des informations incluses dans le paquet. Vous êtes toutefois intéressé par les en-têtes des paquets et les informations qu’ils contiennent.

Conseils pour obtenir une trace exploitable

  • Prenez connaissance de la valeur de l’adresse IPv4 ou IPv6 de votre ordinateur client. Vous pouvez l’obtenir via une invite de commandes en tapant IPConfig, puis en appuyant sur Entrée. Cette information vous permet de déterminer rapidement si le trafic dans la trace implique votre ordinateur client. S’il inclut un proxy connu, effectuez un test ping et récupérez son adresse IP également.

  • Videz votre cache de résolution DNS et, si possible, fermez tous les navigateurs à l’exception de celui dans lequel vous exécutez vos tests. Si vous ne pouvez pas effectuer ceci, par exemple, si le support utilise un outil basé sur un navigateur pour afficher le bureau de votre ordinateur client, vous devez filtrer votre trace.

  • Dans une trace occupé (e), recherchez le service Office 365 que vous utilisez. Si vous avez vu jamais ou rarement votre trafic auparavant, il s’agit d’une étape utile pour séparer le problème de performance à partir d’autres bruit réseau. Il existe plusieurs méthodes pour effectuer cette action. Directement avant votre test, vous pouvez utiliser ping ou, PsPing, à l’URL du service spécifique (ping outlook.office365.com et/ou psping -4 microsoft-my.sharepoint.com:443, pour obtenir des exemples). Vous pouvez également facilement trouver cette commande PsPing dans une trace Netmon (par son nom processus). Qui vous donne un point de départ vous recherchez.

    Vous pouvez également utiliser le traçage Netmon au moment du problème. Pour vous orienter, utilisez un filtre tel que ContainsBin(FrameData, ASCII, "office") ou ContainsBin(FrameData, ASCII, "outlook"). Vous pouvez enregistrer votre numéro de trame à partir du fichier de trace. Vous pouvez également faire défiler le volet Frame Summary complètement à droite et rechercher la colonne Conversation ID. Un nombre y est indiqué pour l’ID de cette conversation spécifique que vous pouvez également enregistrer et examiner séparément plus tard. N’oubliez pas de supprimer ce filtre avant d’appliquer un autre filtrage.

    Conseil : Netmon inclut un grand nombre de filtres prédéfinis. Cliquez sur le bouton Load Filter en haut du volet de filtre Display.

    Rechercher votre adresse IP à l’aide d’une commande PSPing dans une ligne de commande sur l’ordinateur client

    Trace Netmon du client affichant la même commande PSPing via le filtre TCP.Flags.Syn ==1

    Familiarisez-vous avec votre trafic et apprenez à trouver les informations utiles. Par exemple, découvrez comment identifier le paquet dans la trace incluant la première référence au service Office 365 que vous utilisez (tel que « Outlook »).

Par exemple, pour Office 365 Outlook Online, le trafic commence par ceci :

  • Requête standard DNS et réponse DNS pour outlook.office365.com avec les ID de requête correspondants. Il est important de noter le décalage de temps pour cet aller-retour, ainsi que l’emplacement géographique auquel le DNS global d’Office 365 envoie la demande de résolution du nom. Dans l’idéal, celui doit être situé localement. (Ces informations peuvent être suivies par le trafic DNS, la connexion en ligne.)

  • Demande HTTP GET avec l’état Déplacé définitivement (301)

  • Trafic RWS, notamment les demandes et réponses de connexion RWS. (Le Winsock distant établit une connexion).

  • Une conversation TCP SYN et SYN/ACK TCP. Un grand nombre de paramètres de cette conversation ont une incidence sur les performances.

  • Une série de trafic TLS:TLS incluant notamment les conversations de négociation TLS et de certificat TLS. (N’oubliez pas que les données sont chiffrées via SSL/TLS).

Tous les composants du trafic sont importantes et connectées, mais des petites portions de la trace contiennent des informations particulièrement importantes pour la résolution des problèmes de performance (sur lesquelles nous allons nous concentrer). Par ailleurs, dans le cadre de notre expérience en matière de résolution des problèmes de performance d’Office 365 au sein de Microsoft, nous avons compilé une liste des dix principaux problèmes rencontrés. Nous allons décrire ceux-ci et l’utilisation des outils disponibles pour les solutionner.

Le tableau ci-dessous utilise plusieurs outils (que vous avez déjà à votre disposition éventuellement). Dans la mesure du possible, des liens vers les points d’installation sont fournis. La liste comprend les principaux outils de suivi réseau tels que Netmon et Wireshark, mais vous pouvez utiliser n’importe quel outil de suivi auquel vous êtes habitué, notamment dans le cadre du filtrage du trafic réseau. Dans le cadre des tests, veillez à :

  • Fermer votre navigateur et tester avec qu’un seul navigateur en cours d’exécution - Cela permet de réduire le trafic général vous capturez. Il est pour une trace moins occupé (e).

  • Vider le cache de résolution DNS sur l’ordinateur client - Cela vous permet de commencer de zéro au moment de la capture et de récupérer une trace plus claire.

Problèmes principaux

Problèmes courants que vous pouvez rencontrer et comment les détecter dans votre trace réseau.

Problème principal

Outil

Éléments à rechercher

Dimensionnement de fenêtre TCP

  • Informations trouvées dans le paquet SYN - SYN/ACK.

  • Il est possible que le matériel ancien ou vieillissant ne puisse pas utiliser le dimensionnement de fenêtre TCP.

  • À défaut de paramètres de dimensionnement de fenêtre TCP corrects, la mémoire tampon de 16 bits par défaut dans les en-têtes TCP est remplie en quelques millisecondes.

  • Le trafic ne peut pas poursuivre les envois tant que le client ne reçoit pas d’accusé de réception confirmant la réception des données d’origine, ce qui provoque des retards.

Netmon

Wireshark

Recherchez le trafic SYN - SYN/ACK dans votre trace réseau.

Dans Netmon, utilisez un filtre comme tcp.flags.syn == 1. Ce filtre est la même dans Wireshark.

Filtre dans Netmon ou Wireshark sur les paquets SYN pour les deux outils : TCP.Flags.Syn == 1.

Pour chaque paquet SYN, il existe un numéro de port source (SrcPort) avec une correspondance dans le port de destination (DstPort) de l’accusé de réception associé (SYN/ACK).

Pour afficher la valeur de dimensionnement de fenêtre utilisée par votre connexion réseau, commencez par développer le paquet SYN, puis le paquet SYN/ACK associé.

Graphique montrant comment faire correspondre SrcPort et DstPort dans une trace, pour obtenir le délai

Paramètres de durée d’inactivité TCP

  • Traditionnellement, la plupart des réseaux de périmètre sont configurés pour les connexions transitoires, aussi les connexions inactives sont-elles généralement terminées.

  • Les sessions TCP inactives peuvent être terminées par des proxys et pare-feu à des valeurs supérieures à 100 à 300 secondes.

  • Ceci pose problème pour Outlook Online, car le programme crée et utilise des connexions longues, inactives ou non.

  • Lorsque les connexions sont terminées par des dispositifs de proxy ou pare-feu, le client n’en est pas informé. Or, dans une tentative d’utilisation d’Outlook Online, un ordinateur client tente à plusieurs reprises de récupérer la connexion avant d’en établir une nouvelle.

  • Il est possible que vous receviez des invites du produit, ou observiez des blocages ou une baisse des performances lors du chargement des pages.

Netmon

Wireshark

Dans Netmon, consultez le champ Time Offset pour un aller-retour. Un aller-retour est le délai entre l’envoi d’une demande au serveur par le client et la réception d’une réponse en retour. Examinez les paquets entre le client et le point de sortie (par exemple, Client --> Proxy) ou entre le client et Office 365 (Client --> Office 365). Vous pouvez observer ceci dans plusieurs types de paquets.

Par exemple, le filtre dans Netmon peut se présenter comme .Protocol.IPv4.Address == 10.102.14.112 AND .Protocol.IPv4.Address == 10.201.114.12, ou dans Wireshark, ip.addr == 10.102.14.112 && ip.addr == 10.201.114.12.

Conseils : 

  • Vous ne savez pas si l’adresse IP dans votre trace appartient à votre serveur DNS ? Essayez de la rechercher via une ligne de commande. Cliquez sur Démarrer > Exécuter, puis tapez cmd ou appuyez sur Touche Windows, puis tapez cmd. À l’invite, tapez nslookup <the IP address from the network trace>. Pour le test, utilisez nslookup sur l’adresse IP de votre propre ordinateur.

  • Pour afficher une liste des plages d’adresses IP de Microsoft, voir URL et plages d’adresses IP Office 365.

Si un problème se pose, ils doivent s’attendre décale heure longue pour s’afficher dans ce cas (Outlook Online), en particulier dans les paquets TLS:TLS qui montrent le passage des données d’Application (par exemple, dans Netmon vous trouverez paquets de données d’application via .Protocol.TLS AND Description == "TLS:TLS Rec Layer-1 SSL Application Data"). Vous devriez voir une progression lisse dans le temps au sein de la session. Si vous voyez longs délais lors de l’actualisation votre Outlook Online, cela peut être dû à un haut degré de réinitialisations envoyé.

Temps de latence/durée des boucles

  • Latence est une mesure qui peut changer beaucoup en fonction de plusieurs variables, ces appareils vieillissants de la mise à niveau, ajoutez un grand nombre d’utilisateurs à un réseau et le pourcentage de bande passante globale utilisée par d’autres tâches sur une connexion réseau.

  • Des calculateurs de bande passante pour Office 365 sont disponibles sur la page Planification réseau et optimisation des performances pour Office 365.

  • Vous avez besoin de mesurer la vitesse de votre connexion ou la bande passante de la connexion à votre fournisseur de services Internet ? Essayez ce site (ou des sites semblables) : Speedtest et Pingtest.

Ping

PsPing

Netmon

Wireshark

Pour suivre la latence dans une trace, il est recommandé d’enregistrer l’adresse IP de l’ordinateur client et l’adresse IP du serveur DNS dans Office 365. Cela permet de filtrer plus facilement les traces. Si vous vous connectez via un proxy, vous avez besoin de l’adresse IP de votre ordinateur client, de l’adresse IP du proxy/du point de sortie et de l’adresse IP du DNS Office 365 pour simplifier les choses.

Une demande ping envoyée à outlook.office365.com vous indiquera le nom du centre de données recevant la demande, même s’il est possible que ping ne puisse pas se connecter pour envoyer les paquets ICMP consécutifs de la marque. Si vous utilisez PsPing (outil téléchargeable gratuitement) et spécifiez le port (443), et utilisez éventuellement IPv4 (-4), vous obtenez une durée de boucle moyenne pour les paquets envoyés. Ceci fonctionnera pour les autres URL dans les services Office 365, tels que psping -4 yourSite.sharepoint.com:443. En fait, vous pouvez spécifier un nombre de tests ping pour obtenir un échantillon plus large pour votre moyenne. Par exemple, vous pouvez essayer ceci : psping -4 -n 20 yourSite-my.sharepoint.com:443.

Remarque : PsPing n’envoie pas de paquets ICMP. Il effectue un test ping avec des paquets TCP sur un port spécifique, de telle sorte que vous pouvez utiliser un des ports que vous savez ouverts. Dans Office 365, qui utilise SSL/TLS, essayez de joindre le port : 443 à votre test PsPing.

Capture d’écran montrant un test ping résolvant outlook.office365.com et une commande PSPing sur le port 443 obtenant le même résultat, mais indiquant une durée moyenne nécessaire pour l’aller-retour de 6,5 ms

Si vous avez chargé la page Office 365 présentant des performances ralenties tandis que vous générez une trace réseau, vous devez filtrer une trace Netmon ou Wireshark pour DNS. Il s’agit d’une des adresses IP que nous recherchons.

Voici les étapes à suivre pour filtrer votre trace Netmon pour obtenir l’adresse IP (et examiner la latence DNS). Cet exemple utilise outlook.office365.com, mais il peut également utiliser l’URL d’un client SharePoint Online (hithere.sharepoint.com, par exemple).

  1. Effectuez un test ping sur l’URL ping outlook.office365.com puis, dans les résultats, notez le nom et l’adresse IP du serveur DNS auquel la demande ping a été envoyée.

    Requête Ping sur outlook.office365.com affichant le DNS et l’adresse IP de namnorthwest

  2. Network trace ouvre la page, ou effectuer l’action qui vous donne le problème de performance ou, si vous voyez une latence élevée à la commande ping, elle-même, une trace réseau.

  3. Ouvrez la trace dans Netmon et filtrez sur DNS (ce filtre fonctionne également dans Wireshark, mais est sensible à la casse -- dns). Comme vous connaissez le nom du serveur DNS à partir de votre commande ping, vous pouvez également filtrer plus rapidement dans Netmon comme suit : DNS AND ContainsBin(FrameData, ASCII, "namnorthwest"), qui ressemble à ceci dans Wireshark : dns and frame contains "namnorthwest".

    Ouvrez le paquet de réponse puis, dans la fenêtre Frame Details de Netmon, cliquez sur DNS pour accéder à davantage d’informations. Les informations DNS incluent l’adresse IP du serveur DNS auquel la demande a été transmise dans Office 365, vous aurez besoin de cette adresse IP pour l’étape suivante (outil PsPing). Supprimez le filtre, cliquez avec le bouton droit sur la réponse DNS dans Netmon, puis sur Frame Summary > Find Conversations > DNS pour afficher les requête et réponse DNS côte-à-côte.

    Trace filtrée par les options Find Conversations, puis DNS

  4. Dans Netmon, notez également la colonne Time Offset entre les demande et réponse DNS.

    Résultats Netmon supplémentaires filtrés sur DNS AND CONTAINSBIN(Framedata, ASCII, "namnorthwest") montrant un décalage de temps faible entre la requête et la réponse

Dans l’étape suivante, la facile à installer et utiliser PsPing outil est très pratique, car ICMP est souvent bloqué sur pare-feu, et parce que PsPing élégante effectue le suivi de latence en millisecondes. PsPing termine une connexion TCP avec une adresse et un port (dans notre cas ouvrir le port 443).

  1. Installez PsPing.

  2. Ouvrez une invite de commandes (Démarrer > Exécuter, puis tapez cmd, ou Touche Windows, puis tapez cmd) et placez-vous dans le répertoire dans lequel vous avez installé PsPing pour exécuter la commande PsPing. Dans mes exemples, vous pouvez voir que j’ai créé un dossier « Perf » à la racine du lecteur C. Vous pouvez faire de même pour y accéder rapidement.

  3. Tapez la commande afin d’effectuer le test PsPing sur l’adresse IP du serveur DNS Office 365 à partir de votre trace Netmon précédente, pensez à ajouter le numéro de port (psping -n 20 132.245.24.82:445). Cela vous donne un échantillonnage de 20 tests ping et vous permet de calculer la latence moyenne à la fin du test PsPing.

    Commande PSPing psping -n 20 132.245.24.82:443 qui renvoie une latence moyenne de 25,51 millisecondes

Si vous accédez à Office 365 via un serveur proxy, les étapes sont un peu différentes. Vous devez commencer par effectuer un test PsPing sur le serveur proxy pour obtenir une valeur de latence moyenne en millisecondes vers le proxy/point de sortie, puis effectuer un test PsPing sur le proxy ou sur un ordinateur avec une connexion Internet directe pour obtenir la valeur manquante (celle de la boucle vers Office 365).

Si vous choisissez d’effectuer un test PsPing à partir du proxy, vous aurez deux valeurs en millisecondes : de l’ordinateur client au serveur proxy ou point de sortie, et du serveur proxy à Office 365. Vous avez terminé d’enregistrer les valeurs.

Si vous exécutez PsPing sur un autre ordinateur client qui a une connexion directe à Internet, c'est-à-dire, sans proxy, vous devrez deux valeurs millisecondes : ordinateur Client au serveur proxy ou point de sortie et de l’ordinateur client vers Office 365. Dans ce cas, soustraire la valeur de l’ordinateur client au proxy serveur ou sortie au point de la valeur de l’ordinateur client vers Office 365, et cela créera les nombres RTT depuis votre ordinateur client vers le serveur proxy ou un point de sortie et du point server ou sortie proxy vers Office 365.

Toutefois, si vous pouvez trouver un ordinateur client à l’emplacement concerné qui est connecté directement ou ignore le proxy, vous pouvez voir si le problème se reproduit à cet endroit pour commencer et effectuer un test en utilisant celui-ci ensuite.

Latence, comme illustré dans une trace Netmon, ces millisecondes supplémentaires peuvent additionner, si nombre est suffisant d'entre eux dans n’importe quelle session donnée.

Latence générale dans Netmon, avec la colonne Netmon default Time Delta ajoutée à la fenêtre Frame Summary

Remarque : Votre adresse IP peut être différente des adresses IP présentées ici. Par exemple, votre test ping peut retourner une valeur qui ressemble davantage à 157.56.0.0/16 ou une plage similaire. Pour consulter la liste des plages utilisées par Office 365, voir URL et plages d’adresses IP Office 365. Pensez à développer tous les nœuds (bouton dans la partie supérieure) si vous voulez rechercher 132.245, par exemple.

Authentification du proxy

  • Ceci ne vous concerne que si vous utilisez un serveur proxy. Si ce n’est pas le cas, vous pouvez ignorer ces étapes.

  • Lorsque qu’elle fonctionne correctement, l’authentification du proxy ne doit durer que quelques millisecondes à chaque fois. Vous ne devez pas observer des performances médiocres de façon intermittente pendant les pics d’utilisation (par exemple).

  • Si l’authentification du proxy est activée, chaque fois que vous établissez une nouvelle connexion TCP à Office 365 pour obtenir des informations, vous devez passer par un processus d’authentification en arrière-plan. Ainsi, lorsque vous basculez de Calendrier à Courrier dans Outlook Online par exemple, vous vous authentifiez. Dans SharePoint Online, si une page affiche du contenu multimédia ou des données provenant de différents sites ou emplacements, vous vous authentifiez pour chaque connexion TCP nécessaire à l’affichage des données.

  • Dans Outlook Online, vous pouvez rencontrer des temps de chargement ralentis chaque fois que vous basculez entre Calendrier et votre boîte aux lettres, ou des chargements de page lents dans SharePoint Online. Il existe toutefois d’autres symptômes non répertoriés ici.

    Authentification du proxy est un paramètre de votre serveur proxy de sortie. Si elle est à l’origine d’un problème de performance avec Office 365, vous devez consulter votre équipe de mise en réseau.

Netmon

Wireshark

L’authentification proxy intervient chaque fois qu’une nouvelle session TCP doit être utilisée, fréquemment pour demander des fichiers ou des informations à partir du serveur, ou pour fournir des informations. Par exemple, vous pouvez voir l’authentification du proxy autour des demandes HTTP GET ou HTTP POST. Si vous voulez voir les images dans laquelle vous soyez l’authentification des demandes dans votre trace, ajoutez la colonne 'NTLMSSP Summary' Netmon et filtre pour .property.NTLMSSPSummary. Pour voir combien de temps prend l’authentification, ajoutez la colonne Time Delta. Pour ajouter une colonne à Netmon :

  1. Cliquez avec le bouton droit sur une colonne telle que Description.

  2. Cliquez sur Choose Columns. Sélectionnez NTLMSSP Summary et Time Delta dans la liste, puis cliquez sur Add.

  3. Placez les nouvelles colonnes avant ou après la colonne Description afin que vous puissiez les lire côte-à-côte. Cliquez sur OK.

Même si vous n’ajoutez pas la colonne, le filtre de Netmon est prises en charge. Mais votre résolution des problèmes seront beaucoup plus facile si vous pouvez voir quel stade d’authentification Active. Lorsque vous avez besoin d’instances de l’authentification du Proxy, veillez à étudier toutes les images lorsqu’il existe un défi NTLM, ou un Message s’authentifier est présente. Le cas échéant, la partie spécifique du trafic et rechercher les Conversations avec le bouton droit > TCP. N’oubliez pas des valeurs Time Delta dans ces Conversations.

Trace Netmon montrant l’authentification proxy, filtrée par conversation

Délai de quatre secondes dans l’authentification du proxy tel qu’observé dans Wireshark. La colonne Time delta from previous displayed frame a été ajoutée par clic droit sur le champ du même nom dans les détails de la trame et sélection de l’option Add as Column.

Dans Wireshark, la colonne « Time delta from previous displayed frame » peut être ajoutée par clic droit sur le champ du même nom dans les détails de la trame et sélection de l’option Add as Column.

Performances de DNS

  • La résolution de noms fonctionne de façon optimale lorsqu’elle intervient à proximité du pays ou de la région du client.

  • Si la résolution de noms DNS intervient à l’étranger, cela peut ajouter plusieurs secondes au chargement des pages.

  • Dans l’idéal, la résolution de noms dure moins de 100 millisecondes. Si ce n’est pas le cas, vous devez effectuer des recherches plus approfondies.

Conseil : Vous ne savez pas comment fonctionne la connectivité des clients dans Office 365 ? Consultez un document de référence ici.

Netmon

Wireshark

PsPing

Une trace réseau permet également d’analyser les performances de DNS. PsPing est également utile pour identifier ou écarter une cause possible.

Le trafic DNS est basé sur les demandes TCP et UDP, et les réponses sont clairement marquées avec un ID qui vous aidera à faire correspondre une demande avec sa réponse spécifique. Vous verrez le trafic DNS lorsque, par exemple, SharePoint Online utilise un nom de réseau ou une URL sur une page web. En règle générale, la plupart du trafic, sauf lors du transfert des zones, est exécuté sur UDP.

Dans Netmon et Wireshark, le filtre plus simple qui vous permet d’examiner le trafic DNS est simplement dns. Veillez à utiliser des minuscules lorsque vous spécifiez le filtre. N’oubliez pas de vider le cache de résolution DNS avant de commencer à reproduire le problème sur votre ordinateur client. Par exemple, si vous avez chargement d’une page SharePoint Online lent pour la page d’accueil, vous devez fermer tous les navigateurs, ouvrez une nouvelle fenêtre de navigateur, lancer le suivi, vider le cache DNS et accédez à votre site SharePoint Online. Une fois que la page entière est résolu, vous devez arrêter et enregistrer la trace.

Un filtre de base pour DNS dans Netmon est DNS

Vous voulez consulter l’heure de décalage ici. Et il peut être utile ajouter la colonne Time Delta dans Netmon ce que vous pouvez faire en procédant comme suit :

  1. Cliquez avec le bouton droit sur une colonne telle que Description.

  2. Cliquez sur Choose Columns.

  3. Sélectionnez Time Delta dans la liste, puis cliquez sur Add.

  4. Placez la nouvelle colonne avant ou après la colonne Description afin que vous puissiez les lire côte-à-côte. Cliquez sur OK.

Si vous trouvez une requête d’intérêt, vous pouvez isoler en double-cliquant sur cette requête dans le volet de détails cadre, en choisissant Find Conversations > DNS. Notez que le panneau de configuration Network Conversations déviations de droite à la conversation spécifique dans le fichier journal du trafic UDP.

Trace Netmon de la charge Outlook Online filtrée par DNS et utilisation des options Find Conversations, puis DNS pour affiner les résultats

Dans Wireshark vous pouvez rendre une colonne pour fois DNS. Votre trace (ou ouvrir une trace) dans Wireshark et filtrer par dnsou plus lorsque dns.time. Cliquez sur n’importe quelle requête DNS et, dans le panneau de configuration avec les détails, développez les détails Domain Name System (response) . Vous voyez un champ par heure (par exemple, [Time: 0.001111100 seconds]. Avec le bouton droit de cette fois, puis sélectionnez appliquer en tant que colonne. Cela vous donne une colonne heure pour le tri plus rapide de votre trace. Cliquez sur la nouvelle colonne pour trier par ordre décroissant des valeurs pour déterminer les appel DNS a pris la plus longue pour résoudre.

Exploration de SharePoint Online filtrée dans Wireshark en fonction de dns.time (en minuscules), avec le délai indiqué dans les détails présenté dans une colonne et trié par ordre croissant

Si vous voulez faire plus enquête de l’heure de résolution DNS, psping sur le port DNS utilisé par TCP (par exemple, psping <IP address of DNS server>:53). Vous voyez toujours un problème de performance ? Dans ce cas, le problème est censée être un réseau plus large de problème à un problème de spécifiques à l’application de DNS que vous êtes en appuyant sur pour effectuer la résolution. Il est également important de répéter, qu’une commande ping sur outlook.office365.com vous indiquera à l’endroit où résolution de noms DNS pour Outlook Online est en cours (par exemple, outlook-namnorthwest.office365.com).

Si le problème semble propre à DNS, il peut être nécessaire de demander à votre service informatique d’examiner les configurations et redirecteurs DNS afin d’approfondir les recherches.

Extensibilité du proxy

  • Les services, tels que Outlook Online dans Office 365, octroient aux clients plusieurs connexions longues.

  • Par conséquent, chaque utilisateur peut utiliser plusieurs connexions nécessitant une durée plus longue.

Conseil : Vous avez besoin de planifier l’utilisation de la bande passante car vous êtes sur le point d’ajouter plusieurs utilisateurs à Office 365 ? Voir Planifier l’utilisation de la bande passante Internet pour Office 365. Des calculateurs de bande passante sont disponibles dans cette page.

Math

Il n’existe pas de trace réseau ou outil de dépannage spécifique à cet outil. Celui-ci est basé sur les calculs de bande passante en fonction de limitations et d’autres variables.

Taille de segment maximale TCP

  • Informations trouvées dans le paquet SYN - SYN/ACK.

  • Effectuez ce test dans les traces réseau de performance que vous avez capturées pour vous assurer que les paquets TCP sont configurés pour transporter la quantité maximale de données possible.

  • L’objectif est d’avoir une taille de segment maximale de 1460 octets pour la transmission des données.

  • Si vous vous trouvez derrière un proxy ou si vous utilisez un traducteur d’adresses réseau, n’oubliez pas d’exécuter ce test du client au proxy/point de sortie/traducteur d’adresses réseau et du proxy/point de sortie/traducteur d’adresses réseau à Office 365 pour obtenir de meilleurs résultats. Il s’agit de sessions TCP différentes.

Netmon

Taille de Segment maximale (MSS) TCP est un autre paramètre du contrôle en trois étapes dans votre trace réseau, ce qui signifie que vous trouverez les données souhaitées dans le paquet SYN - paquet SYN/ACK. MSS est en réalité assez simple de voir.

Ouvrez n’importe quelle trace réseau de performances que vous avez et recherchez la connexion qui vous intéresse ou qui illustre le problème de performance.

Remarques : 

  • Si vous examinez une trace et recherchez le trafic relatif à votre conversation, filtrez sur l’adresse IP du client ou l’adresse IP du serveur proxy et/ou du point de sortie. En y accédant directement, vous devez effectuer un test ping sur l’URL testée pour l’adresse IP d’Office 365 dans la trace et filtrer dessus.

  • Examiner la trace d’occasion ? Essayez d’utiliser des filtres pour orienter. Dans Netmon, exécuter une recherche basée sur l’URL, par exemple Containsbin(framedata, ascii, "sphybridExample"), prenez note du numéro de l’image. Dans Wireshark utiliser quelque chose comme frame contains "sphybridExample". Si vous constatez que vous avez trouvé le trafic Winsock distant (RW) (il peut s’afficher sous une [PSH, ACK] dans Wireshark), n’oubliez pas que RW se connecte puisse être vu peu de temps avant pertinent SYN - SYN/ACK, comme indiqué précédemment. À ce stade, vous pouvez enregistrer le nombre d’images, supprimer le filtre, cliquez sur tout le trafic dans la fenêtre Network Conversations de Netmon pour examiner le plus proche SYN.

  • Par ailleurs, si vous n’avez pas reçu les informations d’adresse IP au moment de la création de la trace, la recherche de votre URL dans la trace (partie de sphybridExample-my.sharepoint.com, par exemple), vous donnera les adresses IP sur lesquelles filtrer.

  1. Recherchez la connexion qui vous intéresse dans la trace. Pour ce faire, analysez la trace en filtrant sur les adresses IP, ou en sélectionnant les ID de conversation spécifiques à l’aide de la fenêtre Network Conversations dans Netmon.

    Filtrage par conversation Cliquer avec le bouton sur la trame SYN, puis sur Find Conversations et TCP

  2. Une fois que vous avez trouvé le paquet SYN, développez TCP (dans Netmon) ou Transmission Control Protocol (dans Wireshark) dans le volet Frame Details.

  3. Développez les options TCP et MaxSegmentSize.

  4. Recherchez les valeurs de trame SYN-ACK, développez les options TCP et MaxSegmentSize.

  5. Le plus petite des deux valeurs est votre taille de segment maximale.

Dans cette image, rendre utilise la colonne prédéfinie TCP Troubleshoot de Netmon.

Network Trace filtré dans Netmon à l’aide des colonnes prédéfinies

La colonne prédéfinie apparaît dans la partie supérieure du volet Frame Details. (Pour revenir à l’affichage normal, cliquez à nouveau sur Columns, puis sélectionnez Time Zone.)

Emplacement du menu déroulant Columns pour l’option TCP résolution (dans la partie supérieure de la fenêtre Frame Summary)

Voici une trace filtrée dans Wireshark. Il existe un filtre spécifique à la valeur MSS (tcp.options.mss). Les cadres de SYN, SYN/ACK, négociation ACK sont liés au bas de la Wireshark équivalent à Frame Details (donc de trame ACK 47, des liens vers des 46 SYN/ACK, des liens vers les SYN 43) pour simplifier ce type de travail.

Trace filtrée dans Wireshark par tcp.options.mss pour la taille de segment maximale (MSS, Max Segment Size)

Si vous avez besoin de consulter l’accusé de réception sélectif (rubrique suivante dans ce tableau), ne fermez pas votre trace.

Accusé de réception sélectif

  • Informations trouvées dans le paquet SYN - SYN/ACK.

  • Doit être signalé comme autorisé dans SYN et SYN/ACK.

  • L’accusé de réception sélectif (SACK) permet par ailleurs une meilleure retransmission des données lorsqu’il manque un ou plusieurs paquets.

  • Les appareils peuvent désactiver cette fonctionnalité, ce qui peut affecter les performances.

  • Si vous vous trouvez derrière un proxy ou si vous utilisez un traducteur d’adresses réseau, n’oubliez pas d’exécuter ce test du client au proxy/point de sortie/traducteur d’adresses réseau et du proxy/point de sortie/traducteur d’adresses réseau à Office 365 pour obtenir de meilleurs résultats. Il s’agit de sessions TCP différentes.

Netmon

L’accusé de réception sélectif (SACK) est un autre paramètre dans la négociation SYN-SYN/ACK. Vous pouvez filtrer votre trace sur SYN - SYN/ACK de plusieurs façons.

  1. Recherchez la connexion dans la trace qui vous intéresse en analysant la trace, en filtrant sur les adresses IP ou en cliquant sur un ID de conversation dans la fenêtre Network Conversations de Netmon.

  2. Une fois que vous avez trouvé le paquet SYN, développez TCP dans Netmon ou Transmission Control Protocol dans Wireshark dans la section Frame Details.

  3. Développez les options TCP, puis SACK.

  4. Recherchez les valeurs de trame SYN-ACK, développez les options TCP et SACK.

  5. Vérifiez que SACK est autorisé dans SYN et SYN/ACK.

Les valeurs SACK apparaissent comme suit dans Netmon et Wireshark.

Accusé de réception sélectif (SACK) dans Netmon suite à l’application du filtre tcp.flags.syn == 1

Accusé de réception sélectif (SACK) dans Wireshark avec le filtre tcp.flags.syn == 1

Géolocalisation de DNS

  • L’emplacement géographique dans lequel Office 365 tente de résoudre votre appel DNS affecte la vitesse de votre connexion.

  • Dans Outlook Online, une fois la première recherche DNS terminée, l’emplacement de ce DNS est utilisé pour la connexion à votre centre de données le plus proche. Vous serez connecté à un serveur CAS Outlook Online, qui utilisera le réseau principal pour se connecter au centre de données dans lequel vos données sont stockées. Cette méthode est plus rapide.

  • Lorsqu’il accède à SharePoint Online, un utilisateur en déplacement à l’étranger est redirigé vers son centre de données actif. Il s’agit du centre de données dont l’emplacement est basé sur le site du client SharePoint Online (centre de données aux États-Unis si l’utilisateur est basé aux États-Unis).

  • Lync Online inclut des nœuds actifs dans plusieurs centres de données à la fois. Lorsque les demandes sont envoyées pour des instances Lync Online, le DNS de Microsoft identifie l’emplacement géographique d’où provient la demande et renvoie les adresses IP à partir du centre de données régional le plus proche dans lequel Lync Online est actif.

Conseil : Vous voulez en savoir plus sur la connexion des clients à Office 365 ? Consultez l’article de référence sur la connectivité des clients (et ses graphiques utiles).

Ping

PsPing

Les demandes de résolution de noms de serveurs DNS du client vers les serveurs DNS de Microsoft doivent dans la plupart des résultats de cas dans Microsoft DNS renvoyant l’adresse IP d’un centre de données régionaux (dC). Que cela signifie pour vous ? Si votre siège se trouve à Bangalore, Inde, mais que vous êtes en déplacement aux États-Unis, lorsque votre navigateur effectue une demande pour Outlook Online, les serveurs DNS de Microsoft doivent remettre vous adresses IP aux centres de données aux États-Unis, un centre de données régionaux. Si mail est nécessaire à partir d’Outlook, ces données seront traversent réseau principal rapide de Microsoft entre les centres de données.

DNS fonctionne plus rapidement lorsque la résolution de noms est effectuée à proximité de l’emplacement de l’utilisateur. Si vous êtes en Europe, vous voulez utiliser un DNS Microsoft en Europe et (dans l’idéal) accéder à un centre de données en Europe. Les performances entre un client en Europe accédant à DNS et un centre de données en Amérique sont ralenties.

Exécutez l’outil Ping sur outlook.office365.com pour déterminer l’emplacement géographique d’acheminement de votre demande DNS. Si vous êtes en Europe, vous devez recevoir une réponse de outlook-emeawest.office365.com. Si vous êtes en Amérique, vous devez recevoir une réponse de outlook-namnorthwest.office365.com.

  1. Ouvrez l’invite de commandes sur l’ordinateur client (Démarrer > Exécuter > cmd ou touche Windows , puis tapez cmd).

  2. Tapez ping outlook.office365.com, puis appuyez sur Entrée.

    N’oubliez pas, spécifiez -4 si vous voulez spécifier à la commande ping via IPv4. Vous pouvez échouer obtenir une réponse à partir des paquets ICMP, mais vous devriez voir le nom du système DNS auquel la demande a été routée.

Si vous voulez consulter les données de latence pour cette connexion, effectuez un test PsPing sur l’adresse IP du serveur renvoyée par la commande ping.

Test ping de outlook.office365.com affichant la résolution en outlook-namnorthwest

Commande PSPing à l’adresse IP renvoyée par le test ping sur outlook.office365.com affichant une latence moyenne de 28 millisecondes

Dépannage des applications Office 365

Netmon

HTTPWatch

Console F12 dans le navigateur

Nous ne décrivons pas les outils utilisés pour la résolution des problèmes spécifiques aux applications dans cet article portant sur le réseau. Les ressources que vous pouvez utiliser sont disponibles sur cette page.

Rubriques connexes

Gestion des points de terminaison Office 365
connectivité de résolution des problèmes Office 365

Remarque : Avertissement traduction automatique : cet article a été traduit par un ordinateur, sans intervention humaine. Microsoft propose cette traduction automatique pour offrir aux personnes ne maîtrisant pas l’anglais l’accès au contenu relatif aux produits, services et technologies Microsoft. Comme cet article a été traduit automatiquement, il risque de contenir des erreurs de grammaire, de syntaxe ou de terminologie.

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.

×