Regardons la configuration DNS.

Nous avons travaillé avec un client qui avait eu des difficultés pour accéder à Office365 depuis son domaine européen.

Après avoir comparé les performances sur plusieurs sites et avoir admis que le problème se produisait en Europe seulement, nous avons commencé à explorer sa configuration réseau.

Où vont les données? A quel niveau quittent-elles le réseau? Comment ont-elles été traitées sur le backbone de Microsoft?

Nous avons commencé à réaliser que le problème n’était pas le point d’accès européen, ni son réseau local, mais que les données traversaient les États-Unis avant d’arriver chez Microsoft.

Pour être plus précis, les données se dirigeaient vers le nord-ouest des États-Unis.

Nous avons continué à creuser et avons découvert que le client avait un DNS interne pointant vers le DNS de Google ; vous pouvez imaginer que depuis l’Europe, ce DNS ne pouvait pas fournir de très bonnes performances.

Lorsque des clients européens traversent le web via le DNS de la côte ouest des États-Unis pour récupérer leurs e-mails, les performances de leurs connexions sont réduites.

Expérience

Afin de montrer pour quelles raisons les performances se dégradent, nous avons mis nos robots dans les mêmes conditions.

Nous avons configuré un robot qui force une résolution d’adresse IP aux États-Unis puis renvoie le trafic vers la zone EMEA où il serait à nouveau renvoyé aux Etats-Unis …avant d’être finalement envoyé à Microsoft.

Nous avons donc un robot effectuant un test que nous avons précédemment fait sur le point d’entrée du siège afin d’analyser à quel point cela aurait un impact sur les résultats.

 

Résultats

Le temps moyen de chaque action est largement dégradé par rapport aux autres robots; le nombre de dégradations qui mènent à l’ouverture de tickets potentiels est beaucoup plus élevé que celui des 3 autres robots-user que nous avons configurés précédemment.

Plus vous vos utilisateurs sont éloignés de votre tenant, plus les problèmes de performances sont importants

Ceci est un cas extrême, mais il montre comment la configuration du réseau peut réellement affecter l’expérience utilisateur.

De même, le VPN peut également avoir un impact sur les performances des utilisateurs finaux.

 

Configuration d’un VPN

La connexion avec un VPN peut avoir un impact considérable sur les performances, en fonction du protocole, de ses paramètres et en particulier des paramètres de la passerelle.

Avec un VPN, en vous connectant depuis l’Europe ou depuis un tenant aux États-Unis, la différence sera importante.

Si on prend  Skype en exemple, son trafic est déjà crypté en TLS. Les charges de travail multimédias sont cryptées avec Secure Real Time Protocol.

Ainsi, l’utilisation d’un VPN ne fera qu’ajouter un autre cryptage, des bonds de réseau supplémentaires et affectera considérablement les performances augmentant le jitter, la perte de paquets et la latence.

Une fois de plus, sachez que la configuration de votre point d’entrée est ce qui importe vraiment ici. Vous devez aller aussi vite que possible sur le réseau de Microsoft et éliminer les couches d’infrastructure et de sécurité inutiles si vous souhaitez bénéficier de la meilleure expérience utilisateur.

 

Le cas d’un proxy authentifié

 

De la même manière, voici une autre configuration réseau à laquelle nous avons été confrontés à plusieurs reprises avec laquelle des clients ont rencontré des problèmes de connectivité.

Beaucoup de nos clients avaient eu des problèmes suite à l’installation d’un proxy pour se connecter à Office 365. Ce qui semble être une bonne idée s’est rapidement transformé en une source de coûts supplémentaires.

Nous avons reproduit la situation avec nos robots-utilisateurs afin de fournir des données sur ce problème lié au proxy.

 

Comparaison de l’expérience utilisateur final avec un proxy authentifié

 

Le tableau de bord affiche nos tests sur le Free/Busy effectués depuis plusieurs robots-users. Ici, il est intéressant de comprendre qui fait quoi. Concentrons-nous sur le graphique carré qui compare le temps nécessaire pour effectuer cette action de Free/Busy :

Le premier carré (gris) représente les résultats du robot-utilisateur de Philadelphie se connectant au tenant européen. Le second (en noir) est un robot-utilisateur de Bangalore qui a des problèmes de bande passante et se connecte au tenant européen.

Ce qui est intéressant ici, c’est le troisième (en bas à gauche, en vert). Il s’agit d’un robot-user installé à Philadelphie qui se connecte à un tenant américain, mais la connexion au tenant est configurée pour rediriger d’abord chaque connexion sortante vers un proxy authentifié.

Le serveur proxy authentifié exige simplement que les clients s’authentifient avant de se connecter à Office 365.

Ce qui est remarquable est que le robot-user américain se connectant à un tenant américain obtient un résultat d’exécution plus mauvais que le carré rouge en haut représentant un robot-user implanté à Bangalore se connectant au tenant aux États-Unis.

 

Ceci est un très bon exemple sur la façon dont avec un simple équipement réseau entre Office 365 et le tenant, vous pouvez réduire considérablement les performances de l’utilisateur final.

Le simple fait d’installer un équipement comme un proxy peut réellement affecter les performances fournies aux utilisateurs finaux.

 

Conclusion

Après cette série de tests, nous sommes arrivés à la conclusion selon laquelle plusieurs paramètres fondamentaux sont nécessaires pour permettre de gérer de manière optimale l’expérience de l’utilisateur final.

Tout d’abord, vous devez connaître votre propre configuration réseau et mesurer constamment l’expérience de l’utilisateur final : vous avez besoin de ces mesures car vous devez analyser les données pour comprendre ce qui se passe.

Deuxièmement, vous devez disposer de plusieurs points de connectivité pour vous permettre de faire des comparaisons, ce qui signifie plusieurs robots-utilisateurs pour permettre de déterminer si les problèmes affectent un ou plusieurs sites ou l’ensemble de votre tenant.

Ensuite, vous devez mesurer l’expérience utilisateur au niveau des actions qu’ils peuvent effectuer. Nous avons clairement montré qu’un comportement normal de l’ouverture d’une boîte aux lettres ne signifie rien, contrairement à d’autres actions telles que le Free/Busy ou la création d’un rendez-vous, par exemple.

Enfin, vous devez comprendre comment fonctionne la configuration de votre réseau, d’où proviennent les données et comment elles sont transmises à Microsoft. L’itinéraire des données et la configuration de l’équipement peuvent avoir une incidence considérable sur l’expérience de l’utilisateur final et augmenter considérablement vos coûts d’assistance.

C’est pourquoi il est essentiel de surveiller cette expérience de l’utilisateur final avant, pendant et après les modifications de votre réseau pour obtenir des informations et des résultats basés sur ces modifications du réseau.