Résolution des problèmes de performances eCDN

Cette page répertorie certains problèmes de performances courants et les solutions possibles.

Aucun peering observé de manière inattendue

En général, il existe deux scénarios principaux où vos visionneuses sont automatiquement définies sur p2p-off : le scénario sans ip et le scénario d’ip incorrecte.

Visionneuses dans un groupe « Non groupé »

Les visionneuses du groupe de sous-réseaux prédéfinis « Non groupés » ne sont pas appairées, car elles sont automatiquement définies sur p2p-off. Si vos visionneuses appartiennent au groupe Non groupé , vérifiez que vous respectez les instructions de désactivation du masquage IP mDNS . Pour obtenir une définition complète du groupe non groupé , consultez les définitions de groupes par défaut.

Si vous respectez correctement nos conseils mDNS et que vos utilisateurs ne parviennent toujours pas à exposer leur adresse IP, ce qui peut être attribué au groupe Non groupé , la cause peut être due à la stratégie de navigateur.

Stratégie de gestion IP WebRTC bloquant le peering

Certaines stratégies de navigateur peuvent empêcher Microsoft eCDN d’obtenir les adresses IP locales nécessaires au peering. Microsoft Edge (WebRtcLocalhostIpHandling) et Google Chrome (WebRtcIPHandling) ont des stratégies équivalentes qui peuvent entraîner des problèmes. Si l’une des stratégies est définie sur :

• disable_non_proxied_udp: le trafic WebRTC est limité et peut bloquer les fonctionnalités eCDN
• default_public_interface_only: seule l’interface publique par défaut est utilisée, ce qui empêche la détection d’adresses IP locales

Solution : Il existe deux façons de restaurer l’énumération IP locale pour les clients Microsoft eCDN :

1. Préféré : modifiez la stratégie de gestion globale (ce qui est actuellement recommandé dans cet article) : configurez la stratégie sur vos appareils gérés sur l’une des valeurs suivantes afin que les navigateurs autorisent l’énumération IP locale :

   • default: autorise le comportement WebRTC normal (recommandé pour Microsoft eCDN)
   • default_public_and_private_interfaces: autorise la détection d’interface publique et privée

   Cela est généralement appliqué de manière centralisée via stratégie de groupe ou Microsoft Intune. Il s’agit du moyen le plus simple de s’assurer que Microsoft eCDN peut obtenir des adresses IP locales pour le peering.

2. Alternative : appliquez une exception ciblée pour les origines eCDN : utilisez la WebRtcIPHandlingUrl stratégie (prise en charge par Microsoft Edge et Google Chrome) pour définir explicitement le mode de gestion IP pour les origines Microsoft eCDN et Teams (répertoriées dans l’article Comment désactiver l’obfuscation mDNS ) sur default. Cette option vous permet de conserver une valeur par défaut globale plus restrictive tout en activant l’énumération d’adresses IP locales uniquement pour les origines nécessaires. Déployez cette stratégie via stratégie de groupe ou Intune et vérifiez que les origines répertoriées sont incluses.

   Exemple de test (PowerShell)

   Exécutez ce PowerShell (en tant qu’administrateur sur un ordinateur de test) pour activer temporairement la gestion IP par défaut pour les origines eCDN/Teams sur Microsoft Edge ; vérifiez et rétablissez après le test.

   $edgePoliciesPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Edge'
   $jsonValue = '[{"handling":"default","url":"[*.]ecdn.teams.microsoft.com"},{"handling":"default","url":"https://teams.microsoft.com"},{"handling":"default","url":"https://teams.cloud.microsoft"},{"handling":"default","url":"[*.]ecdn.teams.cloud.microsoft"}]'
   Set-ItemProperty -Path $edgePoliciesPath -Name "WebRtcIPHandlingUrl" -Value $jsonValue -Force
   

   Importante

   Portez une attention particulière à la syntaxe générique (*) dans les modèles d’URL lors de la configuration de cette stratégie.

Collaborez avec votre administrateur informatique pour choisir et déployer l’approche qui correspond le mieux à la posture de sécurité et aux pratiques de gestion des changements de votre organization.

Visionneuses dans le groupe « Groupe par défaut »

Les visionneuses du groupe de sous-réseaux prédéfinis « Groupe par défaut » peuvent être automatiquement définies sur p2p-off selon que le mappage de sous-réseau est chargé ou non.

Si vous avez défini votre mappage de sous-réseau et que vos visionneuses appartiennent au groupe « Groupe par défaut », cela signifie que l’adresse IP capturée par le SDK eCDN n’est pas prise en compte dans votre mappage de sous-réseau. Consultez l’adresse IP capturée dans la colonne Ip privée du tableau de répartition utilisateur du tableau de bord d’exploration. Pour plus d’informations, consultez les définitions de groupes par défaut.

Problème de plusieurs cartes réseau

Le « problème de plusieurs cartes réseau » est généralement caractérisé par le fait que les visionneuses sont placées par inadvertance dans un groupe fourre-tout involontaire ou dans le groupe par défaut défini par le système au lieu de leur groupe de sous-réseau prévu. Ce problème se produit lorsque plusieurs adresses IP locales valides sont présentes sur l’appareil d’une visionneuse. Consultez le scénario Multi-NIC pour en savoir plus.

Pour vérifier ce problème, procédez comme suit :

1. Vérifiez l’adresse IP privée : Examinez l’adresse IP de l’utilisateur répertoriée dans la colonne Ip privée de la table de répartition Utilisateurs du tableau de bord d’exploration.
2. Comparer avec les adresses IP d’appareil : Exécutez la ipconfig commande dans la ligne de commande de l’appareil de l’utilisateur. Comparez les adresses IP obtenues à partir de cette commande avec l’adresse IP dans le tableau de bord Explorations. Vous pouvez découvrir que l’adresse IP d’une carte Ethernet involontaire a été sélectionnée pour l’affectation du groupe de sous-réseaux de l’appareil.

Un plus grand nombre d’adaptateurs Ethernet peuvent fournir des adresses IP supplémentaires à un système. Les raisons courantes incluent la présence de clients VPN ou de logiciels hôtes virtuels. La solution appropriée dépend du contexte spécifique de votre environnement. Nous vous recommandons d’engager une discussion interne avec votre administrateur informatique afin de déterminer la meilleure approche pour résoudre ce problème.

Créez un cas avec notre équipe si vous pensez que l’adresse IP incorrecte a été choisie par erreur.

Faible efficacité du peering

Une faible efficacité de peering se produit généralement en raison d’un ou de plusieurs des problèmes suivants.

• Événement en direct avec trop peu d’utilisateurs (moins de 50)
• Absence d’adresses IP locales des utilisateurs finaux
• Absence de groupes de mappage de sous-réseaux
• Latence élevée entre deux appareils

Solution

• En cas de test, veillez à effectuer des tests avec autant de clients que possible. Plus il y a de participants à un événement, plus les groupes de peering sont importants, ce qui entraîne des performances de déchargement plus fortes.

• Si les utilisateurs n’utilisent pas l’application de bureau Teams, vérifiez que l’obfuscation ip mDNS est désactivée afin que Microsoft eCDN puisse obtenir les adresses IP locales des utilisateurs finaux. Découvrez comment désactiver le masquage IP mDNS pour obtenir des instructions.

• Chargez votre mappage de sous-réseau dans l’interface utilisateur mappage de sous-réseau. Votre mappage doit inclure les noms de sites et les sous-réseaux au sein du réseau d’entreprise. Consultez l’exemple de figure suivant.

  

• Effectuez un test de latence. Dans l’idéal, la latence entre deux appareils doit être inférieure à 30 ms et ne doit pas fluctuer à un degré élevé.

Pour plus d’informations, consultez Résolution des problèmes de faible efficacité de peering.

Manque d’analytique, pas de peering pour les événements en direct

Les causes courantes suivantes peuvent vous empêcher de voir des analyses après avoir mené un événement en direct Teams (TLE) ou une assemblée publique et une solution pour chacune d’elles.

L’administrateur affiche un intervalle de temps incorrect

Il existe un sélecteur de temps dans l’angle supérieur droit du tableau de bord analytique. Veillez à sélectionner l’intervalle de temps approprié.

Microsoft eCDN non configuré dans teams Administration Center

Dans votre Centre Administration Teams (TAC), assurez-vous que Microsoft eCDN est sélectionné en tant que fournisseur SDN.

Microsoft eCDN non configuré pour le locataire de production ou l’événement effectué dans le locataire de test

Vérifiez que le locataire de production est utilisé.

Microsoft eCDN est correctement configuré dans TAC, mais l’événement en direct est effectué avant que Microsoft eCDN prenne effet

La propagation de la modification de la configuration du locataire prend jusqu’à 24 heures. Effectuez un test rapide auprès de quelques utilisateurs internes et vérifiez que vous voyez les analyses avant un événement de production important.

Le producteur a créé une réunion Teams au lieu d’un TLE ou d’un hôtel de ville

Microsoft eCDN prend en charge les événements en direct teams et les assemblées de ville. Veillez à créer un événement en direct pris en charge.

Les participants étaient des utilisateurs anonymes

Autrement dit, il s’agissait d’utilisateurs extérieurs à votre locataire ou d’utilisateurs non authentifiés.

Microsoft eCDN est activé sur le locataire pour lequel il est configuré. Les participants en dehors de votre locataire n’utilisent pas Microsoft eCDN. Une façon de s’assurer que les utilisateurs sont correctement authentifiés consiste à limiter l’accès aux événements aux utilisateurs au sein de votre organization au lieu de le rendre « public ».

Pour les événements en direct Teams :

Pour les mairies :

Les participants ont été invités en tant que présentateurs

Les présentateurs ne participent pas au peering, seuls les participants le font. Lorsque vous créez un événement, assurez-vous d’inviter des participants en tant que participants.

Le filtrage IP Microsoft eCDN bloque la participation eCDN des participants

Vérifiez que l’onglet Sécurité ne contient pas d’adresses IP, sauf si vous souhaitez uniquement autoriser les utilisateurs des plages d’adresses IP publiques spécifiées à utiliser le service eCDN. Si aucune adresse IP n’est spécifiée, tous les utilisateurs sont autorisés à se connecter à partir de toutes les adresses IP publiques.

Le filtrage de domaine Microsoft eCDN bloque la participation eCDN des participants

Comme pour le filtrage IP ci-dessus, assurez-vous que l’onglet Plateformes tierces ne contient aucun domaine, sauf si vous souhaitez uniquement autoriser les utilisateurs des domaines spécifiés à utiliser le service eCDN. Si aucun domaine n’est spécifié, tous les utilisateurs sont autorisés à se connecter à partir de tous les domaines.

Les paramètres de pare-feu/réseau peuvent bloquer les connexions WebSocket

Vérifiez que le domaine Microsoft eCDN est autorisé. Effectuez un test rapide à l’aide de notre page testeur et recherchez les erreurs dans l’onglet Mise en réseau des outils de développement de votre navigateur.

Pour plus d’informations, consultez la documentation relative à la configuration réseau requise . Dans l’idéal, la section mise en réseau doit afficher le résultat suivant.

Aide supplémentaire

Si vous avez épuisé les étapes de résolution des problèmes ci-dessus et que vous ne voyez toujours pas de données dans votre tableau de bord analytique, collectez les informations suivantes pour l’événement en question et envoyez-les à votre représentant de compte Microsoft.

1. Capture d’écran de la table complète des rapports d’utilisation.

   1. Accédez à votre Centre Administration Teams (TAC).
   2. Accédez à Analytics & rapports>Rapports d’utilisation dans le volet de menu à gauche
   3. Sélectionner l’utilisation des événements en direct Teams dans le sélecteur de type de rapport
   4. Sélectionner la plage de dates appropriée
   5. Sélectionnez le bouton Exécuter le rapport
   6. Vérifiez que la capture d’écran inclut la colonne « Type de production » pour l’événement en question

2. Téléchargez le rapport des participants à partir du TAC.

   1. En continuant à partir des étapes ci-dessus, sélectionnez l’événement en question
   2. Sélectionner le rapport d’engagement des participants à télécharger

3. Envoyez ces informations, ainsi que votre ID de locataire, à votre spécialiste technique Microsoft, à votre responsable de compte customer success ou à votre architecte de solutions cloud.

Le nombre de visionneuses est différent de celui des rapports ailleurs

Comparaison des visionneuses uniques aux vues

Microsoft eCDN Analytics affiche un nombre de visionneuses uniques, quel que soit le nombre d’appareils ou les défaillances de la session d’affichage. Autrement dit, un utilisateur unique et authentifié équivaut à une visionneuse. Lors de la comparaison des nombres de visionneuses dérivés d’autres sources, il est important de noter les différences possibles dans les méthodologies de comptage.

Cas précis : rapport d’événements en direct Teams

Comparons le nombre de visionneuses de Microsoft eCDN à celui de la colonne Vues dans le rapport d’utilisation des événements en direct Teams. La distinction à noter ici est que dans le rapport d’utilisation, une vue équivaut à une session d’affichage. Par conséquent, en ce qui concerne une visionneuse unique, chaque nouvelle session sur un nouvel appareil, ou après une déconnexion, ou une modification du réseau, ou même après le rechargement de la page, peut être comptabilisée comme une vue supplémentaire. Du point de vue de Microsoft eCDN, quel que soit le nombre de sessions, il est compté comme une visionneuse unique pour l’événement.

Ces différences dans la méthodologie de comptage se trouvent également avec les plateformes non-Microsoft.

Anecdote

Une anecdote rapide pour illustrer les différences potentielles perçues. Dans un scénario de 45 minutes où un ingénieur Microsoft eCDN a utilisé un seul compte de test sur un événement de test, connectant et déconnectant plusieurs sessions d’affichage simultanées, le nombre total d’affichages du rapport d’utilisation TLE était de 19, tandis que Microsoft eCDN Analytics a signalé une visionneuse unique avec déchargement de peering.

Utilisateurs iOS

Actuellement, Microsoft eCDN ne prend pas en charge la plateforme iOS. Par conséquent, les visionneuses iOS ne participent pas au peering. Leur expérience d’affichage n’est pas impactée, mais cette mise en garde peut entraîner une réduction du nombre de visionneuses.