Optimisation des performances d’Office 365 à l’aide de lignes de référence et de l’historique des performances
Il existe des méthodes simples pour case activée les performances de connexion entre Office 365 et votre entreprise, ce qui vous permet d’établir une base de référence approximative de votre connectivité. Connaître l’historique des performances de vos connexions d’ordinateur client peut vous aider à détecter tôt les problèmes émergents, à identifier et à prédire les problèmes.
Si vous n’êtes pas habitué à travailler sur les problèmes de performances, cet article est conçu pour vous aider à prendre en compte certaines questions courantes. Comment savez-vous que le problème que vous rencontrez est un problème de performances et non un incident de service Office 365 ? Comment pouvez-vous planifier de bonnes performances à long terme ? Comment pouvez-vous garder un œil sur les performances ? Si votre équipe ou vos clients constatent des performances lentes lors de l’utilisation de Office 365 et que vous vous posez des questions sur l’une de ces questions, lisez la suite.
Importante
Vous rencontrez actuellement un problème de performances entre votre client et Office 365 ? Suivez les étapes décrites dans le plan de résolution des problèmes de performances pour Office 365.
Quelque chose que vous devez savoir sur les performances Office 365
Office 365 vit à l’intérieur d’un réseau Microsoft dédié à haute capacité qui est surveillé par l’automatisation et des personnes réelles. Une partie de la maintenance du cloud Office 365 consiste à optimiser les performances et à simplifier si possible. Étant donné que les clients du cloud Office 365 doivent se connecter via Internet, il y a également des efforts continus pour optimiser les performances sur Office 365 services.
Les améliorations des performances ne s’arrêtent jamais vraiment dans le cloud, de sorte qu’il n’y a pas non plus d’expérience avec le maintien du cloud sain et rapide. Si vous rencontrez un problème de performances lors de la connexion de votre emplacement à Office 365, il est préférable de ne pas commencer par ou d’attendre un cas de support. Au lieu de cela, vous devez commencer à examiner le problème de l’intérieur vers l’extérieur. Autrement dit, commencez à l’intérieur de votre réseau et travaillez sur votre chemin pour Office 365. Avant d’ouvrir un cas avec le support technique, vous pouvez collecter des données et prendre des mesures qui explorent et peuvent résoudre le problème.
Importante
Tenez compte de la planification de la capacité et des limites dans Office 365. Ces informations vous donneront une longueur d’avance lorsque vous tentez de résoudre un problème de performances. Voici un lien vers les descriptions des services Microsoft 365 et Office 365. Il s’agit d’un hub central, et tous les services offerts par Office 365 ont un lien qui accède à leurs propres descriptions de service à partir d’ici. Cela signifie que si vous avez besoin de voir les limites standard pour SharePoint, par exemple, vous devez cliquer sur Description du service SharePoint et rechercher sa section Limites SharePoint.
Assurez-vous d’entrer dans votre résolution des problèmes en comprenant que les performances sont une échelle glissante. Il ne s’agit pas d’atteindre une valeur idéalisée et de la maintenir en permanence. Les tâches occasionnelles à bande passante élevée, telles que l’intégration d’un grand nombre d’utilisateurs ou l’exécution de migrations de données volumineuses, seront stressantes, alors planifiez les impacts sur les performances. Vous devez avoir une idée approximative de vos objectifs de performances, mais de nombreuses variables jouent un rôle dans les performances, de sorte que les performances varient.
La résolution des problèmes de performances ne concerne pas l’atteinte d’objectifs spécifiques et la conservation indéfinie de ces nombres, mais l’amélioration des activités existantes, compte tenu de toutes les variables.
À quoi ressemble un problème de performances ?
Tout d’abord, vous devez vous assurer que ce que vous rencontrez est bien un problème de performances et non un incident de service. Un problème de performances est différent d’un incident de service dans Office 365. Voici comment les distinguer.
Les incidents de service se produisent lorsque le service Office 365 lui-même rencontre des problèmes. Vous pouvez voir des icônes rouges ou jaunes sous Intégrité actuelle dans le Centre d'administration Microsoft 365. Vous remarquerez peut-être que les performances sur les ordinateurs clients qui se connectent à Office 365 sont lentes. Par exemple, si l’intégrité actuelle signale une icône rouge et que vous voyez Examen en regard d’Exchange, vous pouvez également recevoir des appels de personnes de votre organization qui se plaignent que les boîtes aux lettres clientes utilisant Exchange Online sont lentes. Dans ce cas, il est raisonnable de supposer que votre performance Exchange Online a été victime de problèmes de service.
À ce stade, vous, l’administrateur Office 365, devez case activée Intégrité actuelle, puis afficher les détails et l’historique, souvent, pour vous tenir informé de la maintenance sur le système. Le tableau de bord Intégrité actuelle a été créé pour vous mettre à jour sur les modifications apportées au service et les problèmes rencontrés. Les notes et explications écrites dans l’historique d’intégrité, administrateur à administrateur, sont là pour vous aider à évaluer et à vous tenir au courant du travail en cours.
Un problème de performances n’est pas un incident de service, même si les incidents peuvent entraîner un ralentissement des performances. Un problème de performances ressemble à ceci :
Un problème de performances se produit, quel que soit le rapport de l’intégrité actuelle du service dans le centre d’administration.
Un comportement qui était utilisé pour le flux prend beaucoup de temps ou ne se termine jamais.
Vous pouvez également répliquer le problème ou le savoir si vous effectuez la série d’étapes appropriée.
Si le problème est intermittent, il peut toujours y avoir un modèle. Par exemple, vous savez que vers 10h00, vous aurez des appels d’utilisateurs qui ne peuvent pas toujours accéder à Office 365. Les appels se termineront vers midi.
Cette liste semble probablement familière ; peut-être trop familier. Une fois que vous savez qu’il s’agit d’un problème de performances, la question se pose : « Que faites-vous ensuite ? » Le reste de cet article vous aide à déterminer exactement cela.
Comment définir et tester le problème de performances
Les problèmes de performances apparaissent souvent au fil du temps, il peut être difficile de définir le problème réel. Create une bonne déclaration de problème avec une bonne idée du contexte du problème, puis vous devez effectuer des étapes de test reproductibles. Voici quelques exemples d’instructions de problèmes qui ne fournissent pas suffisamment d’informations :
Passer de ma boîte de réception à mon calendrier était quelque chose que je n’ai pas remarqué, et maintenant c’est une pause-café. Pouvez-vous le faire agir comme avant ?
Le chargement de mes fichiers sur SharePoint prend une éternité. Pourquoi est-il lent dans l’après-midi, mais n’importe quel autre moment, c’est rapide ? Ça ne peut pas être rapide ?
Les énoncés de problèmes ci-dessus posent plusieurs défis importants. Plus précisément, trop d’ambiguïtés à traiter. Par exemple :
Il n’est pas clair comment le basculement entre la boîte de réception et le calendrier a utilisé pour agir sur l’ordinateur portable.
Quand l’utilisateur dit : « Ne peut-il pas être rapide », qu’est-ce qui est « rapide » ?
Combien de temps est « pour toujours » ? C’est quelques secondes ? Ou plusieurs minutes ? Ou l’utilisateur pourrait-il déjeuner et l’action se terminerait 10 minutes après son retour ?
L’administrateur et l’utilitaire de résolution des problèmes ne peuvent pas connaître les détails du problème à partir d’instructions générales comme celles-ci. Par exemple, ils ne savent pas quand le problème a commencé à se produire. L’utilitaire de résolution des problèmes peut ne pas savoir que l’utilisateur travaille à domicile et ne voit que le basculement lent sur son réseau domestique. Ou que l’utilisateur exécute d’autres applications gourmandes en RAM sur le client local. Les administrateurs peuvent ne pas savoir que l’utilisateur exécute un système d’exploitation plus ancien ou qu’il n’a pas exécuté les mises à jour récentes.
Lorsque les utilisateurs signalent un problème de performances, il y a beaucoup d’informations à collecter. L’obtention et l’enregistrement d’informations s’appellent l’étendue du problème. Voici une liste d’étendue de base que vous pouvez utiliser pour collecter des informations sur les problèmes de performances. Cette liste n’est pas exhaustive, mais il s’agit d’un point de départ :
À quelle date le problème s’est-il produit et à quelle heure du jour ou de la nuit ?
Quel type d’ordinateur client utilisiez-vous et comment se connecte-t-il au réseau d’entreprise (VPN, câblé, sans fil) ?
Vous travailliez à distance ou étiez-vous au bureau ?
Avez-vous essayé les mêmes actions sur un autre ordinateur et avez-vous vu le même comportement ?
Suivez les étapes qui vous donnent des problèmes afin de pouvoir écrire les actions que vous effectuez.
Les performances sont-elles lentes en secondes ou en minutes ?
Où êtes-vous dans le monde ?
Certaines de ces questions sont plus évidentes que d’autres. La plupart des personnes comprennent qu’un utilitaire de résolution des problèmes a besoin des étapes exactes pour reproduire le problème. Après tout, comment pouvez-vous enregistrer ce qui ne va pas et comment tester si le problème est résolu ? Les éléments comme « Quelle date et heure avez-vous vu le problème ? » et « Où se trouvez-vous dans le monde ? », des informations qui peuvent être utilisées en tandem sont moins évidentes. Selon le moment où l’utilisateur travaillait, quelques heures de temps peuvent signifier que la maintenance est déjà en cours sur certaines parties du réseau de votre entreprise. Par instance, votre entreprise dispose d’une implémentation hybride, telle qu’une Recherche SharePoint hybride, qui peut interroger des index de recherche dans SharePoint dans Microsoft 365 et un sharePoint Server 2013 local instance, des mises à jour peuvent être en cours dans la batterie de serveurs locale. Si votre entreprise est dans le cloud, la maintenance du système peut inclure l’ajout ou la suppression de matériel réseau, le déploiement de mises à jour à l’échelle de l’entreprise ou l’apport de modifications à DNS ou à une autre infrastructure de base.
Lorsque vous résolvez un problème de performances, c’est un peu comme une scène de crime, vous devez être précis et attentif pour tirer des conclusions de la preuve. Pour ce faire, vous devez obtenir une bonne déclaration de problème en recueillant des preuves. Il doit inclure le contexte de l’ordinateur, le contexte de l’utilisateur, le moment où le problème a commencé et les étapes exactes qui ont exposé le problème de performances. Cette instruction de problème doit être, et rester, la page la plus en haut de vos notes. En parcourant à nouveau l’instruction du problème après avoir travaillé sur la résolution, vous effectuez les étapes pour tester et prouver si les actions que vous effectuez ont résolu le problème. Cela est essentiel pour savoir quand votre travail, là, est terminé.
Savez-vous à quoi les performances s’affichent quand elles étaient bonnes ?
Si tu es malchanceux, personne ne le sait. Personne n’avait de chiffres. Cela signifie que personne ne peut répondre à la simple question « Combien de secondes a-t-il fallu pour afficher une boîte de réception dans Office 365 ? » ou « Combien de temps a-t-il fallu pour que les dirigeants tiennent une réunion Lync Online ? », ce qui est un scénario courant pour de nombreuses entreprises.
Il manque ici une base de référence des performances.
Les bases de référence vous donnent un contexte pour vos performances. Vous devez prendre une ligne de base de temps en temps pour fréquemment, en fonction des besoins de votre entreprise. Si vous êtes une grande entreprise, votre équipe des opérations peut déjà prendre des bases de référence pour votre environnement local. Par exemple, si vous corrigez tous les serveurs Exchange le premier lundi du mois et tous vos serveurs SharePoint le troisième lundi, votre équipe des opérations dispose probablement d’une liste de tâches et de scénarios qu’elle exécute après la mise à jour corrective pour prouver que les fonctions critiques sont opérationnelles. Par exemple, ouvrez la boîte de réception, cliquez sur Envoyer/Recevoir et assurez-vous que les dossiers sont mis à jour ou, dans SharePoint, parcourez la page main du site, accédez à la page Recherche d’entreprise et effectuez une recherche qui retourne des résultats.
Si vos applications sont en Office 365, certaines des bases de référence les plus fondamentales que vous pouvez prendre mesurent le temps (en millisecondes) d’un ordinateur client à l’intérieur de votre réseau, jusqu’à un point de sortie, ou le point où vous quittez votre réseau et sortez pour Office 365. Voici quelques bases de référence utiles que vous pouvez examiner et enregistrer :
Identifiez les appareils entre votre ordinateur client et votre point de sortie, par exemple, votre serveur proxy.
Vous devez connaître vos appareils afin d’avoir un contexte (adresses IP, type d’appareil, etc.) pour les problèmes de performances qui surviennent.
Les serveurs proxy étant des points de sortie courants, vous pouvez case activée votre navigateur web pour voir quel serveur proxy il est configuré pour utiliser, le cas échéant.
Il existe des outils tiers qui peuvent découvrir et mapper votre réseau, mais le moyen le plus sûr de connaître vos appareils est de demander à un membre de votre équipe réseau.
Identifiez votre fournisseur de services Internet (ISP), notez ses informations de contact et demandez combien de circuits vous avez de bande passante.
Au sein de votre entreprise, identifiez les ressources pour les appareils entre votre client et le point de sortie, ou identifiez un contact d’urgence pour discuter des problèmes de réseau.
Voici quelques bases de référence que des tests simples avec des outils peuvent calculer pour vous :
Temps entre votre ordinateur client et votre point de sortie, en millisecondes
Temps entre votre point de sortie et Office 365 en millisecondes
Emplacement dans le monde du serveur qui résout les URL pour Office 365 lorsque vous naviguez
Vitesse de la résolution DNS de votre fournisseur de services Internet en millisecondes, incohérences dans l’arrivée des paquets (gigue réseau), temps de chargement et de téléchargement en millisecondes
Si vous n’êtes pas familiarisé avec la façon d’effectuer ces étapes, nous allons aller plus en détail dans cet article.
Qu’est-ce qu’une base de référence ?
Vous connaîtrez l’impact en cas de mauvaises performances, mais si vous ne connaissez pas vos données de performances historiques, il n’est pas possible d’avoir un contexte pour savoir à quel moment elle est devenue mauvaise. Donc, sans base de référence, vous manquez l’indice clé pour résoudre le puzzle : l’image sur la boîte de puzzle. Dans la résolution des problèmes de performances, vous avez besoin d’un point de comparaison. Les bases de référence de performances simples ne sont pas difficiles à prendre. Votre équipe des opérations peut être chargée d’effectuer ces opérations selon une planification. Par exemple, supposons que votre connexion ressemble à ceci :
Cela signifie que vous avez vérifié auprès de votre équipe réseau et découvert que vous quittez votre entreprise pour Internet par le biais d’un serveur proxy, et que ce proxy gère toutes les demandes que votre ordinateur client envoie au cloud. Dans ce cas, vous devez dessiner une version simplifiée de votre connexion qui répertorie tous les appareils intermédiaires. À présent, insérez des outils que vous pouvez utiliser pour tester les performances entre le client, le point de sortie (où vous quittez votre réseau pour Internet) et le cloud Office 365.
Les options sont répertoriées comme Simples et Avancées en raison de la quantité d’expertise dont vous avez besoin pour trouver les données de performances. Une trace réseau prend beaucoup de temps, par rapport à l’exécution d’outils en ligne de commande tels que PsPing et TraceTCP. Ces deux outils en ligne de commande ont été choisis parce qu’ils n’utilisent pas de paquets ICMP, qui seront bloqués par Office 365, et parce qu’ils donnent le temps nécessaire en millisecondes pour quitter l’ordinateur client ou le serveur proxy (si vous y avez accès) et arriver à Office 365. Chaque tronçon individuel d’un ordinateur à un autre se retrouve avec une valeur de temps, et c’est idéal pour les bases de référence ! Tout aussi important, ces outils en ligne de commande vous permettent d’ajouter un numéro de port à la commande, car Office 365 communique sur le port 443, qui est le port utilisé par Secure Sockets Layer et Transport Layer Security (SSL et TLS). Toutefois, d’autres outils tiers peuvent être de meilleures solutions pour votre situation. Microsoft ne prend pas en charge tous ces outils. Par conséquent, si, pour une raison quelconque, vous ne pouvez pas faire fonctionner PsPing et TraceTCP, passez à une trace réseau avec un outil comme Netmon.
Vous pouvez prendre une base de référence avant les heures d’ouverture, de nouveau pendant une utilisation intensive, puis de nouveau après les heures d’ouverture. Cela signifie que vous pouvez avoir une structure de dossiers qui ressemble un peu à ceci à la fin :
Vous devez également choisir une convention d’affectation de noms à vos fichiers. Voici quelques exemples :
Feb_09_2015_9amPST_PerfBaseline_Netmon_ClientToEgress_Normal
Jan_10_2015_3pmCST_PerfBaseline_PsPing_ClientToO365_bypassProxy_SLOW
Feb_08_2015_2pmEST_PerfBaseline_BADPerf
30amEST_PerfBaseline_GoodPerf Feb_08_2015_8
Il existe de nombreuses façons de procéder, mais l’utilisation> du format< dateTime>< est un bon point de départ. Être diligent à ce sujet vous aidera beaucoup lorsque vous essayez de résoudre les problèmes ultérieurement. Plus tard, vous serez en mesure de dire « J’ai pris deux traces le 8 février, l’une a montré de bonnes performances et l’autre a montré de mauvaises performances, donc nous pouvons les comparer ». Cela est utile pour la résolution des problèmes.
Vous devez disposer d’un moyen organisé pour conserver vos bases de référence historiques. Dans cet exemple, les méthodes simples ont produit trois sorties de ligne de commande et les résultats ont été collectés sous forme de captures d’écran, mais vous avez peut-être des fichiers de capture réseau à la place. Utilisez la méthode qui vous convient le mieux. Stockez vos bases de référence historiques et faites-y référence à des points où vous remarquez des changements dans le comportement de services en ligne.
Pourquoi collecter des données de performances pendant un pilote ?
Il n’y a pas de meilleur moment pour commencer à établir des bases de référence que pendant un pilote du service Office 365. Votre bureau peut avoir des milliers d’utilisateurs, des centaines de milliers, ou cinq, mais même avec quelques utilisateurs, vous pouvez effectuer des tests pour mesurer les fluctuations des performances. Dans le cas d’une grande entreprise, un échantillon représentatif de plusieurs centaines d’utilisateurs pilotant Office 365 peut être projeté vers l’extérieur à plusieurs milliers afin que vous sachiez où les problèmes peuvent survenir avant qu’ils ne se produisent.
Dans le cas d’une petite entreprise, où l’embarquement signifie que tous les utilisateurs se rendent au service en même temps et qu’il n’y a pas de pilote, conservez les mesures de performance afin que vous ayez des données à montrer à toute personne susceptible de devoir résoudre une opération mal performante. Par exemple, si vous remarquez que tout d’un coup, vous pouvez vous promener dans votre bâtiment dans le temps nécessaire pour charger un graphique de taille moyenne où cela se produisait rapidement.
Comment collecter des bases de référence
Pour tous les plans de résolution des problèmes, vous devez au minimum identifier ces éléments :
L’ordinateur client que vous utilisez (le type d’ordinateur ou d’appareil, une adresse IP et les actions à l’origine du problème)
Où se trouve l’ordinateur client dans le monde (par exemple, si cet utilisateur utilise un VPN vers le réseau, travaille à distance ou sur l’intranet de l’entreprise)
Point de sortie utilisé par l’ordinateur client à partir de votre réseau (point auquel le trafic quitte votre entreprise pour un isp ou Internet)
Vous pouvez trouver la disposition de votre réseau auprès de l’administrateur réseau. Si vous êtes sur un petit réseau, examinez les appareils qui vous connectent à Internet et appelez votre fai si vous avez des questions sur la disposition. Create un graphique de la disposition finale pour votre référence.
Cette section est divisée en méthodes et outils en ligne de commande simples, et en options d’outils plus avancées. Nous allons d’abord aborder les méthodes simples. Toutefois, si vous rencontrez un problème de performances, vous devez passer aux méthodes avancées et essayer l’exemple de plan d’action de résolution des problèmes de performances.
Méthodes simples
L’objectif de ces méthodes simples est d’apprendre à prendre, à comprendre et à stocker correctement des bases de référence de performances simples au fil du temps afin d’être informé des performances Office 365. Voici le diagramme simple pour simple, comme vous l’avez vu précédemment :
Remarque
TraceTCP est inclus dans cette capture d’écran, car il s’agit d’un outil utile pour afficher, en millisecondes, la durée de traitement d’une requête et le nombre de tronçons réseau, ou de connexions d’un ordinateur à l’autre, que la demande prend pour atteindre une destination. TraceTCP peut également fournir les noms des serveurs utilisés pendant les tronçons, ce qui peut être utile pour un utilitaire de résolution des problèmes Microsoft Office 365 dans support. > Les commandes TraceTCP peuvent être très simples, telles que : >tracetcp.exe outlook.office365.com:443> N’oubliez pas d’inclure le numéro de port dans la commande ! >TraceTCP est un téléchargement gratuit, mais s’appuie sur Wincap. Wincap est un outil qui est également utilisé et installé par Netmon. Nous utilisons également Netmon dans la section méthodes avancées.
Si vous avez plusieurs bureaux, vous devez également conserver un ensemble de données provenant d’un client dans chacun de ces emplacements. Ce test mesure la latence, qui, dans ce cas, est une valeur numérique qui décrit la durée entre l’envoi d’une demande à Office 365 par un client et Office 365 réponse à la demande. Les tests proviennent de votre domaine sur un ordinateur client et cherchent à mesurer un aller-retour à partir de l’intérieur de votre réseau, par le biais d’un point de sortie, sur Internet pour Office 365 et revenir.
Il existe plusieurs façons de traiter le point de sortie, dans ce cas, le serveur proxy. Vous pouvez effectuer le suivi de 1 à 2, puis de 2 à 3, puis ajouter les nombres en millisecondes pour obtenir un total final à la périphérie de votre réseau. Vous pouvez également configurer la connexion pour contourner le proxy pour les adresses Office 365. Dans un réseau plus grand avec un pare-feu, un proxy inverse ou une combinaison des deux, vous devrez peut-être faire des exceptions sur le serveur proxy qui permettront au trafic de passer pour un grand nombre d’URL. Pour obtenir la liste des points de terminaison utilisés par Office 365, consultez Office 365 URL et plages d’adresses IP. Si vous disposez d’un proxy d’authentification, commencez par tester les exceptions suivantes :
Ports 80 et 443
TCP et HTTPs
Connections sortants vers l’une de ces URL :
*.microsoftonline.com
*.microsoftonline-p.com
*.sharepoint.com
*.outlook.com
*.lync.com
osub.microsoft.com
Tous les utilisateurs doivent être autorisés à accéder à ces adresses sans interférence de proxy ni authentification. Sur un réseau plus petit, vous devez les ajouter à votre liste de contournement de proxy dans votre navigateur web.
Pour les ajouter à votre liste de contournement de proxy dans Internet Explorer, accédez à Outils>Options> Internet Connections Paramètres>>réseau avancés. L’onglet Avancé est également l’emplacement où vous trouverez votre serveur proxy et le port du serveur proxy. Vous devrez peut-être cocher la case Utiliser un serveur proxy pour votre réseau local pour accéder au bouton Avancé . Vous devez vérifier que l’option Ignorer le serveur proxy pour les adresses locales est cochée. Une fois que vous avez sélectionné Avancé, vous voyez une zone de texte dans laquelle vous pouvez entrer des exceptions. Séparez les URL génériques répertoriées ci-dessus par des points-virgules, par exemple :
*.microsoftonline.com ; *.sharepoint.com
Une fois que vous avez contourné votre proxy, vous devez être en mesure d’utiliser ping ou PsPing directement sur une URL Office 365. L’étape suivante consiste à tester les outlook.office365.com ping. Ou, si vous utilisez PsPing ou un autre outil qui vous permet de fournir un numéro de port à la commande, PsPing par rapport à portal.microsoftonline.com:443 pour voir le temps moyen d’aller-retour en millisecondes.
Le temps d’aller-retour, ou RTT, est une valeur numérique qui mesure le temps nécessaire pour envoyer une requête HTTP à un serveur comme outlook.office365.com et obtenir une réponse qui reconnaît que le serveur sait que vous l’avez fait. Vous verrez parfois cela abrégé en RTT. Ce délai devrait être relativement court.
Pour effectuer ce test, vous devez utiliser PSPing ou un autre outil qui n’utilise pas de paquets ICMP bloqués par Office 365.
Comment utiliser PsPing pour obtenir un temps d’aller-retour global en millisecondes directement à partir d’une URL de Office 365
Exécutez une invite de commandes avec élévation de privilèges en procédant comme suit :
Cliquez sur Démarrer.
Dans la zone Démarrer Recherche, tapez cmd, puis appuyez sur Ctrl+Maj+Entrée.
Si la boîte de dialogue Contrôle de compte d'utilisateur apparaît, confirmez que l'action affichée est celle que vous souhaitez, puis cliquez sur Continuer.
Accédez au dossier où l’outil (dans ce cas PsPing) est installé et testez ces URL Office 365 :
psping admin.microsoft.com:443
psping microsoft-my.sharepoint.com:443
psping outlook.office365.com:443
-
Veillez à inclure le numéro de port 443. N’oubliez pas que Office 365 fonctionne sur un canal chiffré. Si vous PsPing sans le numéro de port, votre demande échoue. Une fois que vous avez effectué un test ping sur votre liste courte, recherchez le Temps moyen en millisecondes (ms). C’est ce que vous voulez enregistrer !
Si vous n’êtes pas familiarisé avec la déviation du proxy et que vous préférez effectuer les opérations étape par étape, vous devez d’abord trouver le nom de votre serveur proxy. Dans Internet Explorer, accédez à Outils>Options> Internet Connections Paramètres>>réseau avancés. L’onglet Avancé est l’emplacement où vous verrez votre serveur proxy répertorié. Effectuez un test ping sur ce serveur proxy à une invite de commandes en effectuant cette tâche :
Pour effectuer un test ping sur le serveur proxy et obtenir une valeur aller-retour en millisecondes pour les étapes 1 à 2
Exécutez une invite de commandes avec élévation de privilèges en procédant comme suit :
Cliquez sur Démarrer.
Dans la zone Démarrer Recherche, tapez cmd, puis appuyez sur Ctrl+Maj+Entrée.
Si la boîte de dialogue Contrôle de compte d'utilisateur apparaît, confirmez que l'action affichée est celle que vous souhaitez, puis cliquez sur Continuer.
Tapez ping <le nom du serveur proxy utilisé par votre navigateur ou l’adresse IP du serveur> proxy, puis appuyez sur Entrée. Si PsPing ou un autre outil est installé, vous pouvez choisir d’utiliser cet outil à la place.
Votre commande peut ressembler à l’un des exemples suivants :
ping ourproxy.ourdomain.industry.business.com
ping 155.55.121.55
ping ourproxy
psping ourproxy.ourdomain.industry.business.com:80
psping 155.55.121.55 :80
psping ourproxy :80
- Lorsque la trace cesse d’envoyer des paquets de test, vous obtenez un petit résumé qui répertorie une moyenne, en millisecondes, et c’est la valeur que vous recherchez. Prenez une capture d’écran de l’invite et enregistrez-la à l’aide de votre convention de nommage. À ce stade, il peut également être utile de remplir le diagramme avec la valeur .
Peut-être que vous avez pris une trace tôt le matin et que votre client peut accéder au proxy (ou tout serveur de sortie se ferme à Internet) rapidement. Dans ce cas, vos nombres peuvent ressembler à ceci :
Si votre ordinateur client est l’un des rares à avoir accès au serveur proxy (ou de sortie), vous pouvez exécuter l’étape suivante du test en vous connectant à distance à cet ordinateur, en exécutant l’invite de commandes à PsPing vers une URL Office 365 à partir de là. Si vous n’avez pas accès à cet ordinateur, vous pouvez contacter vos ressources réseau pour obtenir de l’aide sur l’étape suivante et obtenir des numéros exacts de cette façon. Si ce n’est pas possible, prenez un PsPing par rapport à l’URL Office 365 en question et comparez-le à l’heure PsPing ou Ping par rapport à votre serveur proxy.
Par exemple, si vous avez 51,84 millisecondes entre le client et l’URL Office 365, et que vous avez 2,8 millisecondes entre le client et le proxy (ou le point de sortie), vous avez 49,04 millisecondes entre la sortie et Office 365. De même, si vous avez un PsPing de 12,25 millisecondes entre le client et le proxy pendant la hauteur de la journée, et 62,01 millisecondes entre le client et l’URL Office 365, votre valeur moyenne pour la sortie du proxy vers l’URL Office 365 est de 49,76 millisecondes.
En termes de résolution des problèmes, vous trouverez peut-être quelque chose d’intéressant simplement en conservant ces bases de référence. Par exemple, si vous constatez que vous avez généralement environ 40 millisecondes à 59 millisecondes de latence à partir du proxy ou que vous pointez de sortie vers l’URL Office 365, et que vous avez un client vers le proxy ou une latence de point de sortie d’environ 3 millisecondes à 7 millisecondes (en fonction de la quantité de trafic réseau que vous voyez pendant cette heure de la journée), vous saurez certainement que quelque chose est problématique si vos trois derniers clients vers le proxy ou les bases de référence de sortie affichent un problème latence de 45 millisecondes.
Méthodes avancées
Si vous voulez vraiment savoir ce qui se passe avec vos demandes Internet pour Office 365, vous devez vous familiariser avec les traces réseau. Peu importe les outils que vous préférez pour ces traces, HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, Developer Dashboard tool ou tout autre outil peut capturer et filtrer le trafic réseau. Vous verrez dans cette section qu’il est avantageux d’exécuter plusieurs de ces outils pour obtenir une image plus complète du problème. Lorsque vous effectuez des tests, certains de ces outils agissent également en tant que proxys à part entière. Les outils utilisés dans l’article complémentaire, Plan de résolution des problèmes de performances pour Office 365, incluent Netmon 3.4, HTTPWatch ou WireShark.
L’utilisation d’une base de référence des performances est la partie simple de cette méthode, et la plupart des étapes sont les mêmes que lorsque vous résolvez un problème de performances. Les méthodes plus avancées de création de bases de référence pour les performances nécessitent que vous preniez et stockiez des traces réseau. La plupart des exemples de cet article utilisent SharePoint, mais vous devez développer une liste d’actions courantes dans les services Office 365 auxquels vous vous abonnez pour tester et enregistrer. Voici un exemple de base :
Liste de référence pour SPO - ** Étape 1 : ** Parcourez la page d’accueil du site web SPO et effectuez une trace réseau. Enregistrez la trace.
Liste de référence pour SPO - Étape 2 : Recherche pour un terme (tel que le nom de votre entreprise) via Enterprise Recherche et effectuer une trace réseau. Enregistrez la trace.
Liste de référence pour SPO - Étape 3 : charger un fichier volumineux dans une bibliothèque de documents SharePoint et effectuer une trace réseau. Enregistrez la trace.
Liste de référence pour SPO - Étape 4 : parcourez la page d’accueil du site web OneDrive et effectuez une trace réseau. Enregistrez la trace.
Cette liste doit inclure les actions courantes les plus importantes que les utilisateurs effectuent sur SharePoint. Notez que la dernière étape, pour effectuer le suivi vers OneDrive, génère une comparaison entre la charge de la page d’accueil SharePoint (qui est souvent personnalisée par les entreprises) et la page d’accueil OneDrive, qui est rarement personnalisée. Il s’agit d’un test de base lorsqu’il s’agit d’un site SharePoint à chargement lent. Vous pouvez créer un enregistrement de cette différence dans vos tests.
Si vous êtes au milieu d’un problème de performances, la plupart des étapes sont les mêmes que lors de l’utilisation d’une base de référence. Les traces réseau devenant critiques, nous allons donc gérer la façon de prendre les traces importantes ensuite.
Pour résoudre un problème de performances, vous devez maintenant prendre une trace au moment où vous rencontrez le problème de performances. Vous devez disposer des outils appropriés pour collecter les journaux, et vous avez besoin d’un plan d’action, c’est-à-dire d’une liste d’actions de dépannage à entreprendre pour collecter les meilleures informations possibles. La première chose à faire est d’enregistrer la date et l’heure du test afin que les fichiers puissent être enregistrés dans un dossier qui reflète le minutage. Ensuite, limitez-vous aux étapes du problème elles-mêmes. Voici les étapes exactes que vous allez utiliser pour les tests. N’oubliez pas les principes de base : si le problème concerne uniquement Outlook, veillez à enregistrer que le comportement du problème se produit dans un seul service Office 365. La réduction de l’étendue de ce problème vous aidera à vous concentrer sur quelque chose que vous pouvez résoudre.