Résoudre les problèmes liés au cache connecté Microsoft pour les entreprises et l’éducation

S’applique à: ✅ Windows 11, ✅ Supported Linux distributions, ✅ Microsoft Connected Cache for Enterprise

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 Microsoft Connected Cache for Enterprise and Education. 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. Ce script ne prend actuellement pas en charge les nœuds de cache déployés sur Windows Server 2022 ou Windows Server 2025 avec un compte d’exécution du cache connecté gMSA.

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

Connectez-vous au Portail Azure.
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.
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.
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.
Dans la page Abonnements , vous trouverez des détails sur votre abonnement actuel. Sélectionnez le nom de l’abonnement.
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 :

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
WSL_Mcc_Install_FromRegisteredTask_Status : ce fichier journal enregistre les status de haut niveau écrites pendant l’installation des tâches inscrites
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 :

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.
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.
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 ».

Gestion 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 :

Lancez un processus PowerShell en tant que compte spécifié en tant que compte d’exécution pendant l’installation du cache connecté
Exécutez wsl -d Ubuntu-24.04-Mcc pour accéder à la distribution Linux qui héberge le conteneur de cache connecté
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.

É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’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.

Ouvrir le planificateur de tâches sur l’ordinateur hôte
Accédez à la section Tâches actives et double-cliquez sur MCC_Monitor_Task
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.
Sélectionnez l’onglet Déclencheurs et vérifiez que l’état est Activé
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.

Ouvrez un processus PowerShell en tant qu’administrateur.
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.
Créez un objet PSCredential nommé $myLocalAccountCredential représentant le compte d’exécution du cache connecté avec le nouveau mot de passe.
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.

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 un ordinateur hôte Linux

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 :

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

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

Remarque

Après avoir redéployé un nœud de cache Linux afin qu’il soit migré vers le conteneur de mise en production en disponibilité générale, l’utilisateur doit exécuter chmod 777 -R /cachedrivepath , puis redémarrer le conteneur sudo iotedge restart MCCde cache connecté . Sinon, le nœud redéployé sera opérationnel, mais les demandes de contenu échoueront.

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

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 :

Lancez un processus PowerShell en tant que compte spécifié en tant que compte d’exécution pendant l’installation du cache connecté
Remplacez le répertoire par le répertoire « MccScripts » dans le répertoire d’installation de l’application De cache connecté (spécifié par deliveryoptimization-cli mcc-get-scripts-path) et vérifiez la présence de collectmccdiagnostics.sh
Exécuter wsl bash collectmccdiagnostics.sh pour générer le bundle de prise en charge des diagnostics
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 »
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 les machines hôtes Linux , vous devez effectuer les opérations suivantes :

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
Exécuter collectmccdiagnostics.sh pour générer le bundle de prise en charge des diagnostics
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.

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.

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2025-12-08