Applications Win32 Intune : le guide complet du diagnostic de bout en bout

Résumé opérationnel

Je ne dépanne pas une application Win32 à partir du seul message du portail. Je détermine d’abord si elle devait réellement s’appliquer, puis je suis son AppId dans les journaux de l’Intune Management Extension. Cette méthode localise la première phase divergente et évite les suppressions de cache ou de registre qui effacent les preuves.

Le diagnostic repose sur quatre ensembles cohérents: la configuration Intune, les prérequis du poste, les journaux IME et le journal propre à l’installateur. Une installation peut retourner zéro puis échouer à la détection; elle peut aussi ne jamais démarrer parce qu’une exigence, une dépendance ou une supersedence l’a rendue inapplicable.

L’objectif est de produire une conclusion vérifiable: phase en échec, cause confirmée, correction ciblée, résultat attendu et retour arrière. Les exemples utilisent des identifiants fictifs et aucune modification du GRS n’est proposée comme procédure standard.

Je ne dépanne pas une application Win32 à partir du seul message du portail. Je détermine d’abord si elle devait réellement s’appliquer, puis je suis son AppId dans les journaux de l’Intune Management Extension. Cette méthode localise la première phase divergente et évite les suppressions de cache ou de registre qui effacent les preuves.

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

Une application Win32 Intune est un objet d’orchestration, pas seulement un exécutable emballé dans un fichier.intunewin. Le service associe le contenu à une commande d’installation, des exigences, une règle de détection, des dépendances, une éventuelle supersedence, un contexte d’exécution et une stratégie de codes de retour.

Le portail agrège ce traitement en quelques états faciles à lire, mais cette simplification masque la chronologie. Un échec de téléchargement, un installateur qui retourne 1603 et une détection faussement négative peuvent produire une expérience utilisateur proche tout en exigeant des corrections totalement différentes.

• applications Win32.intunewin exécutées en contexte SYSTEM ou utilisateur
• affectations Required et Available, dépendances, supersedence, exigences et détection
• postes Windows Entra joints ou hybrides gérés par Intune et disposant de l’IME

Questions à résoudre et méthode de diagnostic

Pour Diagnostic complet des applications Win32, l’enquête suit le parcours Intune → IME → Installateur → Détection. 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 C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log: check-in, stratégie et reporting, AppWorkload.log et AppActionProcessor.log: applicabilité, téléchargement, installation et détection et AgentExecutor.log: exécution d’un script PowerShell utilisé par l’application. 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 « Téléchargement absent, 0x80070002 et Code 1603 » 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.

• identifier précisément la phase du cycle Win32 qui échoue
• expliquer où trouver les preuves dans Intune, Windows et les journaux de l’installateur
• corriger la cause sans modifier aveuglément les états internes de l’IME

Cartographie du flux à diagnostiquer

L’IME effectue une détection avant installation. Si l’état attendu existe déjà, l’installation peut être considérée comme satisfaite sans lancement de l’installateur. Dans le cas contraire, l’agent vérifie les exigences et les relations, récupère le contenu chiffré, le prépare dans ses répertoires de travail, puis l’extrait dans IMECache pour l’exécution.

Le code de retour de l’installateur est interprété selon le mapping défini dans l’application. Succès, succès avec redémarrage, nouvelle tentative et échec sont des décisions Intune; un code non prévu reste un échec. L’IME relance ensuite la règle de détection. Le succès du processus ne suffit donc jamais si l’artefact attendu n’est pas détecté.

Enfin, les états locaux sont convertis en messages de conformité et d’enforcement envoyés au service. Le GRS intervient dans la planification de certaines réévaluations, mais sa structure de registre est interne. Une valeur GRS peut être historique, partagée ou présente après un succès; sa présence ne prouve pas un échec actif.

État initial et prérequis de collecte

L’état initial de Diagnostic complet des applications Win32 doit couvrir Accès en lecture à l’application, ses affectations, dépendances, supersedences, exigences, règles de détection et codes de retour dans Intune. Droits locaux permettant de lire C:\ProgramData\Microsoft\IntuneManagementExtension\Logs et les journaux de l’installateur. AppId Intune, heure approximative du test, utilisateur concerné, contexte SYSTEM/User, architecture et version Windows. Package et commande réellement publiés, ainsi que la procédure de test silencieux fournie par l’éditeur. Cette photographie est prise avant de relancer un traitement ou de modifier une affectation.

Les couches Intune, IME, Installateur, Détection 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.

• Accès en lecture à l’application, ses affectations, dépendances, supersedences, exigences, règles de détection et codes de retour dans Intune.
• Droits locaux permettant de lire C:\ProgramData\Microsoft\IntuneManagementExtension\Logs et les journaux de l’installateur.
• AppId Intune, heure approximative du test, utilisateur concerné, contexte SYSTEM/User, architecture et version Windows.
• Package et commande réellement publiés, ainsi que la procédure de test silencieux fournie par l’éditeur.
• Poste pilote reproductible; aucune suppression de cache, réinstallation IME ou modification GRS avant la collecte initiale.

Collecte des preuves : journaux, registre et états

Je conserve la configuration de l’application, un export minimisé des journaux IME, le journal complet de l’installateur et le résultat de la règle de détection. Les captures du portail doivent montrer l’heure de dernière remontée afin de ne pas comparer un état cloud ancien à une tentative locale récente.

Le journal de l’installateur reste l’autorité pour expliquer son propre code. Un 1603 MSI signifie une erreur fatale générique; il faut rechercher la première erreur causale et la section Return value 3 dans le log verbose, puis confirmer le prérequis, le verrou, la permission ou l’action personnalisée concernée.

• C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log: check-in, stratégie et reporting.
• AppWorkload.log et AppActionProcessor.log: applicabilité, téléchargement, installation et détection.
• AgentExecutor.log: exécution d’un script PowerShell utilisé par l’application.
• C:\Windows\IMECache: contenu temporaire de la tentative courante, s’il est encore présent.
• HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps: états internes à lire sans les modifier.
• Journal MSI /L*v ou journal natif de l’éditeur: cause détaillée de l’installateur.

09:12:01  AppId=<APP-ID> DetectionBefore=False
09:12:08  Download=Completed ContentHash=Validated
09:12:11  InstallContext=System Command=setup.exe /silent
09:13:42  ProcessExitCode=0 MappedResult=Success
09:13:44  DetectionAfter=False
09:13:45  EnforcementState=Failed Reason=DetectionRuleNotMet

Investigation pas à pas

L’investigation suit l’ordre Intune → IME → Installateur → Détection. La première divergence confirmée détermine la branche suivante et évite de multiplier les symptômes secondaires.

Pour Diagnostic complet des applications Win32, les contrôles « Qualifier le ciblage et l’applicabilité », « Fixer la fenêtre temporelle », « Suivre l’AppId dans les journaux IME » précisent à la fois l’emplacement, le résultat attendu et la vérification à effectuer.

Lire la séquence IME sans perdre le fil

IntuneManagementExtension.log donne le cadre général: check-in, réception des politiques et reporting. AppWorkload.log est généralement le meilleur point d’entrée pour le cycle applicatif. AppActionProcessor.log précise les évaluations d’applicabilité et de détection, tandis qu’AgentExecutor.log devient indispensable lorsqu’un script PowerShell intervient.

Je recherche d’abord l’AppId et je construis une chronologie. Je note le début du cycle, l’état de détection préalable, le téléchargement, le chemin d’exécution, le PID du processus, le code de sortie, la détection post-installation et le message final. Un saut d’horodatage important peut révéler une attente réseau, un timeout ou un redémarrage.

Le contenu temporaire sous C:\Windows\IMECache ne doit pas être considéré comme une archive du package. Il peut être supprimé par l’agent après traitement. Je ne retarde donc pas la collecte lorsque l’incident est reproductible et je ne publie jamais un contenu récupéré qui pourrait intégrer une licence ou des données d’éditeur.

Les noms de journaux évoluent avec l’agent. Je commence par ceux qui correspondent à la charge applicative et à la fenêtre étudiée.

Une dépendance ou une supersedence peut arrêter le graphe avant l’exécution de l’application étudiée.

Une bonne détection prouve l’état final

Une détection par simple existence de fichier devient vite fragile: le fichier peut être laissé par une version antérieure ou créé avant la fin de l’installation. J’utilise de préférence un ProductCode MSI lorsque le produit s’y prête, une valeur de registre accompagnée d’une version, ou un fichier dont la version correspond au minimum réellement supporté.

Pour un script de détection Intune, le résultat positif exige à la fois un code de sortie zéro et une sortie standard non vide. Écrire uniquement dans un flux verbeux ou retourner zéro sans texte peut produire un verdict différent de celui imaginé. Le script doit être court, déterministe, sans accès réseau non maîtrisé et testé en contexte 32 et 64 bits si le registre est concerné.

Je sépare la réussite technique de l’installateur et la conformité fonctionnelle. Une application peut être installée mais mal configurée; la règle de détection doit alors viser l’artefact qui représente l’objectif du déploiement, sans devenir un contrôle métier trop complexe ou instable.

Le chemin, la vue 32/64 bits, le type de comparaison et la version attendue doivent tous être documentés.

GRS : observer avant de toucher

Les états sous HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps contiennent des données de conformité, d’enforcement et de temporisation. Leur structure est utile pour corréler un incident, mais Microsoft ne la présente pas comme une API publique de remédiation. Elle peut varier entre versions de l’IME.

Une sous-clé GRS opaque peut contenir plusieurs propriétés nommées par des AppId. Supprimer le conteneur complet pour relancer une application peut donc affecter d’autres traitements. Plusieurs valeurs associées à un même AppId peuvent aussi coexister entre contextes ou cycles historiques.

Ma procédure reste la collecte de l’état initial, la correction de la cause, puis une nouvelle évaluation par les mécanismes supportés: nouvelle synchronisation, action depuis le Portail d’entreprise ou nouvelle affectation contrôlée selon le scénario. Une modification du registre ne se justifie que si la clé visée, son propriétaire, son impact et le retour à l’état précédent sont connus et vérifiés sur un poste pilote.

Commandes et scripts de diagnostic en lecture seule

Les exemples ci-dessous contrôlent C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log: check-in, stratégie et reporting. AppWorkload.log et AppActionProcessor.log: applicabilité, téléchargement, installation et détection. AgentExecutor.log: exécution d’un script PowerShell utilisé par l’application. C:\Windows\IMECache: contenu temporaire de la tentative courante, s’il est encore présent. Leur sortie doit être rapprochée de l’heure de l’incident et du contexte d’exécution concerné.

Pour Diagnostic complet des applications Win32, 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 Win32
$ErrorActionPreference = 'Stop'
try {
    $appId = '<APP-ID-INTUNE>'
    $logRoot = 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs'
    $logNames = @('IntuneManagementExtension.log','AppWorkload.log','AppActionProcessor.log','AgentExecutor.log')
    foreach ($logName in $logNames) {
        $path = Join-Path $logRoot $logName
        if (Test-Path -LiteralPath $path) {
            Select-String -LiteralPath $path -SimpleMatch $appId | Select-Object Path, LineNumber, Line
        }
    }
}
catch { Write-Error "Collecte Win32 impossible : $($_.Exception.Message)"; exit 1 }

$process = Start-Process -FilePath 'msiexec.exe' -ArgumentList @( '/i', 'C:\Lab\Package.msi', '/qn', '/norestart', '/L*v', 'C:\Windows\Temp\Package-install.log' ) -Wait -PassThru
$process.ExitCode

$ErrorActionPreference = 'Stop'
try {
  $appId = '<APP-GUID>'
  $logRoot = 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs'
  Get-ChildItem -LiteralPath $logRoot -Filter '*.log' |
    Select-String -Pattern $appId -Context 2,4 |
    Select-Object Path,LineNumber,Line
}
catch {
  Write-Error "Collecte impossible : $($_.Exception.Message)"
  exit 1
}

[12:12:01.120] AppWorkload AppId=<GUID> Intent=Required Applicability=True
[12:12:03.800] Content     AppId=<GUID> Download=Complete Hash=Valid
[12:12:05.421] Executor    AppId=<GUID> ExitCode=0
[12:12:06.090] Detection   AppId=<GUID> Result=NotDetected
[12:12:06.710] Reporting   AppId=<GUID> State=Failed Phase=Detection

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

La matrice couvre notamment Téléchargement absent, 0x80070002, Code 1603, Installation réussie puis échec. 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 détection négative avant installation, positive après installation et négative après désinstallation, commande silencieuse sans interaction et code retour documenté et cycle complet visible pour le même AppId 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 Diagnostic complet des applications Win32 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.

• détection négative avant installation, positive après installation et négative après désinstallation
• commande silencieuse sans interaction et code retour documenté
• cycle complet visible pour le même AppId
• succès remonté dans Intune
• dépendances, supersedence et redémarrage validés sur pilote

Retour arrière, escalade et points de vigilance

Le retour arrière de Diagnostic complet des applications Win32 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 à C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log: check-in, stratégie et reporting. AppWorkload.log et AppActionProcessor.log: applicabilité, téléchargement, installation et détection. AgentExecutor.log: exécution d’un script PowerShell utilisé par l’application. C:\Windows\IMECache: contenu temporaire de la tentative courante, s’il est encore présent. ainsi que les causes déjà écartées.