Intune GRS : pourquoi il ne faut pas supprimer une clé de registre à l’aveugle

Résumé opérationnel

Sous HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps, l’IME conserve des états applicatifs et des informations de temporisation. Dans GRS, l’AppId observé est le nom d’une propriété REG_SZ placée sous une sous-clé opaque; ce n’est pas nécessairement une clé nommée avec l’AppId.

Une propriété GRS peut rester après un succès, exister dans plusieurs contextes ou partager son conteneur avec d’autres applications. Supprimer la sous-clé entière peut donc toucher plusieurs déploiements et détruire la chronologie.

Je n’envisage une nouvelle tentative qu’après avoir prouvé un échec terminal courant, corrigé sa cause, classé tous les candidats GRS et préparé une sauvegarde et un rollback. L’observation reste la méthode normale.

Sous HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps, l’IME conserve des états applicatifs et des informations de temporisation. Dans GRS, l’AppId observé est le nom d’une propriété REG_SZ placée sous une sous-clé opaque; ce n’est pas nécessairement une clé nommée avec l’AppId.

Symptôme, contexte et périmètre de l’incident

Le besoin de relancer rapidement une application est légitime, mais GRS n’est pas une interface publique de remédiation documentée. Sa structure et sa sémantique peuvent évoluer avec l’IME.

Les recettes copiées d’un cas particulier échouent lorsqu’elles confondent l’état d’une application, le cache de reporting et la temporisation. Elles peuvent également provoquer une nouvelle tentative avant que la détection ou le package soit corrigé.

• applications Win32 prises en charge par l’IME
• états locaux Win32Apps et GRS
• observation et décision de support

Questions à résoudre et méthode de diagnostic

Pour Comprendre le GRS Intune avant toute action, l’enquête suit le parcours Policy → Enforcement → State → GRS. L’étape utile n’est pas celle qui affiche le dernier message: c’est la première dont le résultat ne correspond plus au fonctionnement attendu.

Les premiers contrôles portent sur AppId et révision exacts, dernier code d’enforcement et résultat de détection actuel. Ils permettent de dater le problème et de séparer un défaut de ciblage, de transport ou d’exécution avant d’envisager une correction.

Les symptômes « App installée mais GRS présent, Plusieurs valeurs AppId et Sous-clé avec plusieurs apps » peuvent se ressembler à l’écran tout en provenant de causes différentes. Chaque branche de diagnostic associe donc un signal, une preuve et une action de correction précise.

• expliquer la structure observée sans la présenter comme un contrat
• déterminer si l’échec est actuel et réessayable
• définir les garde-fous d’un éventuel pilote de remédiation

Cartographie du flux à diagnostiquer

La branche Win32Apps est organisée par contexte utilisateur ou device, puis par application et révision. Les états doivent être reliés à l’AppId et aux journaux du même cycle.

Sous GRS, une sous-clé opaque peut contenir plusieurs propriétés dont les noms correspondent à différents AppId. Plusieurs propriétés portant le même AppId peuvent aussi exister dans différents contextes ou historiques.

Le verdict est donc une classification: absent, historique, succès avec trace, échec actuel probable ou ambigu. Seul un candidat actuel, unique et corrélé peut être étudié pour un pilote; il n’est jamais automatiquement autorisé à la suppression.

État initial et prérequis de collecte

L’état initial de Comprendre le GRS Intune avant toute action doit couvrir AppId exact obtenu depuis Intune, heure de l’échec et contexte connus, journaux IME complets, état local de détection contrôlé. Cette photographie est prise avant de relancer un traitement ou de modifier une affectation.

Les couches Policy, Enforcement, State, GRS sont contrôlées séparément. Un prérequis absent devient alors une cause identifiable, au lieu d’être noyé dans les effets des essais suivants.

• AppId exact obtenu depuis Intune
• heure de l’échec et contexte connus
• journaux IME complets
• état local de détection contrôlé
• cause corrigée avant retry
• export minimal des propriétés concernées
• validation en laboratoire représentatif

Collecte des preuves : journaux, registre et états

Je lis IntuneManagementExtension.log, AppWorkload.log, AppActionProcessor.log et Win32AppInventory.log avant le registre. L’état de détection actuel est indispensable.

Le rapport conserve AppId et révision, mais pseudonymise les contextes. Il indique le nombre de candidats, leur âge relatif, le nombre de propriétés dans le conteneur et le verdict fail-safe.

• AppId et révision exacts
• dernier code d’enforcement
• résultat de détection actuel
• heure de début et fin
• tous les candidats GRS
• conteneur partagé ou non
• sauvegarde avant toute mutation

Investigation pas à pas

L’investigation suit l’ordre Policy → Enforcement → State → GRS. La première divergence confirmée détermine la branche suivante et évite de multiplier les symptômes secondaires.

Pour Comprendre le GRS Intune avant toute action, les contrôles « Prouver l’échec courant », « Inventorier les candidats GRS », « Corriger la cause » précisent à la fois l’emplacement, le résultat attendu et la vérification à effectuer.

Ce que la présence GRS ne prouve pas

Une propriété GRS peut être présente alors que l’application est installée et détectée. Elle peut correspondre à une tentative antérieure ou à un autre contexte. Je commence donc par le dernier EnforcementStateMessage et les logs, pas par le registre.

La date contenue dans la valeur doit être interprétée avec prudence et corrélée au fuseau. Une correspondance temporelle renforce une hypothèse; elle ne remplace pas l’état applicatif.

L’absence de propriété ne signifie pas que l’IME réessaiera immédiatement. Applicabilité, dépendances, supersedence, intention et cycle de check-in restent valables.

Pourquoi la suppression du conteneur est dangereuse

Le nom opaque de la sous-clé n’est pas l’AppId. Cette sous-clé peut contenir des valeurs pour plusieurs applications. La supprimer revient à élargir la cible sans preuve et peut relancer ou altérer d’autres traitements.

Une commande récursive copiée depuis Internet masque le nombre d’objets touchés. Elle supprime aussi l’artefact qui aurait permis de comprendre un doublon de contexte ou une ancienne révision.

Même une suppression ciblée d’une propriété reste une opération non contractuelle. Elle exige sauvegarde, simulation, vérification post-action et une version IME testée. Elle ne doit pas devenir un mécanisme d’exploitation permanent.

Le cas 0x87D1041C

0x87D1041C indique que l’application n’a pas été détectée après une installation annoncée réussie. La priorité est de comparer la règle à l’état réel: fichier, version, MSI product code, vue du registre et contexte.

Supprimer une temporisation sans corriger la détection provoque généralement la même installation puis le même échec. Cela augmente la charge, peut réparer ou désinstaller involontairement le produit et brouille le diagnostic.

Je classe donc ce code DETECTION_REVIEW_REQUIRED. Le retry n’est étudié qu’après une nouvelle règle validée sur les états installés, absents et mis à niveau.

Commandes et scripts de diagnostic en lecture seule

Les exemples ci-dessous contrôlent AppId et révision exacts, dernier code d’enforcement, résultat de détection actuel, heure de début et fin. Leur sortie doit être rapprochée de l’heure de l’incident et du contexte d’exécution concerné.

Pour Comprendre le GRS Intune avant toute action, les données utiles se lisent dans les états locaux, les journaux et les rapports cités dans chaque exemple. Une valeur isolée ne remplace pas cette corrélation.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
    $appId = '<GUID-AppId>'
    $root = 'HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps'
    Get-ChildItem -LiteralPath $root -Recurse -ErrorAction Stop |
        Where-Object { $_.PSParentPath -match '\\GRS($|\\)' } |
        ForEach-Object {
            $item = Get-ItemProperty -LiteralPath $_.PSPath
            if ($item.PSObject.Properties.Name -contains $appId) {
                [pscustomobject]@{ KeyPath = $_.Name; AppId = $appId; Value = $item.$appId }
            }
        }
}
catch { Write-Error "Inventaire GRS impossible : $($_.Exception.Message)"; exit 1 }

$ErrorActionPreference = 'Stop'
try {
  $root = 'HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps'
  Get-ChildItem -LiteralPath $root -Recurse -ErrorAction SilentlyContinue |
    Where-Object { $_.PSChildName -eq 'GRS' } |
    ForEach-Object {
      $item = Get-ItemProperty -LiteralPath $_.PSPath
      [pscustomobject]@{ Path=$_.Name; Properties=($item.PSObject.Properties.Name -join ',') }
    }
}
catch {
  Write-Error "Collecte impossible : $($_.Exception.Message)"
  exit 1
}

[14:31:00.014] Policy  AppId=<GUID> Revision=4 Intent=Required
[14:31:02.882] Detect  AppId=<GUID> Result=NotDetected
[14:31:11.223] Install AppId=<GUID> ExitCode=1603
[14:31:11.225] GRS     AppId=<GUID> Candidate=True Container=<HASH>
[15:02:48.900] Cause   InstallerLog=ReturnValue3 PermissionDenied

Arbre de décision : symptômes, causes et corrections

La matrice couvre notamment App installée mais GRS présent, Plusieurs valeurs AppId, Sous-clé avec plusieurs apps, 0x87D1041C. Ces symptômes servent de points d’entrée; la preuve indiquée dans la même ligne confirme ou écarte la cause.

Après correction, les contrôles échec actuel prouvé, cause corrigée et tous candidats classifiés sont rejoués dans les mêmes conditions pour vérifier que le problème n’a pas simplement changé de phase.

Validation de la correction et critères de clôture

La correction de Comprendre le GRS Intune avant toute action est validée avec les mêmes points de mesure que le diagnostic initial. Le résultat local et l’état remonté dans le service doivent raconter la même chronologie.

• échec actuel prouvé
• cause corrigée
• tous candidats classifiés
• aucun conteneur partagé ciblé
• sauvegarde vérifiée
• pilote reproductible
• état Intune stable après deux cycles

Retour arrière, escalade et points de vigilance

Le retour arrière de Comprendre le GRS Intune avant toute action restaure l’état connu décrit ci-dessous. Sa réussite se vérifie sur le poste et dans le service, pas seulement par la disparition d’une affectation.

Une escalade conserve les preuves correspondant à AppId et révision exacts, dernier code d’enforcement, résultat de détection actuel, heure de début et fin ainsi que les causes déjà écartées.