Azure Stack HCI 23H2 (2311.2) : échec de l’extension LCM Controller — diagnostic, correctifs et automatisation

Sur Azure Stack HCI 23H2 (build 2311.2), l’extension LCM Controller peut refuser de s’installer sur certains nœuds. Voici une méthode pragmatique et reproductible pour diagnostiquer, corriger et harmoniser tout le cluster sans perturber la production.

Sommaire

Contexte et périmètre

Dans plusieurs déploiements Azure Stack HCI 23H2 (2311.2), des nœuds d’un même cluster échouent à installer ou charger l’extension LCM Controller (Lifecycle Management Controller) malgré des désinstallations/réinstallations locales. Le comportement touche des hôtes Arc connectés et ne se manifeste pas toujours sur tous les serveurs, ce qui laisse le cluster dans un état hétérogène (certaines machines « OK », d’autres « KO »).

Symptômes typiques

Dans le Portail Azure → Machines Arc → Extensions, l’extension LCM Controller reste en Failed, Creating, Installing ou Unresponsive.
Les tentatives de réinstallation depuis la machine elle‑même échouent ou bouclent (aucune progression côté portail).
Les journaux Arc indiquent des erreurs d’invocation de handler, de dépendances ou de timeout.
Le cluster n’est pas aligné : un ou plusieurs nœuds n’exposent pas l’extension attendue, empêchant un déploiement homogène des fonctionnalités qui en dépendent.

Résumé exécutif

Bonne nouvelle : il s’agit d’un problème connu sur des environnements 23H2/2311.2. Un workaround fiable consiste à désinstaller l’extension depuis le Portail puis à la réinstaller à distance via Azure Cloud Shell / Azure CLI, en reprenant publisher/type/version d’un nœud sain. Cette méthode a permis de débloquer des nœuds « récalcitrants » et d’aligner le cluster. Ensuite, prévoir le déploiement de la prochaine version de l’extension dès sa disponibilité pour pérenniser le correctif.

Pourquoi ce contournement fonctionne

La réinstallation à distance (depuis Cloud Shell/CLI) contourne les échecs observés lors d’installations locales liées au contexte de session, à la concurrence d’installations, à des verrous de fichier/sous‑processus ou à des résidus d’état. Le Portail/CLI orchestre l’opération côté service Arc et pousse les bons paramètres de manière idempotente, ce qui évite les conflits locaux et synchronise l’état ressource ↔ machine.

Procédure recommandée (pas‑à‑pas)

Objectif : supprimer proprement l’extension LCM Controller sur les nœuds en échec puis la réinstaller à distance avec exactement les mêmes paramètres (publisher/type/version) que sur un nœud où elle fonctionne déjà.

1) Récupérer les valeurs de référence sur un nœud « OK »

Dans Azure Cloud Shell (Bash) ou une station avec Azure CLI :

# Liste des extensions sur un nœud sain
az connectedmachine extension list \
  --resource-group &lt;RG&gt; \
  --machine-name &lt;NOM_NOEUD_OK&gt; -o table

Notez précisément : name, publisher, type, typeHandlerVersion.

Pour extraire automatiquement ces valeurs :

# (Optionnel) Extraction directe des propriétés utiles
az connectedmachine extension show \
  --resource-group &lt;RG&gt; \
  --machine-name &lt;NOM_NOEUD_OK&gt; \
  --name &lt;NOM_EXTENSION_LCM&gt; \
  --query "{name:name,publisher:publisher,type:type,version:typeHandlerVersion}" -o tsv

2) Désinstaller l’extension sur le(s) nœud(s) « KO »

az connectedmachine extension delete \
  --resource-group &lt;RG&gt; \
  --machine-name &lt;NOM_NOEUD_KO&gt; \
  --name &lt;NOM_EXTENSION_LCM&gt;

Vérifiez dans le Portail/CLI que l’extension n’apparaît plus pour la machine ciblée avant de poursuivre.

3) Réinstaller l’extension à distance avec les mêmes paramètres

az connectedmachine extension create \
  --resource-group &lt;RG&gt; \
  --machine-name &lt;NOM_NOEUD_KO&gt; \
  --location &lt;REGION&gt; \
  --name &lt;NOM_EXTENSION_LCM&gt; \
  --publisher "&lt;PUBLISHER&gt;" \
  --type "&lt;TYPE&gt;" \
  --type-handler-version "&lt;VERSION&gt;"

4) Contrôler l’état jusqu’au succès

az connectedmachine extension show \
  --resource-group &lt;RG&gt; \
  --machine-name &lt;NOM_NOEUD_KO&gt; \
  --name &lt;NOM_EXTENSION_LCM&gt; -o table
# Attendu : provisioningState = Succeeded

Astuce « watch » (optionnel)

# Boucle d'attente simple (timeout 15 min)
DELAI=900; PAS=10; t0=$(date +%s)
while true; do
  ETAT=$(az connectedmachine extension show \
    --resource-group &lt;RG&gt; \
    --machine-name &lt;NOM_NOEUD_KO&gt; \
    --name &lt;NOM_EXTENSION_LCM&gt; \
    --query "provisioningState" -o tsv 2&gt;/dev/null)
  echo "Etat courant: $ETAT"
  if [ "$ETAT" = "Succeeded" ] || [ "$ETAT" = "Failed" ]; then break; fi
  [ $(($(date +%s)-t0)) -gt $DELAI ] &amp;&amp; { echo "Timeout atteint."; break; }
  sleep $PAS
done

Check‑list express avant/après

Contrôle	Commande / Action	Résultat attendu
Agent Arc prêt	`"C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe" check`	Connectivité OK, dépendances validées
Journaux agent	`"C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe" logs`	Archive générée (utile pour l’escalade)
Service agent	`Restart-Service -Name AzureConnectedMachineAgent -Force`	Service redémarré sans erreur
Extension supprimée	`az connectedmachine extension delete ...`	Plus de trace de l’extension côté Portail/CLI
Extension réinstallée	`az connectedmachine extension create ...`	provisioningState = Succeeded

Automatisation multi‑nœuds (script prêt à l’emploi)

Ce script Bash pour Azure Cloud Shell récupère les paramètres sur un nœud sain, puis applique la séquence delete → create sur une liste de nœuds « KO ».

#!/usr/bin/env bash
set -euo pipefail

RG="\"
REGION="\"
NODE\_OK="\"
EXT\_NAME="\"

# Liste des nœuds à corriger (séparés par des espaces)

BAD\_NODES=("NODE1" "NODE2" "NODE3")

read PUBLISHER TYPE VERSION < <(az connectedmachine extension show 
\--resource-group "\$RG" 
\--machine-name "\$NODE\_OK" 
\--name "\$EXT\_NAME" 
\--query "\[publisher,type,typeHandlerVersion]" -o tsv)

echo "Référence : publisher=\$PUBLISHER type=\$TYPE version=\$VERSION"

for NODE in "\${BAD\_NODES\[@]}"; do
echo "==== Traitement de \$NODE ===="
set +e
az connectedmachine extension delete 
\--resource-group "\$RG" 
\--machine-name "\$NODE" 
\--name "\$EXT\_NAME"
set -e

az connectedmachine extension create 
\--resource-group "\$RG" 
\--machine-name "\$NODE" 
\--location "\$REGION" 
\--name "\$EXT\_NAME" 
\--publisher "\$PUBLISHER" 
\--type "\$TYPE" 
\--type-handler-version "\$VERSION"

az connectedmachine extension show 
\--resource-group "\$RG" 
\--machine-name "\$NODE" 
\--name "\$EXT\_NAME" 
\--query "{node\:name, state\:provisioningState, version\:typeHandlerVersion}" -o table
done

echo "Terminé."

Variante PowerShell (sur poste admin avec Azure CLI)

$RG = "<RG>"
$Region = "<REGION>"
$NodeOK = "<NOM_NOEUD_OK>"
$ExtName = "<NOM_EXTENSION_LCM>"
$BadNodes = @("NODE1","NODE2","NODE3")

\$ref = az connectedmachine extension show `  --resource-group $RG`
\--machine-name \$NodeOK `  --name $ExtName`
\--query "{publisher\:publisher,type\:type,version\:typeHandlerVersion}" -o json | ConvertFrom-Json

\$pub = \$ref.publisher; \$type = \$ref.type; \$ver = \$ref.version
Write-Host "Référence : publisher=\$pub type=\$type version=\$ver"

foreach (\$n in \$BadNodes) {
Write-Host "==== Traitement de \$n ===="
az connectedmachine extension delete --resource-group \$RG --machine-name \$n --name \$ExtName | Out-Null
az connectedmachine extension create `    --resource-group $RG`
\--machine-name \$n `    --location $Region`
\--name \$ExtName `    --publisher $pub`
\--type \$type \`
\--type-handler-version \$ver | Out-Null

az connectedmachine extension show `    --resource-group $RG`
\--machine-name \$n `    --name $ExtName`
\--query "{node\:name, state\:provisioningState, version\:typeHandlerVersion}" -o table
}

Dépannage complémentaire utile

1) Santé de l’agent Arc & réseau

"C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe" check
"C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe" logs
Restart-Service -Name AzureConnectedMachineAgent -Force

check valide la connectivité sortante requise et les dépendances système (proxies, filtrage URL, certificats).
logs produit une archive à fournir au support en cas d’escalade.
En environnement proxy, vérifiez l’application des paramètres système et des exclusions no_proxy si nécessaire.

2) Journaux côté Windows

Event Viewer : Applications and Services Logs → Microsoft-Azure-ConnectedMachine-Agent/Admin.
Dossiers utiles :
- C:\ProgramData\AzureConnectedMachineAgent\Log\
- C:\ProgramData\AzureConnectedMachineAgent\Extensions\

3) Nettoyage d’état résiduel

Toujours préférer az connectedmachine extension delete plutôt que des suppressions manuelles dans le système de fichiers.
Assurez‑vous que l’extension n’apparaît plus (Portail/CLI) avant de relancer l’installation.
Fermez les sessions RDP/console : la déconnexion lève souvent des verrous sur des composants invoqués par l’extension.

4) Version du cluster & état de conformité

Confirmez que l’environnement est bien en 23H2 avec les dernières mises à jour cumulatives. Certains correctifs d’extensions supposent un niveau minimal.
Évitez les mélanges de versions d’extensions dans un même cluster : harmonisez publisher/type/version sur tous les nœuds.

Carte mentale du diagnostic (cause → action)

Cause probable	Indicateurs	Action corrective
Résidu d’état d’une tentative précédente	Extension « Deleting/Installing » persistante	Désinstallation via CLI → réinstallation à distance
Conflit de contexte (session interactive)	Échec local, succès depuis Cloud Shell	Se déconnecter des nœuds, opérer depuis le Portail/CLI
Dépendance agent Arc	`azcmagent check` non conforme	Corriger connectivité/proxy, redémarrer le service agent
Version d’extension non homogène	Nœuds OK et KO avec versions différentes	Réutiliser publisher/type/version du nœud de référence
Niveau de build insuffisant	Nœud sans dernières CU 23H2	Appliquer mises à jour, relancer la procédure

Bonnes pratiques pour des déploiements robustes

Paramètres figés : conservez dans un dépôt interne un fichier texte/JSON listant publisher/type/version de référence pour le cluster.
Automatiser : encapsulez la séquence delete → create dans un pipeline (Cloud Shell/DevOps) à rejouer pour tout nouveau nœud.
Observabilité : mettez en place une requête récurrente (CLI/Graph) pour remonter l’état des extensions et alerter sur « Failed ».
Sécurité des changements : opérez par petits lots (2 nœuds), validez, puis élargissez.
Anticiper : planifiez le déploiement de la prochaine version de l’extension dès sa publication pour pérenniser le correctif.

FAQ

Faut‑il impérativement se déconnecter des nœuds ?

Ce n’est pas toujours obligatoire, mais cela supprime un facteur d’échec fréquent (verrous et processus hérités d’une session interactive). C’est une étape peu coûteuse et souvent décisive.

Puis‑je installer une version plus récente que celle du nœud « OK » ?

Le contournement le plus sûr consiste à répliquer la combinaison publisher/type/version qui fonctionne déjà. Vous pourrez ensuite aligner tout le monde sur la prochaine version une fois validée.

Combien de temps laisser à l’installation ?

Sur la plupart des environnements, l’état passe à Succeeded en quelques minutes. Si l’état reste bloqué (ex. Creating) alors que la connectivité est saine, relancez la séquence delete → create et consultez les journaux agent/extension.

Dois‑je forcer un redémarrage de l’hôte ?

Non, pas par défaut. En revanche, un redémarrage du service Azure Connected Machine Agent (Restart-Service ...) peut clarifier une situation ambigüe sans impacter les charges de travail.

Modèles & snippets utiles

Extraction avancée (JSON complet de l’extension)

az connectedmachine extension show \
  --resource-group &lt;RG&gt; \
  --machine-name &lt;NOM_NOEUD&gt; \
  --name &lt;NOM_EXTENSION_LCM&gt; -o json

Liste condensée de l’état des nœuds

for N in NODE1 NODE2 NODE3; do
  az connectedmachine extension show \
    --resource-group &lt;RG&gt; \
    --machine-name "$N" \
    --name &lt;NOM_EXTENSION_LCM&gt; \
    --query "{node:name, state:provisioningState, version:typeHandlerVersion}" -o table
done

Contrôle côté Windows (journalisation extension)

# Explorer rapidement les derniers événements Arc Agent
Get-WinEvent -LogName "Microsoft-Azure-ConnectedMachine-Agent/Admin" -MaxEvents 100 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

En bref

Symptôme : échec d’installation/chargement de LCM Controller sur Azure Stack HCI 23H2 (2311.2), souvent sur un sous‑ensemble de nœuds.
Problème connu : oui, observé sur cette build.
Workaround éprouvé : logout des sessions, désinstallation via le Portail, réinstallation à distance via Azure CLI/Cloud Shell en réutilisant les paramètres d’un nœud sain.
À vérifier : agent Arc à jour, connectivité réseau, journaux, niveau de build (dernières CU 23H2).
À prévoir : déployer la prochaine version de l’extension dès sa disponibilité pour éliminer définitivement le comportement observé.

Annexe : grille d’interprétation des états

provisioningState	Interprétation	Action
`Succeeded`	Extension installée et opérationnelle	Aucune, passer au nœud suivant
`Failed`	Le handler a échoué	Consulter journaux, rejouer la séquence delete → create
`Creating` / `Installing`	Installation en cours	Patienter quelques minutes, sinon relancer la séquence
`Deleting`	Suppression en cours	Réessayer après stabilisation, vérifier connectivité

Conclusion

Pour les échecs de l’extension LCM Controller sur Azure Stack HCI 23H2 (2311.2), la démarche la plus efficace est opérationnelle et répétable : se déconnecter des nœuds, supprimer l’extension via le Portail, puis réinstaller à distance via Azure CLI en calquant publisher/type/version sur un nœud de référence. Ajoutez un contrôle de l’agent Arc et des journaux, industrialisez la séquence pour plusieurs hôtes, et planifiez l’adoption de la prochaine version de l’extension afin d’assainir durablement le cluster.