Résoudre les problèmes de Cache connecté Microsoft pour les entreprises et l’éducation

Cet article contient des instructions sur la façon de résoudre les différents problèmes que vous pouvez rencontrer lors de l’utilisation du cache connecté. Ces problèmes sont classés par tâche dans laquelle ils peuvent être rencontrés.

Problèmes connus

Cette section décrit les problèmes connus liés à la dernière version de Cache connecté Microsoft pour les entreprises et l’éducation. Pour plus d’informations sur les correctifs inclus dans la dernière version, consultez la page Notes de publication.

La ressource de Azure cache connecté est manquante dans la sélection de l’étendue sous l’onglet « Métriques »

Vous pouvez créer des graphiques personnalisés sur l’Portail Azure Cache connecté en sélectionnant l’onglet Métriques sous la section Surveillance de la ressource De Azure cache connecté. La ressource Connected Cache Azure est correctement sélectionnée comme étendue par défaut, mais si vous modifiez l’étendue sélectionnée, vous ne pouvez pas sélectionner à nouveau la ressource Connected Cache Azure, ce qui empêche la création ultérieure de graphiques personnalisés.

En guise de solution de contournement temporaire, vous pouvez vous éloigner de l’onglet Métriques , puis y revenir. La ressource Connected Cache Azure est à nouveau sélectionnée correctement comme étendue.

limitations importCert.ps1

Le importCert.ps1 script est utilisé pour importer des certificats dans le magasin de certificats Windows dans le cadre du processus de configuration HTTPS pour les nœuds de cache hébergés par Windows. L’application Windows cache connecté v1.0.24.0 ne prend pas en charge l’exécution de ce script sur les nœuds de cache déployés vers Windows Server 2022 ou Windows Server 2025 avec un compte d’exécution du cache connecté gMSA. Utilisez l’application v1.0.26.0 ou une version ultérieure pour exécuter ce script dans ces environnements.

Limitations de l’application Windows Installer du cache connecté

L’application Windows Du cache connecté est un package MSIX qui est utilisé pour déployer le cache connecté sur les machines hôtes Windows. Actuellement, l’application du programme d’installation ne prend pas en charge Windows Server Core.

Corrigé dans la dernière version

Version en disponibilité générale : 23/07/2025

• L’installation du cache connecté échoue lorsque l’ordinateur hôte Windows est configuré avec des paramètres régionaux non-EN.
• Les nœuds de cache connecté hébergés par Windows peuvent dépasser leur taille de lecteur de cache configurée.

Étapes d’obtention d’un ID d’abonnement Azure

1. Connectez-vous au Portail Azure.
2. Sélectionnez Abonnements. Si vous ne voyez pas Abonnements, tapez Abonnements dans la barre de recherche. Lorsque vous commencez à taper, la liste filtre en fonction de votre entrée.
3. Si vous disposez déjà d’un abonnement Azure, passez à l’étape 5. Si vous n’avez pas d’abonnement Azure, sélectionnez + Ajouter en haut à gauche.
4. Sélectionnez l’abonnement Paiement à l’utilisation . Vous serez invité à entrer des informations de crédit carte, mais vous ne serez pas facturé pour l’utilisation du service Microsoft Connected Cache.
5. Dans la page Abonnements , vous trouverez des détails sur votre abonnement actuel. Sélectionnez le nom de l’abonnement.
6. Une fois que vous avez sélectionné le nom de l’abonnement, vous trouverez l’ID d’abonnement sous l’onglet Vue d’ensemble . Sélectionnez l’icône Copier dans le Presse-papiers en regard de votre ID d’abonnement pour copier la valeur.

Résolution des problèmes de création de ressources Azure

La création de ressources du cache connecté Azure peut être lancée à l’aide de l’interface utilisateur Portail Azure ou du jeu de commandes CLI Azure.

Si vous rencontrez une erreur lors de la création de la ressource, case activée que vous disposez des autorisations nécessaires pour créer des ressources Azure sous votre abonnement et que vous avez rempli tous les champs obligatoires pendant le processus de création de la ressource.

Résolution des problèmes de configuration du nœud de cache

La configuration de votre nœud Cache connecté peut être effectuée à l’aide de l’interface utilisateur Portail Azure ou de l’ensemble de commandes CLI Azure.

Si vous rencontrez une erreur de validation, case activée que vous avez rempli tous les champs de configuration requis.

Si votre configuration ne semble pas prendre effet, case activée que vous avez sélectionné l’option Enregistrer en haut de la page de configuration dans l’interface utilisateur Portail Azure.

Si vous avez modifié la configuration du proxy, vous devez redéployer le logiciel cache connecté sur l’ordinateur hôte pour que la configuration du proxy prenne effet.

Résolution des problèmes de déploiement de nœud de cache sur l’ordinateur hôte Windows

Collecte des journaux d’installation hébergés par Windows

Le déploiement d’un nœud Cache connecté sur un ordinateur hôte Windows implique l’exécution d’une série de scripts PowerShell contenus dans l’application Windows De cache connecté. Ces scripts tentent d’écrire des fichiers journaux dans le répertoire de script de l’application de cache connecté, spécifié par deliveryoptimization-cli mcc-get-scripts-path.

Il existe trois types de fichiers journaux d’installation :

1. WSL_Mcc_Install_Transcript : ce fichier journal enregistre les lignes imprimées dans la fenêtre PowerShell lors de l’exécution du script d’installation
2. WSL_Mcc_Install_FromRegisteredTask_Status : ce fichier journal enregistre les status de haut niveau écrites pendant l’installation des tâches inscrites
3. WSL_Mcc_Install_FromRegisteredTask_Transcript : ce fichier journal enregistre les status détaillées écrites pendant l’installation des tâches inscrites

La transcription de la tâche inscrite est généralement la plus utile pour diagnostiquer le problème d’installation.

Collecte d’autres journaux hébergés par Windows

Une fois que le nœud de cache a été correctement installé sur l’ordinateur hôte Windows, il écrit régulièrement des fichiers journaux dans le répertoire d’installation (C:\mccwsl01\ par défaut).

Vous pouvez vous attendre à voir les types de fichiers journaux suivants :

1. WSL_Mcc_Monitor_FromRegisteredTask_Transcript : ce fichier journal enregistre la sortie de la tâche planifiée « MCC_Monitor_Task » chargée de s’assurer que le cache connecté continue de s’exécuter.
2. WSL_Mcc_UserUninstall_Transcript : ce fichier journal enregistre la sortie du script « uninstallmcconwsl.ps1 » que l’utilisateur peut exécuter pour désinstaller le logiciel Connected Cache de l’ordinateur hôte.
3. WSL_Mcc_Uninstall_FromRegisteredTask_Transcript : ce fichier journal enregistre la sortie de la tâche planifiée « MCC_Uninstall_Task » qui est chargée de désinstaller le logiciel de cache connecté de l’ordinateur hôte lorsqu’elle est appelée par le script « uninstallmcconwsl.ps1 ».

Lancement d’un processus PowerShell en tant que compte d’exécution du cache connecté

Pour résoudre les problèmes liés au logiciel cache connecté sur un ordinateur hôte Windows, vous devrez peut-être exécuter des commandes en tant que compte d’exécution du cache connecté. Pour ce faire, vous pouvez lancer un processus PowerShell en tant que compte d’exécution spécifié lors de l’installation du cache connecté.

• Si le compte runtime est un compte local, vous pouvez lancer un processus PowerShell en tant que compte d’exécution en exécutant la commande suivante dans une fenêtre PowerShell avec élévation de privilèges :

  Start-Process powershell.exe -Credential (Get-Credential "<RuntimeAccountName>") -ArgumentList '-NoExit'
  

• Si le compte runtime est un compte de domaine ou de service, vous pouvez lancer un processus PowerShell en tant que compte d’exécution en exécutant la commande suivante dans une fenêtre PowerShell avec élévation de privilèges :

  Start-Process powershell.exe -Credential (Get-Credential "<Domain>\<RuntimeAccountName>") -ArgumentList '-NoExit'
  

• Si le compte d’exécution est un compte de service administré de groupe (gMSA), vous devez utiliser PsExec pour lancer un processus PowerShell en tant que compte d’exécution en exécutant la commande suivante dans une fenêtre PowerShell avec élévation de privilèges :

  psexec.exe -i -u <DOMAIN\GmsaAccountName$> -p ~ powershell.exe 
  

Vérification si le conteneur de cache connecté est en cours d’exécution

Une fois que le logiciel de cache connecté a été correctement déployé sur l’ordinateur hôte Windows, vous pouvez case activée si le nœud de cache s’exécute correctement en procédant comme suit sur l’ordinateur hôte Windows :

1. Lancez un processus PowerShell en tant que compte spécifié en tant que compte d’exécution pendant l’installation du cache connecté
2. Exécutez wsl -d Ubuntu-24.04-Mcc pour accéder à la distribution Linux qui héberge le conteneur de cache connecté
3. Exécuter sudo iotedge list pour afficher les conteneurs en cours d’exécution dans le runtime IoT Edge

S’il affiche les conteneurs edgeAgent et edgeHub, mais n’affiche pas MCC, vous pouvez afficher les status du gestionnaire de sécurité IoT Edge à l’aide sudo iotedge system logs -- -fde .

Vous pouvez également redémarrer le runtime IoT Edge à l’aide de sudo iotedge system restart. Consultez IoT Edge documentation sur la résolution des problèmes pour plus d’informations sur la résolution des problèmes du runtime IoT Edge.

Échec de l’installation du cache connecté lors de l’inscription du nœud de cache

Dans le cadre du processus d’installation sur les ordinateurs hôtes Windows, le cache connecté tente de s’inscrire auprès du service d’optimisation de la distribution en appelant un point de terminaison geomcc.prod.do.dsp.mp.microsoft.comd’inscription . Cet appel provient de la distribution WSL2 qui héberge le conteneur de cache connecté et doit réussir pour que le nœud de cache soit installé.

Pour résoudre les problèmes de connexion, vous pouvez essayer d’exécuter les commandes suivantes à partir d’une fenêtre PowerShell avec élévation de privilèges en tant que compte d’exécution du cache connecté.

Tout d’abord, accédez à la distribution WSL2 qui héberge le conteneur De cache connecté :

wsl -d Ubuntu-24.04-Mcc

Ensuite, exécutez la commande bash suivante pour case activée résolution DNS du point de terminaison d’inscription :

nslookup geomcc.prod.do.dsp.mp.microsoft.com

Vérifiez la connectivité TCP (port 443 pour HTTPS) au point de terminaison d’inscription :

nc -vz geomcc.prod.do.dsp.mp.microsoft.com 443

Vérifiez la réponse HTTPS à partir du point de terminaison d’inscription :

curl -v https://geomcc.prod.do.dsp.mp.microsoft.com

MCC_Install_Task tâche planifiée ne parvient pas à s’exécuter

L’installation du cache connecté sur les machines hôtes Windows s’appuie sur la tâche planifiée « MCC_Install_Task » pour effectuer des actions d’installation en tant que compte d’exécution du cache connecté désigné. Si cette tâche ne parvient pas à s’exécuter, cela peut être dû à l’une des raisons suivantes.

stratégie de groupe l’objet est en conflit avec l’inscription de tâches planifiées

L’activation de l’objet stratégie de groupe : Accès réseau : Ne pas autoriser le stockage des mots de passe et des informations d’identification pour l’authentification réseau empêche le logiciel du cache connecté d’inscrire les tâches planifiées nécessaires à la réussite de l’inscription et du fonctionnement des nœuds de cache.

Le compte d’exécution MCC ne dispose pas des autorisations nécessaires pour se connecter en tant que travail par lots

Vérifiez que vous avez accordé au compte d’exécution du cache connecté l’autorisation « Ouvrir une session en tant que travail par lots ». Cette autorisation est requise pour que le compte d’exécution du cache connecté exécute des tâches planifiées.

La stratégie de sécurité d’entreprise empêche l’exécution de scripts PowerShell

Vérifiez que la stratégie d’exécution PowerShell sur l’ordinateur hôte Windows autorise l’exécution de scripts. Vous pouvez case activée la stratégie d’exécution actuelle en exécutant la commande suivante dans une fenêtre PowerShell avec élévation de privilèges :

Get-ExecutionPolicy

L’inscription de la tâche planifiée MCC échoue avec une erreur d’informations d’identification gMSA

Si vous voyez une erreur d’installation indiquant que le nom d’utilisateur ou le mot de passe gMSA est incorrect lors de la tentative d’inscription des tâches planifiées MCC, le problème peut être dû à une incompatibilité dans le type de chiffrement Kerberos entre l’ordinateur hôte MCC et le contrôleur de domaine. Pour résoudre ce problème, le type de chiffrement sur le compte gMSA doit être mis à jour pour correspondre au type de chiffrement configuré sur le contrôleur de domaine.

Vous pouvez case activée et aligner ces paramètres en consultant la stratégie Sécurité réseau : Configurer les types de chiffrement autorisés pour Kerberos sur le contrôleur de domaine et l’attribut du msDS-SupportedEncryptionTypes compte gMSA. Contactez votre équipe Active Directory pour mettre à jour le type de chiffrement du compte gMSA pour qu’il corresponde au contrôleur de domaine.

L’installation de WSL2 échoue avec le message « Une session d’ouverture de session spécifiée n’existe pas »

Si vous rencontrez ce message d’échec lors de la tentative d’exécution de la commande wsl.exe --install --no-distribution PowerShell sur votre ordinateur hôte Windows, vérifiez que vous êtes connecté en tant qu’administrateur local et que vous exécutez la commande à partir d’une fenêtre PowerShell avec élévation de privilèges.

Mise à jour du noyau WSL2

Si l’installation du cache connecté échoue en raison de problèmes liés à WSL, essayez d’exécuter wsl.exe --update pour obtenir la dernière version du noyau WSL.

MCC_Monitor_Task tâche planifiée ne parvient pas à s’exécuter

Une fois le conteneur de cache connecté en cours d’exécution, la tâche planifiée MCC_Monitor_Task s’exécute régulièrement sous le compte d’exécution du cache connecté pour empêcher WSL d’arrêter la distribution WSL du cache connecté. Si votre nœud de cache passe hors connexion sans aucune action de l’utilisateur, cela peut être dû au fait que la tâche planifiée « MCC_Monitor_Task » ne s’exécute pas correctement.

Vous pouvez utiliser le planificateur de tâches sur l’ordinateur hôte pour case activée la status de cette tâche planifiée.

1. Ouvrir le planificateur de tâches sur l’ordinateur hôte
2. Accédez à la section Tâches actives et double-cliquez sur MCC_Monitor_Task
3. Vérifiez les colonnes Heure de la dernière exécution et Résultat de la dernière exécution pour voir si l’opération s’est terminée correctement.
4. Sélectionnez l’onglet Déclencheurs et vérifiez que l’état est Activé
5. Sélectionnez l’onglet Historique et case activée pour les erreurs ou avertissements liés à l’exécution de la tâche.

Si le MCC_Monitor_Task ne parvient pas à s’exécuter correctement, cela peut être dû à l’expiration des informations d’identification du compte d’exécution du cache connecté. Dans ce cas, vous pouvez utiliser le updatetaskpasswords.ps1 script pour mettre à jour les informations d’identification.

1. Ouvrez un processus PowerShell en tant qu’administrateur.

2. Remplacez le répertoire par le répertoire de script et vérifiez la présence de updatetaskpasswords.ps1.

   • Si vous avez installé le cache connecté à l’aide du package de déploiement de la préversion publique, le répertoire de script se trouve dans le dossier d’installation spécifié dans la commande de déploiement d’origine (« C :\mccwsl01\MccScripts » par défaut).
   • Si vous avez installé le cache connecté à l’aide de l’application Windows Cache connecté, le répertoire de script se trouve dans le répertoire retourné par deliveryoptimization-cli mcc-get-scripts-path.

3. Créez un objet PSCredential nommé $myLocalAccountCredential représentant le compte d’exécution du cache connecté avec le nouveau mot de passe.

4. Exécutez le updatetaskpasswords.ps1 script avec la commande suivante :

   .\updatetaskpasswords.ps1 -Credential $myLocalAccountCredential
   

Nœud de cache correctement déployé, mais ne répondant pas aux demandes

Si votre nœud de cache ne répond pas aux requêtes en dehors de localhost, cela peut être dû au fait que les règles de transfert de port de l’ordinateur hôte n’ont pas été correctement définies lors de l’installation du cache connecté. Étant donné que WSL2 utilise une carte Ethernet virtualisée par défaut, des règles de transfert de port sont nécessaires pour autoriser le trafic à atteindre le instance WSL2 à partir de votre réseau local. Pour plus d’informations, consultez Accès aux applications réseau avec WSL.

Le cache connecté utilise netsh portproxy pour définir des règles de transfert de port qui dirigent le trafic de l’adresse IP de l’ordinateur hôte vers la distribution WSL exécutant le conteneur MCC. Le service Windows IP Helper doit être activé pour que ces règles fonctionnent. Si le service IP Helper est désactivé, les règles de transfert de port définies via netsh portproxy ne prendront pas effet et le conteneur MCC ne recevra aucune demande du client en dehors de localhost.

Get-Service -Name iphlpsvc | Select-Object Name, Status, StartType
Set-Service -Name iphlpsvc -StartupType Automatic
Start-Service -Name iphlpsvc

Pour case activée les règles de transfert de port de votre ordinateur hôte, utilisez la commande PowerShell suivante.

netsh interface portproxy show v4tov4

Si vous ne voyez aucune règle de transfert de port pour le port 80 vers 0.0.0.0, vous pouvez exécuter la commande suivante à partir d’un instance PowerShell avec élévation de privilèges pour définir le transfert approprié vers WSL.

netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=<WSL IP Address>

Vous pouvez récupérer l’adresse IP WSL à partir du wslip.txt fichier qui doit être présent dans le répertoire d’installation de l’application de cache connecté (C:\mccwsl01 par défaut).

Règles de transfert de port WSL manquantes (443, 5000)

Pour configurer correctement vos nœuds de cache hébergés par Windows pour prendre en charge HTTPS, vous devez créer une règle de transfert de port pour transférer le trafic du port 443 sur l’ordinateur hôte vers le port 443 sur la distribution WSL2 qui héberge le conteneur de cache connecté.

Pour accéder à distance à la page Résumé terse de votre nœud de cache hébergé par Windows, vous devez créer une règle de transfert de port pour transférer le trafic du port 5000 sur l’ordinateur hôte vers le port 5000 sur la distribution WSL2 qui héberge le conteneur de cache connecté.

Vous pouvez créer ces règles de transfert de port en exécutant les commandes suivantes dans une fenêtre PowerShell avec élévation de privilèges après avoir terminé le déploiement du nœud de cache.

$ipFilePath = Join-Path ([System.Environment]::GetEnvironmentVariable("MCC_INSTALLATION_FOLDER", "Machine")) "wslIp.txt"

$ipAddress = (Get-Content $ipFilePath | Select-Object -First 1).Trim()

netsh interface portproxy add v4tov4 listenport=443 listenaddress=0.0.0.0 connectport=443 connectaddress=$ipAddress
netsh interface portproxy add v4tov4 listenport=5000 listenaddress=0.0.0.0 connectport=5000 connectaddress=$ipAddress

Vous devez également vous assurer que le pare-feu de l’ordinateur hôte autorise le trafic entrant sur les ports 443 et 5000. Pour ce faire, exécutez les commandes suivantes dans une fenêtre PowerShell avec élévation de privilèges :

[void](New-NetFirewallRule -DisplayName "WSL2 Port Bridge (HTTPS)" -Direction Inbound -Action Allow -Protocol TCP -LocalPort "443")

[void](New-NetFirewallRule -DisplayName "WSL2 Port Bridge (HTTPS)" -Direction Outbound -Action Allow -Protocol TCP -LocalPort "443")

[void](New-NetFirewallRule -DisplayName "WSL2 Port Bridge (MCC SUMMARY)" -Direction Inbound -Action Allow -Protocol TCP -LocalPort "5000")

Le déploiement du nœud de cache sur Windows échoue avec « ERREUR : impossible de vérifier le certificat »

Si vous rencontrez une erreur lors du déploiement du nœud de cache indiquant « ERREUR : impossible de vérifier le certificat », cela peut être dû au proxy d’inspection TLS de votre réseau (par exemple, ZScaler) qui intercepte la communication entre le logiciel de cache connecté et le service d’optimisation de la distribution. Cette interception interrompt la chaîne de certificats et empêche le déploiement du cache connecté.

Pour résoudre ce problème, vous devez configurer votre environnement réseau pour autoriser les appels vers et depuis « *.prod.do.dsp.mp.microsoft.com » afin de contourner le proxy d’inspection TLS.

Vous devez également configurer les paramètres de proxy pour votre nœud de cache, puis placer le fichier de certificat de proxy (.pem) dans le chemin d’accès installationFolder souhaité et ajouter -proxyTlsCertificatePemFileName "mycert.pem" à la commande de déploiement. Par exemple, placez le fichier .pem dans C:\mccwsl01\mycert.pem et ajoutez -proxyTlsCertificatePemFileName "mycert.pem" à la commande de déploiement.

Résolution des problèmes de déploiement de nœud de cache sur Linux machine hôte

Le déploiement d’un nœud De cache connecté sur un ordinateur hôte Linux implique l’exécution d’une série de scripts Bash contenus dans le package de déploiement Linux.

Une fois que le logiciel de cache connecté a été correctement déployé sur l’ordinateur hôte Linux, vous pouvez case activée si le nœud de cache s’exécute correctement en procédant comme suit sur l’ordinateur hôte Linux :

1. Exécuter sudo iotedge list pour afficher les conteneurs en cours d’exécution dans le runtime IoT Edge

S’il affiche les conteneurs edgeAgent et edgeHub, mais n’affiche pas MCC, vous pouvez afficher les status du gestionnaire de sécurité IoT Edge à l’aide sudo iotedge system logs -- -fde .

Vous pouvez également redémarrer le runtime IoT Edge à l’aide de sudo systemctl restart iotedge.

Le déploiement du nœud de cache vers Linux échoue avec « ERREUR : impossible de vérifier le certificat »

Si vous rencontrez une erreur lors du déploiement du nœud de cache indiquant « ERREUR : impossible de vérifier le certificat », cela peut être dû au proxy d’inspection TLS de votre réseau (par exemple, ZScaler) qui intercepte la communication entre le logiciel de cache connecté et le service d’optimisation de la distribution. Cette interception interrompt la chaîne de certificats et empêche le déploiement du cache connecté.

Pour résoudre ce problème, vous devez configurer votre environnement réseau pour autoriser les appels vers et depuis « *.prod.do.dsp.mp.microsoft.com » afin de contourner le proxy d’inspection TLS.

Vous devez également configurer les paramètres de proxy pour votre nœud de cache, puis placer le fichier de certificat de proxy (.pem) dans le répertoire du package de déploiement extrait et ajouter proxytlscertificatepath="/path/to/pem/file" à la commande de déploiement.

Génération d’un bundle de prise en charge des diagnostics de nœud de cache

Vous pouvez générer un bundle de support avec des informations de diagnostic détaillées en exécutant le collectMccDiagnostics.sh script inclus dans le package d’installation.

Pour les machines hôtes Windows , vous devez effectuer les opérations suivantes :

1. Lancez un processus PowerShell en tant que compte spécifié en tant que compte d’exécution pendant l’installation du cache connecté

2. Remplacez le répertoire par le répertoire « MccScripts » dans le répertoire d’installation de l’application De cache connecté (spécifié dans la commande de déploiement, la valeur par défaut est C:\mccwsl01\MccScripts) et vérifiez la présence de collectmccdiagnostics.sh

3. Exécuter wsl bash collectmccdiagnostics.sh pour générer le bundle de prise en charge des diagnostics

4. Une fois le script terminé, notez la sortie de la console décrivant l’emplacement du bundle de prise en charge des diagnostics

   Par exemple, « Package correctement compressé, envoyez le fichier créé à l’adresse /etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz »

5. Exécutez la wsl cp commande pour copier le bundle de prise en charge à partir de l’emplacement de la distribution Ubuntu vers le système d’exploitation hôte Windows

   Par exemple, wsl cp /etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz /mnt/c/mccwsl01/SupportBundles/

Pour Linux ordinateurs hôtes, vous devez effectuer les opérations suivantes :

1. Remplacez le répertoire par le répertoire « MccScripts » dans le package de déploiement du cache connecté extrait et vérifiez la présence de collectmccdiagnostics.sh

2. Exécuter collectmccdiagnostics.sh pour générer le bundle de prise en charge des diagnostics

3. Une fois le script terminé, notez la sortie de la console décrivant l’emplacement du bundle de prise en charge des diagnostics

   Par exemple, « Package correctement compressé, envoyez le fichier créé à l’adresse /etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz »

Résolution des problèmes de configuration HTTPS

Si votre autorité de certification ne peut générer des certificats signés qu’aux formats .pem ou .cer, vous pouvez remplacer l’extension du fichier de certificat par .crt si le fichier est en encodage Base64.

Résolution des problèmes de surveillance des nœuds de cache

Les performances et les status des nœuds du cache connecté peuvent être surveillées à l’aide de l’interface utilisateur Portail Azure.

Si les visuels de surveillance de base de l’onglet Vue d’ensemble affichent des valeurs inattendues ou erronées, actualisez la fenêtre du navigateur. Si le problème persiste, case activée que vous avez configuré les filtres de nœud Intervalle de temps et Cache comme vous le souhaitez.

Notez que le status « Sain » est déterminé par la capacité du conteneur de cache connecté à communiquer correctement avec le service d’optimisation de la distribution. Si votre nœud de cache affiche des status « Non sains », case activée que le nœud de cache dispose d’une connectivité sortante vers Internet et peut atteindre les points de terminaison du service d’optimisation de la distribution.

L’status « Sain » indique uniquement si le conteneur de cache connecté peut communiquer avec le service d’optimisation de la distribution. Il ne vérifie pas que les appareils clients DO sur le réseau peuvent atteindre le nœud de cache. Un nœud « sain » peut toujours être inaccessible aux clients en raison de règles de pare-feu, d’écarts de transfert de port WSL2 ou de la segmentation du réseau.

Résolution des problèmes de connectivité du client au nœud de cache

Pour tester l’accessibilité du client, accédez à l’URL suivante à partir d’un appareil client sur le même réseau que le nœud de cache, en remplaçant par CacheNodeIPAddress l’adresse IP de votre nœud de cache :

http://[CacheNodeIPAddress]/filestreamingservice/files/7bc846e0-af9c-49be-a03d-bb04428c9bb5/Microsoft.png?cacheHostOrigin=dl.delivery.mp.microsoft.com

Reportez-vous à l’article Vérifier le nœud du cache pour obtenir des instructions plus détaillées.

Option DHCP 235 non récupérée en raison du paramètre LocalPolicyMerge

Si vous utilisez l’option DHCP 235 pour publier le nœud Cache connecté aux clients, le paramètre LocalPolicyMerge peut empêcher le client DHCP de récupérer l’option 235. Ce problème est particulièrement courant dans les scénarios d’approvisionnement Windows Autopilot où des bases de référence de sécurité sont appliquées.

Si les clients ne découvrent pas le nœud de cache via DHCP, case activée si le LocalPolicyMerge paramètre est configuré dans votre environnement. Si c’est le cas, envisagez de passer de la découverte de l’option DHCP 235 à la configuration directe de la stratégie DOCacheHost avec le nom d’hôte ou l’adresse IP du nœud de cache.

Diagnostiquer les échecs d’accessibilité du client

Si les clients sur le réseau ne parviennent toujours pas à atteindre le nœud de cache après avoir effectué les étapes de vérification ci-dessus, procédez comme suit pour diagnostiquer le problème.

Étape 1 : Vérifier que la tâche planifiée MCC_Monitor_Task a été exécutée

La MCC_Monitor_Task tâche planifiée est chargée de maintenir la distribution WSL du cache connecté en cours d’exécution sur les ordinateurs hôtes Windows. Si la tâche n’est pas en cours d’exécution, le nœud de cache peut être hors connexion, ce qui entraîne des échecs d’accessibilité du client.

1. Ouvrez le Planificateur de tâches sur l’ordinateur hôte Windows.
2. Dans la section Tâches actives , recherchez MCC_Monitor_Task.
3. Vérifiez les colonnes Heure de la dernière exécution et Résultat de la dernière exécution pour confirmer que la tâche s’est exécutée correctement.
4. Sélectionnez l’onglet Déclencheurs et vérifiez que l’état du déclencheur est Activé.

Si MCC_Monitor_Task ne parvient pas à s’exécuter, consultez la section MCC_Monitor_Task tâche planifiée ne parvient pas à s’exécuter pour connaître les étapes de résolution.

Étape 2 : Passer en revue WSL_Mcc_Monitor_FromRegisteredTask_Transcript.txt

Le WSL_Mcc_Monitor_FromRegisteredTask_Transcript.txt fichier journal enregistre la sortie de chaque MCC_Monitor_Task exécution et est utile pour déterminer si la distribution ou le conteneur WSL du cache connecté a rencontré une erreur.

1. Accédez au répertoire d’installation du cache connecté sur l’ordinateur hôte Windows.
   • Le répertoire d’installation par défaut est C:\mccwsl01\.
   • Vous pouvez confirmer le chemin exact en exécutant deliveryoptimization-cli mcc-get-scripts-path dans une fenêtre PowerShell avec élévation de privilèges.
2. Ouvrez WSL_Mcc_Monitor_FromRegisteredTask_Transcript.txt dans un éditeur de texte.
3. Passez en revue le journal pour rechercher les erreurs indiquant que la distribution WSL n’a pas pu démarrer ou que le conteneur de cache connecté s’est arrêté de manière inattendue.

Étape 3 : Valider la résolution DNS et la connectivité HTTP à b1.download.windowsupdate.com

Le nœud Cache connecté doit être en mesure d’atteindre amont points de terminaison de remise de contenu Microsoft afin de traiter les demandes adressées aux clients. Utilisez les commandes suivantes pour vérifier que l’hôte de nœud de cache peut résoudre et se connecter à b1.download.windowsupdate.com.

Nœuds de cache hébergés par Windows

1. Lancez un processus PowerShell en tant que compte d’exécution du cache connecté.

2. Accédez à la distribution WSL2 :

   wsl -d Ubuntu-24.04-Mcc
   

3. Vérifiez la résolution DNS :

   nslookup b1.download.windowsupdate.com
   

4. Vérifiez la connectivité HTTP :

   curl -v http://b1.download.windowsupdate.com
   

nœuds de cache hébergés par Linux

Exécutez les commandes suivantes directement sur l’ordinateur hôte Linux.

1. Vérifiez la résolution DNS :

   nslookup b1.download.windowsupdate.com
   

2. Vérifiez la connectivité HTTP :

   curl -v http://b1.download.windowsupdate.com
   

Si la résolution DNS échoue ou si la requête HTTP est bloquée, passez à l’étape 4 pour examiner les bloqueurs de couche réseau.

Étape 4 : Vérifier les paramètres de pare-feu, de proxy et d’inspection TLS

Si les vérifications DNS ou HTTP de l’étape 3 échouent, une ou plusieurs des configurations de couche réseau suivantes peuvent bloquer amont connectivité à partir de l’hôte du nœud de cache.

• Pare-feu : vérifiez que le trafic sortant sur les ports 80 et 443 à partir de l’ordinateur hôte du nœud de cache est autorisé. Reportez-vous à Points de terminaison d’optimisation de la distribution pour obtenir la liste complète des points de terminaison requis.
• Proxy : si votre environnement utilise un proxy, vérifiez que les paramètres de proxy du nœud de cache sont correctement configurés. Reportez-vous à la documentation de configuration des paramètres de proxy .
• Inspection TLS : si votre réseau utilise un proxy d’inspection TLS (par exemple, ZScaler), configurez-le pour contourner le trafic vers et depuis les points de *.do.dsp.mp.microsoft.com terminaison. Pour connaître les étapes de résolution, consultez Échec du déploiement du nœud de cache sur Windows avec « ERREUR : impossible de vérifier le certificat » ou Le déploiement du nœud de cache pour Linux échoue avec « ERREUR : impossible de vérifier le certificat ».
• Transfert de port WSL (nœuds hébergés par Windows uniquement) : vérifiez que les règles de transfert de port pour les ports 80 et 443 sont en place. Pour obtenir des instructions, consultez Règles de transfert de port WSL manquantes (443, 5000).

Étape 5 : Collecter des diagnostics

Si le problème persiste après avoir effectué les étapes précédentes, générez un bundle de support de diagnostic à partager avec le support Microsoft. Pour obtenir des instructions, consultez Génération d’un bundle de prise en charge des diagnostics de nœud de cache .

Mettre à jour Docker DNS pour utiliser votre propre programme de résolution DNS

Si votre nœud de cache hébergé Linux rencontre des problèmes de connectivité réseau, la mise à jour de la configuration DNS de Docker pour utiliser le propre programme de résolution DNS de votre organization peut résoudre le problème.

1. Ouvrez le fichier de configuration du démon Docker :

   nano /etc/docker/daemon.json
   

2. Mettez à jour le contenu du fichier pour inclure l’adresse IP du programme de résolution DNS de votre organization :

   "log-driver": "json-file", "log-opts": {"max-size": "10m","max-file": "3"},"dns":["<Your organization's DNS resolver IP address>"]
   

3. Enregistrez et fermez le fichier en utilisant Ctrl+X, puis Y pour confirmer.

4. Redémarrez Docker pour que la modification prenne effet :

   systemctl restart docker
   

5. Réexécutez la commande IoT Edge case activée pour valider la connectivité appropriée :

   iotedge check --verbose
   

Diagnostiquer et résoudre

Vous pouvez également utiliser la fonctionnalité Diagnostiquer et résoudre les problèmes fournie par l’interface Portail Azure. Cet onglet dans la ressource Microsoft Connected Cache Azure vous guide à travers quelques invites pour vous aider à affiner la solution à votre problème.