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

Avez-vous besoin de connaître les étapes à suivre pour identifier et corriger les retards, les blocages et le ralentissement des performances entre SharePoint, OneDrive, Exchange Online ou Skype Entreprise Online et votre ordinateur client ? Avant d’appeler le support technique, cet article peut vous aider à résoudre les problèmes de performances Office 365 et même à résoudre certains des problèmes les plus courants.

Cet article est en fait un exemple de plan d’action que vous pouvez utiliser pour capturer des données précieuses sur votre problème de performances au fur et à mesure. Certains problèmes principaux sont également inclus dans cet article.

Si vous débutez dans le domaine des performances réseau et que vous souhaitez établir un plan à long terme pour surveiller les performances entre vos ordinateurs clients et Office 365, consultez Office 365 réglage et résolution des problèmes de performances - Administration et professionnels de l’informatique.

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

Ce plan d’action contient deux parties : une phase de préparation et une phase de journalisation. Si vous rencontrez actuellement un problème de performances et que vous devez effectuer une collecte de données, vous pouvez commencer à utiliser ce plan immédiatement.

Préparer l’ordinateur client

• Recherchez un ordinateur client capable de reproduire le problème de performances. Cet ordinateur sera utilisé pendant la résolution des problèmes.
• Notez les étapes à l’origine du problème de performances afin d’être prêt au moment du test.
• Installez les outils de collecte et d’enregistrement des informations :
  • Installez Netmon 3.4 (ou utilisez un outil de suivi réseau équivalent).
  • Installez l’édition de base gratuite de HTTPWatch (ou utilisez un outil de suivi réseau équivalent).
  • Utilisez un enregistreur d’écran ou exécutez l’enregistreur d’étapes (PSR.exe) fourni avec Windows Vista et versions ultérieures, afin de conserver un enregistrement des étapes que vous effectuez pendant les tests.

Journaliser le problème de performances

• Fermez tous les navigateurs Internet superflus.

• Démarrez l’enregistreur d’étapes ou un autre enregistreur d’écran.

• Démarrez votre capture Netmon (ou outil de suivi réseau).

• Effacez votre cache DNS sur l’ordinateur client 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 de Analyseur de performances client Exchange à partir de la console d’administration Office 365.

• Reproduisez les étapes exactes qui provoquent le problème de performances.

• Arrêtez la trace de votre Netmon ou d’un autre outil.

• Sur la ligne de commande, exécutez un itinéraire de suivi vers votre abonnement Office 365 en tapant la commande suivante, puis en appuyant sur Entrée :

  tracert <subscriptionname>.onmicrosoft.com
  

• Arrêtez l’enregistreur d’étapes et enregistrez la vidéo. Veillez à inclure la date et l’heure de la capture et si elle présente des performances bonnes ou incorrectes.

• Enregistrez les fichiers de trace. Là encore, veillez à inclure la date et l’heure de la capture et si elle présente des performances bonnes ou mauvaises.

Si vous n’êtes pas familiarisé avec l’exécution des outils mentionnés dans cet article, ne vous inquiétez pas, car nous vous fournissons les étapes suivantes. Si vous avez l’habitude d’effectuer ce type de capture réseau, vous pouvez passer à Comment collecter des bases de référence, qui décrit le filtrage et la lecture des journaux.

Vider d’abord le cache DNS

Pourquoi ? En vidant le cache DNS, vous démarrez vos tests avec une ardoise propre. En effaçant le cache, vous réinitialisez le contenu du programme de résolution DNS aux entrées les plus récentes. N’oubliez pas qu’un vidage ne supprime pas les entrées de fichier HOST. Si vous utilisez beaucoup d’entrées de fichier HOST, vous devez copier ces entrées dans un fichier d’un autre répertoire, puis vider le fichier HOST.

Vider le cache de votre programme de résolution DNS

1. Ouvrez l’invite de commandes (Démarrer exécuter>>cmd ou touche> Windowscmd).

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

   ipconfig /flushdns
   

Netmon

L’outil de surveillance réseau (Netmon) de Microsoft analyse les paquets (trafic réseau) qui passent entre les ordinateurs sur les réseaux. En utilisant Netmon pour suivre le trafic avec Office 365 vous pouvez capturer, afficher et lire les en-têtes de paquets, identifier les appareils intermédiaires, case activée paramètres importants sur le matériel réseau, rechercher les paquets supprimés et suivre le flux de trafic entre les ordinateurs de votre réseau d’entreprise et Office 365. Étant donné que le corps réel du trafic est chiffré, c’est-à-dire qu’il se déplace sur le port 443 via SSL/TLS, vous ne pouvez pas lire les fichiers envoyés. Au lieu de cela, vous obtenez une trace non filtrée du chemin d’accès que le paquet prend, ce qui peut vous aider à identifier le comportement du problème.

Veillez à ne pas appliquer de filtre pour l’instant. Au lieu de cela, exécutez les étapes et illustrez le problème avant d’arrêter la trace et d’enregistrer.

Après avoir installé Netmon 3.4, ouvrez l’outil et effectuez les étapes suivantes :

Prendre une trace Netmon et reproduire le problème

1. Lancez Netmon 3.4. La page d’accueil comporte trois volets : Captures récentes, Sélectionner des réseaux et Prise en main avec Microsoft Network Monitor 3.4. Remarquez. Le panneau Sélectionner les réseaux vous donne également une liste des réseaux par défaut à partir desquels vous pouvez capturer. Assurez-vous que les cartes réseau sont sélectionnées ici.

2. Cliquez sur Nouvelle capture en haut de la page de démarrage . Cela ajoute un nouvel onglet en regard de l’onglet Page de démarrage appelé Capture 1.

3. Pour effectuer une capture simple, cliquez sur Démarrer dans la barre d’outils.

4. Reproduisez les étapes qui présentent un problème de performances.

5. Cliquez sur Arrêter l’enregistrement>du fichier>. N’oubliez pas de donner la date et l’heure avec le fuseau horaire et de mention si les performances sont mauvaises ou bonnes.

HTTPWatch

HTTPWatch est facturé et une édition gratuite. L’édition de base gratuite couvre tout ce dont vous avez besoin pour ce test. HTTPWatch surveille le trafic réseau et le temps de chargement des pages directement à partir de la fenêtre de votre navigateur. HTTPWatch est un plug-in de Microsoft Edge qui décrit graphiquement les performances. L’analyse peut être enregistrée et visualisée dans HTTPWatch Studio.

Remarque

Si vous utilisez un autre navigateur, tel que Firefox, Google Chrome, ou si vous ne pouvez pas installer HTTPWatch dans Edge, ouvrez une nouvelle fenêtre de navigateur et appuyez sur F12 sur votre clavier. La fenêtre contextuelle Outil de développement doit s’afficher en bas de votre navigateur. Si vous utilisez Opera, appuyez sur Ctrl+Maj+I pour Web Inspector, puis cliquez sur l’onglet Réseau et effectuez les tests décrits ci-dessous. Les informations seront légèrement différentes, mais les temps de chargement seront toujours affichés en millisecondes. > HTTPWatch est également très utile pour les problèmes liés aux temps de chargement des pages SharePoint.

Exécuter HTTPWatch et reproduire le problème

HTTPWatch étant un plug-in de navigateur, l’exposition de l’outil dans le navigateur est légèrement différente pour chaque version de Microsoft Edge. En règle générale, vous trouverez HTTPWatch sous la barre commandes du navigateur Microsoft Edge. Si vous ne voyez pas le plug-in HTTPWatch dans la fenêtre de votre navigateur, case activée la version de votre navigateur en cliquant sur Aide>à propos de, ou dans les versions ultérieures de Microsoft Edge, cliquez sur le symbole d’engrenage et à propos de Edge. Pour lancer la barre de commandes , cliquez avec le bouton droit sur la barre de menus dans Microsoft Edge, puis cliquez sur Barre de commandes.

Dans le passé, HTTPWatch a été associé aux barres Commandes et Explorer. Par conséquent, une fois l’installation effectuée, si vous ne voyez pas immédiatement l’icône (même après le redémarrage) case activée Outils et vos barres d’outils pour l’icône. N’oubliez pas que les barres d’outils peuvent être personnalisées et que des options peuvent y être ajoutées.

1. Lancez HTTPWatch dans une fenêtre de navigateur Microsoft Edge. Il apparaît ancré au navigateur en bas de cette fenêtre. Cliquez sur Enregistrer.

2. Reproduisez les étapes exactes impliquées dans le problème de performances. Cliquez sur le bouton Arrêter dans HTTPWatch.

3. Enregistrez l’objet HTTPWatch ou Send by Email. N’oubliez pas de nommer le fichier afin qu’il inclue des informations de date et d’heure et une indication indiquant si votre montre contient une démonstration de performances bonnes ou incorrectes.

Cette capture d’écran provient de la version Professionnel de HTTPWatch. Vous pouvez ouvrir les traces prises dans la version de base sur un ordinateur avec une version Professionnel et les lire. Des informations supplémentaires peuvent être disponibles à partir de la trace via cette méthode.

Enregistreur d’étapes de problème

L’enregistreur d’étapes, ou PSR.exe, vous permet d’enregistrer les problèmes au fur et à mesure qu’ils se produisent. Il s’agit d’un outil très utile et simple à exécuter.

Exécuter l’enregistreur d’étapes de problème (PSR.exe) pour enregistrer votre travail

1. Utilisez le type Démarrer>exécuter>PSR.exe>OK ou cliquez sur le type de clé> Windows PSR.exe> , puis appuyez sur Entrée.

2. Lorsque la petite fenêtre PSR.exe s’affiche, cliquez sur Démarrer l’enregistrement et reproduisez les étapes qui reproduisent le problème de performances. Vous pouvez ajouter des commentaires si nécessaire, en cliquant sur Ajouter des commentaires.

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

4. Cliquez sur Enregistrer.

La date et l’heure sont enregistrées pour vous. Cela lie votre PSR à votre trace Netmon et HTTPWatch dans le temps, et vous aide à résoudre les problèmes de précision. La date et l’heure dans l’enregistrement PSR peuvent indiquer qu’une minute s’est écoulée 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 d’enseigner tout ce qui concerne la résolution des problèmes de réseau et de performances que quelqu’un aurait besoin de connaître par le biais d’un article. L’obtention d’une bonne performance nécessite de l’expérience et une connaissance du fonctionnement et des performances de votre réseau. Mais il est possible d’arrondir une liste des principaux problèmes et de montrer comment les outils peuvent vous aider à éliminer les problèmes les plus courants.

Si vous souhaitez acquérir des compétences de lecture des traces réseau pour vos sites Office 365, il n’y a pas de meilleur enseignant que de créer des traces de chargements de pages régulièrement et d’acquérir de l’expérience en lecture. Par exemple, lorsque vous en avez la possibilité, chargez un service Office 365 et tracez le processus. Filtrez la trace pour le trafic DNS ou recherchez le nom du service que vous avez parcouru dans FrameData. Analysez la trace pour avoir une idée des étapes qui se produisent lors du chargement du service. Cela vous permet de savoir à quoi doit ressembler le chargement normal de la page et, dans le cas de la résolution des problèmes, en particulier en ce qui concerne les performances, la comparaison de bonnes et de mauvaises traces peut vous en apprendre beaucoup.

Netmon utilise Microsoft IntelliSense dans le champ Filtre d’affichage. IntelliSense, ou saisie semi-automatique intelligente du code, consiste à taper un point et à afficher toutes les options disponibles dans une zone de sélection déroulante. Par exemple, vous vous inquiétez de la mise à l’échelle des fenêtres TCP, vous pouvez trouver votre chemin vers un filtre (tel que .protocol.tcp.window < 100) par ce moyen.

Les traces Netmon peuvent contenir beaucoup de trafic. Si vous n’avez pas l’expérience de les lire, il est probable que vous serez submergé d’ouvrir la trace la première fois. La première chose à faire est de séparer le signal du bruit de fond dans la trace. Vous avez testé Office 365, et c’est le trafic que vous souhaitez voir. Si vous avez l’habitude de parcourir les traces, vous n’avez peut-être pas besoin de cette liste.

Le trafic entre votre client et Office 365 transite via TLS, ce qui signifie que le corps du trafic sera chiffré et non lisible dans une trace Netmon générique. Votre analyse des performances n’a pas besoin de connaître les spécificités des informations contenues dans le paquet. Il est cependant très intéressé par les en-têtes de paquets et les informations qu’ils contiennent.

Conseils pour obtenir une bonne trace

• Connaître la valeur de l’adresse IPv4 ou IPv6 de votre ordinateur client. Vous pouvez l’obtenir à partir de l’invite de commandes en tapant IPConfig , puis en appuyant sur Entrée. Le fait de connaître cette adresse vous permet de savoir en un coup d’œil si le trafic dans la trace implique directement votre ordinateur client. S’il existe un proxy connu, effectuez un test ping et obtenez également son adresse IP.

• Videz le cache de votre programme de résolution DNS et, si possible, fermez tous les navigateurs, à l’exception de celui dans lequel vous exécutez vos tests. Si vous n’êtes pas en mesure de le faire, par instance, si la prise en charge utilise un outil basé sur un navigateur pour voir le bureau de votre ordinateur client, préparez-vous à filtrer votre trace.

• Dans une trace occupée, recherchez le service Office 365 que vous utilisez. Si vous n’avez jamais vu ou rarement votre trafic auparavant, il s’agit d’une étape utile pour séparer le problème de performances des autres bruits réseau. Il existe plusieurs façons de procéder. Directement avant votre test, vous pouvez utiliser ping ou PsPing sur l’URL du service spécifique (ping outlook.office365.com ou psping -4 microsoft-my.sharepoint.com:443, par exemple). Vous pouvez également trouver facilement ce ping ou PsPing dans une trace Netmon (par son nom de processus). Cela vous donnera un endroit pour commencer à regarder.

Si vous utilisez uniquement le suivi Netmon au moment du problème, c’est également correct. Pour vous orienter, utilisez un filtre comme 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 Résumé du cadre jusqu’à droite et rechercher la colonne ID de conversation. Il y a un nombre indiqué pour l’ID de cette conversation spécifique que vous pouvez également enregistrer et examiner de manière isolée plus tard. N’oubliez pas de supprimer ce filtre avant d’appliquer tout autre filtrage.

Conseil

Netmon dispose d’un grand nombre de filtres intégrés utiles. Essayez le bouton Charger le filtre en haut du volet Afficher le filtre.

Familiarisez-vous avec votre trafic et apprenez à localiser les informations dont vous avez besoin. Par exemple, découvrez quel paquet de la trace a la première référence au service Office 365 que vous utilisez (comme « Outlook »).

En prenant Office 365 Outlook Online comme exemple, le trafic commence comme suit :

• Requête DNS standard et réponse DNS pour outlook.office365.com avec des ID de requête correspondants. Il est important de noter le décalage de temps pour ce tour et l’emplacement dans le monde où le Office 365 DNS global envoie la demande de résolution de noms. Idéalement, aussi localement que possible, plutôt qu’à mi-chemin à travers le monde.

• Requête HTTP GET dont le rapport status a été déplacé définitivement (301)

• Trafic RWS, y compris les requêtes RWS Connect et les réponses connect. (Il s’agit de Remote Winsock qui crée une connexion pour vous.)

• Une conversation TCP SYN et TCP SYN/ACK. De nombreux paramètres de cette conversation ont un impact sur vos performances.

• Ensuite, une série de trafic TLS :TLS, qui est l’endroit où les conversations de liaison TLS et de certificat TLS ont lieu. (N’oubliez pas que les données sont chiffrées via SSL/TLS.)

Toutes les parties du trafic sont importantes et connectées, mais de petites parties de la trace contiennent des informations importantes en termes de résolution des problèmes de performances. Nous allons donc nous concentrer sur ces domaines. En outre, étant donné que nous avons fait suffisamment de Office 365 résolution des problèmes de performances chez Microsoft pour compiler une liste top 10 des problèmes courants, nous allons nous concentrer sur ces problèmes et sur la façon d’utiliser les outils dont nous disposons pour les rooter ensuite.

Si vous ne les avez pas déjà installés, la matrice ci-dessous permet d’utiliser plusieurs outils lorsque cela est possible. Des liens sont fournis vers les points d’installation. La liste inclut des outils de suivi réseau courants tels que Netmon et Wireshark, mais utilisez n’importe quel outil de suivi qui vous convient et dans lequel vous êtes habitué à filtrer le trafic réseau. Lorsque vous effectuez des tests, n’oubliez pas :

• Fermez vos navigateurs et testez avec un seul navigateur en cours d’exécution : cela réduit le trafic global que vous capturez. Cela permet une trace moins occupée.
• Videz le cache de votre programme de résolution DNS sur l’ordinateur client : cela vous donnera une propre ardoise lorsque vous commencez à effectuer votre capture, pour une trace plus propre.

Problèmes courants

Quelques problèmes courants que vous pouvez rencontrer et comment les trouver dans votre trace réseau.

Mise à l’échelle TCP Windows

Trouvé dans syn - SYN/ACK. Le matériel hérité ou vieillissant peut ne pas tirer parti de la mise à l’échelle des fenêtres TCP. Sans les paramètres de mise à l’échelle des fenêtres TCP appropriés, la mémoire tampon 16 bits par défaut dans les en-têtes TCP se remplit en millisecondes. Le trafic ne peut pas continuer à envoyer tant que le client n’a pas reçu un accusé de réception des données d’origine, ce qui entraîne des retards.

Outils

• Netmon
• Wireshark

Ce qu’il faut rechercher

Recherchez le trafic SYN - SYN/ACK dans votre trace réseau. Dans Netmon, utilisez un filtre comme tcp.flags.syn == 1. Ce filtre est le même dans Wireshark.

Notez que pour chaque SYN, il existe un numéro de port source (SrcPort) qui correspond au port de destination (DstPort) de l’accusé de réception (SYN/ACK) associé.

Pour afficher la valeur de mise à l’échelle Windows utilisée par votre connexion réseau, développez d’abord syn, puis SYN/ACK associé.

Paramètres de temps d’inactivité TCP

Historiquement, la plupart des réseaux de périmètre sont configurés pour les connexions temporaires, ce qui signifie que les connexions inactives sont généralement terminées. Les sessions TCP inactives peuvent être arrêtées par des proxys et des pare-feu à plus de 100 à 300 secondes. Cela est problématique pour Outlook Online, car il crée et utilise des connexions à long terme, qu’elles soient inactives ou non.

Lorsque les connexions sont arrêtées par des périphériques de proxy ou de pare-feu, le client n’est pas informé et une tentative d’utilisation d’Outlook Online signifie qu’un ordinateur client essaiera, à plusieurs reprises, de rétablir la connexion avant d’en créer une nouvelle. Vous pouvez voir des blocages dans le produit, des invites ou des performances lentes lors du chargement de la page.

Outils

• Netmon
• Wireshark

Ce qu’il faut rechercher

Dans Netmon, examinez le champ Décalage de temps pour un aller-retour. Un aller-retour est le temps entre l’envoi d’une demande au serveur par le client et la réception d’une réponse. Vérifiez entre le client et le point de sortie (par exemple, Client -> Proxy) ou le client à Office 365 (Client --> Office 365). Vous pouvez le voir dans de nombreux types de paquets.

Par exemple, le filtre dans Netmon peut ressembler .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à .

Conseil

Vous ne savez pas si l’adresse IP de votre trace appartient à votre serveur DNS ? Essayez de le rechercher sur la ligne de commande. Cliquez sur Démarrer>exécuter> et tapez cmd, ou appuyez sur La touche> Windows et tapez cmd. À l’invite, tapez nslookup <the IP address from the network trace>. Pour tester, utilisez nslookup sur l’adresse IP de votre propre ordinateur. >Pour afficher la liste des plages d’adresses IP de Microsoft, consultez Office 365 URL et plages d’adresses IP.

En cas de problème, attendez-vous à ce que de longs décalages de temps apparaissent, 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 pouvez trouver des paquets de données d’application via .Protocol.TLS AND Description == "TLS:TLS Rec Layer-1 SSL Application Data"). Vous devriez voir une progression fluide dans le temps sur l’ensemble de la session. Si vous constatez de longs retards lors de l’actualisation de votre Outlook Online, cela peut être dû à un degré élevé de réinitialisations envoyées.

Latence/temps aller-retour

La latence est une mesure qui peut changer beaucoup en fonction de nombreuses variables, telles que la mise à niveau d’appareils vieillissants, l’ajout d’un grand nombre d’utilisateurs à un réseau et le pourcentage de bande passante globale consommée par d’autres tâches sur une connexion réseau.

Il existe des calculatrices de bande passante pour Office 365 disponibles à partir de cette page Planification réseau et réglage des performances pour Office 365 page.

Vous avez besoin de mesurer la vitesse de votre connexion ou la bande passante de votre connexion ISP ? Essayez ce site (ou des sites comme celui-ci) : Site officiel Speedtest, ou interrogez votre moteur de recherche favori pour le test de vitesse d’expression.

Outils

• Ping
• PsPing
• Netmon
• Wireshark

Ce qu’il faut rechercher

Pour suivre la latence dans une trace, vous bénéficiez de l’enregistrement de l’adresse IP de l’ordinateur client et de l’adresse IP du serveur DNS dans Office 365. Cela permet de faciliter le filtrage des traces. Si vous vous connectez via un proxy, vous aurez besoin de l’adresse IP de votre ordinateur client, de l’adresse IP du proxy/de sortie et de l’adresse IP DNS Office 365, pour faciliter le travail.

Une demande ping envoyée à outlook.office365.com vous indique le nom du centre de données qui reçoit la demande, même si ping peut ne pas être en mesure de se connecter pour envoyer les paquets ICMP consécutifs de marque commerciale. Si vous utilisez PsPing (un outil gratuit pour le téléchargement) et spécifique au port (443) et peut-être pour utiliser IPv4 (-4), vous obtiendrez un temps d’aller-retour moyen pour les paquets envoyés. Cela fonctionne pour d’autres URL dans les services Office 365, comme psping -4 yourSite.sharepoint.com:443. En fait, vous pouvez spécifier un certain nombre de pings pour obtenir un échantillon plus grand pour votre moyenne, essayez quelque chose comme 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 sorte que vous pouvez utiliser celui que vous connaissez pour être ouvert. Dans Office 365, qui utilise SSL/TLS, essayez d’attacher le port :443 à votre PsPing.

Si vous avez chargé la page de Office 365 lente tout en effectuant une trace réseau, vous devez filtrer une trace Netmon ou Wireshark pour DNS. C’est l’une des adresses IP que nous recherchons.

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

1. Effectuez un test ping sur l’URL ping outlook.office365.com et, dans les résultats, enregistrez le nom et l’adresse IP du serveur DNS auquel la requête ping a été envoyée.
2. Trace réseau ouvrant la page, ou effectuant l’action qui vous donne le problème de performances, ou, si vous voyez une latence élevée sur le ping, lui-même, tracez-la sur le réseau.
3. Ouvrez la trace dans Netmon et filtrez dns (ce filtre fonctionne également dans Wireshark, mais est sensible à la casse -- dns). Étant donné que vous connaissez le nom du serveur DNS à partir de votre ping, vous pouvez également filtrer plus rapidement dans Netmon comme suit : DNS AND ContainsBin(FrameData, ASCII, "namnorthwest"), qui ressemble à ceci dans Wireshark dns et frame contient « namnorthwest ».
   Ouvrez le paquet de réponse et, dans la fenêtre Détails de l’image netmon, cliquez sur DNS pour développer pour plus d’informations. Dans les informations DNS, vous trouverez l’adresse IP du serveur DNS auquel la requête a été envoyée dans Office 365. Vous aurez besoin de cette adresse IP pour l’étape suivante (l’outil PsPing). Supprimez le filtre, cliquez avec le bouton droit sur la réponse DNS dans Netmon (DNS De synthèse> desconversations>) pour afficher la requête ET la réponse DNS côte à côte.
4. Dans Netmon, notez également la colonne Décalage de temps entre la requête et la réponse DNS. Dans l’étape suivante, l’outil PsPing facile à installer et à utiliser est très pratique, à la fois parce que ICMP est souvent bloqué sur les pare-feu et parce que PsPing effectue un suivi élégant de la latence en millisecondes. PsPing termine une connexion TCP à une adresse et à un port (dans notre cas, ouvrez le port 443).
5. Installez PsPing.
6. Ouvrez une invite de commandes (Démarrer > le type d’exécution > cmd ou clé Windows > type cmd) et accédez au répertoire où 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 de C. Vous pouvez faire de même pour un accès rapide.
7. Tapez la commande afin d’effectuer votre PsPing par rapport à l’adresse IP du serveur DNS Office 365 de votre trace Netmon précédente, y compris le numéro de port, comme psping -n 20 132.245.24.82:445. Cela vous donne un échantillonnage de 20 pings et la latence moyenne lorsque PsPing s’arrête.

Si vous envisagez de Office 365 via un serveur proxy, les étapes sont légèrement différentes. Tout d’abord, psPing sur votre serveur proxy pour obtenir une valeur de latence moyenne en millisecondes vers le proxy/sortie et retour, puis exécutez PsPing sur le proxy ou sur un ordinateur disposant d’une connexion Internet directe pour obtenir la valeur manquante (celle à Office 365 et arrière).

Si vous choisissez d’exécuter PsPing à partir du proxy, vous aurez deux valeurs en millisecondes : ordinateur client vers serveur proxy ou point de sortie, et serveur proxy pour Office 365. Et vous avez terminé ! En tout cas, en enregistrant des valeurs.

Si vous exécutez PsPing sur un autre ordinateur client disposant d’une connexion directe à Internet, c’est-à-dire sans proxy, vous aurez deux valeurs en millisecondes : Ordinateur client vers serveur proxy ou point de sortie, et ordinateur client pour Office 365. Dans ce cas, soustrayez la valeur de l’ordinateur client au serveur proxy ou au point de sortie de la valeur de l’ordinateur client à Office 365, et vous aurez les numéros RTT de votre ordinateur client vers le serveur proxy ou le point de sortie, et du serveur proxy ou du point de sortie à Office 365.

Toutefois, si vous trouvez un ordinateur client à l’emplacement concerné qui est directement connecté ou contourne le proxy, vous pouvez choisir de voir si le problème s’y reproduit pour commencer et de l’utiliser par la suite.

Latence, comme indiqué dans une trace Netmon, ces millisecondes supplémentaires peuvent s’additionner, si elles sont suffisantes dans une session donnée.

Remarque

Votre adresse IP peut être différente des adresses IP indiquées ici, par exemple, votre ping peut renvoyer quelque chose comme 157.56.0.0/16 ou une plage similaire. Pour obtenir la liste des plages utilisées par Office 365, case activée les URL Office 365 et les plages d’adresses IP.

N’oubliez pas de développer tous les nœuds (il y a un bouton en haut pour cela) si vous souhaitez rechercher, par exemple, 132.245.

Authentification du proxy

Cela s’applique uniquement à vous si vous passez par un serveur proxy. Si ce n’est pas le cas, vous pouvez ignorer ces étapes. Lorsque vous fonctionnez correctement, l’authentification proxy doit avoir lieu en millisecondes, de manière cohérente. Vous ne devez pas voir de mauvaises performances intermittentes pendant les périodes d’utilisation maximale (par exemple).

Si l’authentification par proxy est activée, chaque fois que vous créez une nouvelle connexion TCP à Office 365 pour obtenir des informations, vous devez passer par un processus d’authentification en arrière-plan. Par exemple, lorsque vous passez du calendrier au courrier dans Outlook Online, vous vous authentifiez. Et dans SharePoint, si une page affiche des médias ou des données provenant de plusieurs sites ou emplacements, vous vous authentifiez pour chaque connexion TCP différente nécessaire pour afficher les données.

Dans Outlook Online, vous pouvez rencontrer des temps de chargement lents chaque fois que vous basculez entre le calendrier et votre boîte aux lettres, ou des chargements de pages lents dans SharePoint. Toutefois, d’autres symptômes ne sont pas répertoriés ici.

L’authentification proxy est un paramètre sur votre serveur proxy de sortie. Si cela provoque un problème de performances avec Office 365, vous devez consulter votre équipe de mise en réseau.

Outils

• Netmon
• Wireshark

Ce qu’il faut rechercher

L’authentification par proxy a lieu chaque fois qu’une nouvelle session TCP doit être lancée, généralement pour demander des fichiers ou des informations au serveur, ou pour fournir des informations. Par exemple, vous pouvez voir l’authentification proxy autour des requêtes HTTP GET ou HTTP POST. Si vous souhaitez voir les cadres dans lesquels vous authentifiez les demandes dans votre trace, ajoutez la colonne « Résumé NTLMSSP » à Netmon et filtrez .property.NTLMSSPSummarypour . Pour voir la durée de l’authentification, ajoutez la colonne Delta de temps.

Pour ajouter une colonne à Netmon :

1. Cliquez avec le bouton droit sur une colonne telle que Description.
2. Cliquez sur Choisir des colonnes.
3. Recherchez NTLMSSP Summary et Time Delta dans la liste, puis cliquez sur Ajouter.
4. Placez les nouvelles colonnes avant ou derrière la colonne Description afin de pouvoir les lire côte à côte.
5. Cliquez sur OK.

Même si vous n’ajoutez pas la colonne, le filtre Netmon fonctionne. Toutefois, votre résolution des problèmes sera beaucoup plus facile si vous pouvez voir l’étape de l’authentification dans laquelle vous vous trouvez.

Lorsque vous recherchez des instances d’authentification proxy, veillez à étudier tous les cadres où il existe un défi NTLM ou un message d’authentification. Si nécessaire, cliquez avec le bouton droit sur la partie spécifique du trafic et Recherchez les conversations > TCP. Tenez compte des valeurs Time Delta dans ces conversations.

Un délai de quatre secondes dans l’authentification du proxy, comme indiqué dans Wireshark. Le delta de temps par rapport à la colonne frame affichée précédente a été effectué en cliquant avec le bouton droit sur le champ du même nom dans les détails du cadre et en sélectionnant Ajouter en tant que colonne.

Performances DNS

La résolution de noms fonctionne de manière optimale et plus rapide lorsqu’elle se produit le plus près possible du pays/de la région du client.

Si la résolution de noms DNS a lieu à l’étranger, elle peut ajouter des secondes aux chargements de pages. Dans l’idéal, la résolution de noms se produit en moins de 100 ms. Si ce n’est pas le cas, vous devez effectuer une enquête plus approfondie.

Conseil

Vous ne savez pas comment la connectivité cliente fonctionne dans Office 365 ? Consultez le document de référence sur la connectivité du client ici.

Outils

• Netmon
• Wireshark
• PsPing

Ce qu’il faut rechercher

L’analyse des performances DNS est généralement une autre tâche pour une trace réseau. Toutefois, PsPing est également utile pour résoudre ou exclure une cause possible.

Le trafic DNS est basé sur les requêtes TCP et UDP, et les réponses sont clairement marquées avec un ID qui permet de faire correspondre une requête spécifique à sa réponse spécifique. Le trafic DNS s’affiche lorsque, par exemple, SharePoint utilise un nom réseau ou une URL sur une page web. En règle générale, la majeure partie de ce trafic, sauf lors du transfert de Zones, s’exécute sur UDP.

Dans Netmon et Wireshark, le filtre le plus simple qui vous permet d’examiner le trafic DNS est simplement dns. Veillez à utiliser la minuscule lorsque vous spécifiez le filtre. N’oubliez pas de vider le cache de votre programme de résolution DNS avant de commencer à reproduire le problème sur votre ordinateur client. Par exemple, si vous avez un chargement de page SharePoint lent pour la page d’accueil, vous devez fermer tous les navigateurs, ouvrir un nouveau navigateur, démarrer le suivi, vider le cache de votre programme de résolution DNS et accéder à votre site SharePoint. Une fois la page entière résolue, vous devez arrêter et enregistrer la trace.

Vous souhaitez examiner le décalage d’heure ici. Et il peut être utile d’ajouter la colonne Delta de temps à Netmon, ce que vous pouvez faire en effectuant les étapes suivantes :

1. Cliquez avec le bouton droit sur une colonne telle que Description.
2. Cliquez sur Choisir des colonnes.
3. Recherchez Time Delta dans la liste, puis cliquez sur Ajouter.
4. Placez la nouvelle colonne avant ou derrière la colonne Description afin de pouvoir les lire côte à côte.
5. Cliquez sur OK.

Si vous trouvez une requête qui vous intéresse, envisagez de l’isoler en cliquant avec le bouton droit sur cette requête dans le panneau détails du cadre, en choisissant Dns Rechercher les conversations>. Notez que le panneau Conversations réseau passe directement à la conversation spécifique dans son journal du trafic UDP.

Dans Wireshark, vous pouvez créer une colonne pour l’heure DNS. Prenez votre trace (ou ouvrez une trace) dans Wireshark et filtrez par dns, ou, plus utilement, dns.time. Cliquez sur une requête DNS, puis, dans le panneau affichant les détails, développez les Domain Name System (response) détails. Vous verrez un champ pour le temps (par exemple, [Time: 0.001111100 seconds]. Cliquez avec le bouton droit sur cette fois et sélectionnez Appliquer en tant que colonne. Cela vous donne une colonne Time pour un tri plus rapide de votre trace. Cliquez sur la nouvelle colonne pour trier les valeurs décroissantes pour voir quel appel DNS a pris le plus de temps à résoudre.

Une navigation de SharePoint filtrée dans Wireshark par dns.time (en minuscules), avec l’heure des détails dans une colonne et triée par ordre croissant.

Si vous souhaitez examiner plus en détail le temps de résolution DNS, essayez un PsPing sur le port DNS utilisé par TCP (par exemple, psping <IP address of DNS server>:53). Rencontrez-vous toujours un problème de performances ? Si c’est le cas, le problème est plus susceptible d’être un problème de réseau plus large qu’un problème de l’application DNS spécifique que vous rencontrez pour la résolution. Il convient également de mentionner, là encore, qu’un test ping pour outlook.office365.com vous indiquera où la résolution de noms DNS pour Outlook Online a lieu (par exemple, outlook-namnorthwest.office365.com).

Si le problème semble spécifique à DNS, il peut être nécessaire de contacter votre service informatique pour examiner les configurations DNS et les redirecteurs DNS afin d’examiner plus en détail ce problème.

Scalabilité du proxy

Des services tels qu’Outlook Online dans Office 365 accordent aux clients plusieurs connexions à long terme. Par conséquent, chaque utilisateur peut utiliser davantage de connexions qui nécessitent une durée de vie plus longue.

Outils

Mathématiques

Ce qu’il faut rechercher

Il n’existe pas de trace réseau ou d’outil de résolution des problèmes spécifiques à ce problème. Au lieu de cela, il est basé sur les calculs de bande passante en fonction des limitations et d’autres variables.

Taille maximale du segment TCP

Trouvé dans syn - SYN/ACK. Effectuez cette case activée dans n’importe quelle trace réseau de performances que vous avez effectuée pour vous assurer que les paquets TCP sont configurés pour transporter le maximum de données possible.

L’objectif est de voir un MSS de 1 460 octets pour la transmission des données. Si vous êtes derrière un proxy ou que vous utilisez un NAT, n’oubliez pas d’exécuter ce test du client au proxy/sortie/NAT, et à partir du proxy/sortie/NAT vers Office 365 pour obtenir de meilleurs résultats ! Il s’agit de sessions TCP différentes.

Outils

Netmon

Ce qu’il faut rechercher

La taille maximale du segment TCP (MSS) est un autre paramètre de l’établissement d’une liaison triple dans votre trace réseau, ce qui signifie que vous trouverez les données dont vous avez besoin dans le paquet SYN - SYN/ACK. MSS est assez simple à voir.

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

Remarque

Si vous examinez une trace et que vous avez besoin de trouver le trafic pertinent pour votre conversation, filtrez par l’adresse IP du client, l’adresse IP du serveur proxy ou du point de sortie, ou les deux. En accédant directement, vous devez effectuer un test ping sur l’URL que vous testez pour l’adresse IP de Office 365 dans la trace et filtrer par celle-ci.

Vous regardez la trace d’occasion ? Essayez d’utiliser des filtres pour vous orienter. Dans Netmon, exécutez une recherche basée sur l’URL, par Containsbin(framedata, ascii, "sphybridExample")exemple , notez le numéro de cadre.

Dans Wireshark, utilisez quelque chose comme frame contains "sphybridExample". Si vous remarquez que vous avez trouvé le trafic Winsock distant (RWS) (il peut apparaître sous la forme d’un [PSH, ACK] dans Wireshark), n’oubliez pas que les connexions RWS sont visibles peu de temps avant les clés SYN - SYN/ACK pertinentes, comme indiqué précédemment.

À ce stade, vous pouvez enregistrer le numéro d’image, supprimer le filtre et cliquer sur Tout le trafic dans la fenêtre Conversations réseau de Netmon pour examiner le SYN le plus proche.

Plus important encore, si vous n’avez reçu aucune des informations d’adresse IP au moment de la trace, la recherche de votre URL dans la trace (partie de sphybridExample-my.sharepoint.com, par exemple), vous donnera des adresses IP par lesquelles filtrer.

Recherchez la connexion dans la trace qui vous intéresse. Vous pouvez le faire en analysant la trace, en filtrant par adresses IP ou en sélectionnant des ID de conversation spécifiques à l’aide de la fenêtre Conversations réseau dans Netmon. Une fois que vous avez trouvé le paquet SYN, développez TCP (dans Netmon) ou Protocole de contrôle de transmission (dans Wireshark) dans le panneau Détails du cadre. Développez Options TCP et MaxSegmentSize. Recherchez le cadre SYN-ACK associé et développez les options TCP et MaxSegmentSize. La plus petite des deux valeurs sera votre Taille maximale de segment. Dans cette image, j’utilise la colonne intégrée dans Netmon appelée Résolution des problèmes TCP.

La colonne intégrée se trouve en haut du panneau Détails du cadre . (Pour revenir à votre affichage normal, cliquez à nouveau sur Colonnes , puis choisissez Fuseau horaire.)

Voici une trace filtrée dans Wireshark. Il existe un filtre spécifique à la valeur MSS (tcp.options.mss). Les trames d’une liaison SYN, SYN/ACK et ACK sont liées au bas du Wireshark équivalent à Frame Details (donc frame 47 ACK, liens vers 46 SYN/ACK, liens vers 43 SYN) pour faciliter ce type de travail.

Si vous devez case activée Accusé de réception sélectif (rubrique suivante dans cette matrice), ne fermez pas votre trace !

Accusé de réception sélectif

Trouvé dans syn - SYN/ACK. Doit être signalé comme autorisé dans SYN et SYN/ACK. L’accusé de réception sélectif (SACK) permet une retransmission plus fluide des données lorsqu’un paquet ou des paquets sont manquants. Les appareils peuvent désactiver cette fonctionnalité, ce qui peut entraîner des problèmes de performances.

Si vous êtes derrière un proxy ou que vous utilisez un NAT, n’oubliez pas d’exécuter ce test du client au proxy/sortie/NAT, et à partir du proxy/sortie/NAT vers Office 365 pour obtenir de meilleurs résultats ! Il s’agit de sessions TCP différentes.

Outils

Netmon

Ce qu’il faut rechercher

L’accusé de réception sélectif (SACK) est un autre paramètre de l’établissement d’une liaison SYN-SYN/ACK. Vous pouvez filtrer votre trace pour SYN - SYN/ACK de plusieurs façons.

Localisez la connexion dans la trace que vous souhaitez voir en analysant la trace, en filtrant par adresses IP ou en cliquant sur un ID de conversation à l’aide de la fenêtre Conversations réseau dans Netmon. Une fois que vous avez trouvé le paquet SYN, développez TCP dans Netmon ou Protocole de contrôle de transmission dans Wireshark dans la section Détails du cadre. Développez Options TCP, puis SACK. Recherchez le cadre SYN-ACK associé et développez les options TCP et son champ SACK. Assurez-vous que SACK est autorisé dans SYN et SYN/ACK. Voici les valeurs SACK telles qu’elles sont affichées dans Netmon et Wireshark.

Géolocalisation DNS

L’endroit où Office 365 tente de résoudre votre appel DNS affecte la vitesse de connexion.

Dans Outlook Online, une fois la première recherche DNS terminée, l’emplacement de ce DNS sera utilisé pour se connecter à 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 (dC) où vos données sont stockées. C’est plus rapide.

Lors de l’accès à SharePoint, un utilisateur voyageant à l’étranger est dirigé vers son centre de données actif , c’est-à-dire le dC dont l’emplacement est basé sur la base d’accueil de son locataire SPO (donc, un dC aux États-Unis si l’utilisateur est basé sur les États-Unis).

Lync Online a des nœuds actifs dans plusieurs dC à la fois. Lorsque des demandes sont envoyées pour des instances lync online, le DNS de Microsoft détermine d’où provient la demande dans le monde et retourne les adresses IP à partir du dC régional le plus proche où Lync online est actif.

Conseil

Vous avez besoin d’en savoir plus sur la façon dont les clients se connectent à Office 365 ? Consultez l’article de référence Connectivité du client (et ses graphiques utiles).

Outils

• Ping
• PsPing

Ce qu’il faut rechercher

Les demandes de résolution de noms des serveurs DNS du client vers les serveurs DNS de Microsoft doivent, dans la plupart des cas, entraîner le renvoi de l’adresse IP d’un centre de données régional (dC). Qu’est-ce que cela signifie pour vous ? Si votre siège social se trouve à Bengaluru, en Inde, mais que vous voyagez dans le États-Unis, lorsque votre navigateur effectue une demande pour Outlook Online, les serveurs DNS de Microsoft doivent vous remettre les adresses IP aux centres de données du États-Unis, un centre de données régional. Si le courrier est nécessaire à partir d’Outlook, ces données sont acheminées sur le 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 aussi près que possible de l’emplacement de l’utilisateur. Si vous êtes en Europe, vous souhaitez accéder à un DNS Microsoft en Europe, et (idéalement) traiter avec un centre de données en Europe. Les performances d’un client en Europe qui passe au DNS et à un centre de données en Amérique seront plus lentes.

Exécutez l’outil Ping sur outlook.office365.com pour déterminer où votre requête DNS est acheminée. Si vous êtes en Europe, vous devriez voir une réponse de quelque chose comme outlook-emeawest.office365.com. Dans les Amériques, attendez-vous à quelque chose comme outlook-namnorthwest.office365.com.

Ouvrez l’invite de commandes sur l’ordinateur client (via Démarrer > l’exécution > cmd ou le type de clé > Windows cmd). Tapez ping outlook.office365.com, puis appuyez sur Entrée. N’oubliez pas de spécifier -4 si vous souhaitez spécifier pour effectuer un test ping via IPv4. Vous pouvez ne pas obtenir de réponse à partir des paquets ICMP, mais vous devez voir le nom du DNS vers lequel la requête a été acheminée. Si vous souhaitez voir les numéros de latence pour cette connexion, essayez PsPing à l’adresse IP du serveur qui est retournée par ping.

Résolution des problèmes d’application Office 365

Outils

• Netmon
• HTTPWatch
• Console F12 dans le navigateur

Nous ne couvrons pas les outils utilisés dans la résolution des problèmes spécifiques à l’application dans cet article spécifique au réseau. Mais vous trouverez des ressources que vous pouvez utiliser sur cette page.

Articles connexes

Gestion des points de terminaison Office 365

Points de terminaison Office 365 - FAQ