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

Résumé

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.

Contexte, objectif et périmètre

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.

Je traite « Diagnostic complet des applications Win32 » comme une chaîne de preuves et non comme une succession de boutons à cliquer. Une action n’est considérée comme réussie que lorsque le résultat est visible au niveau attendu : configuration du service, état reçu par le poste, traitement local, puis remontée cohérente dans les outils d’administration. Cette séparation évite de confondre une affectation valide avec une exécution terminée.

Je conserve systématiquement les heures en UTC et en heure locale, l’identité de l’appareil, le contexte utilisateur ou système, la version de Windows et la version des composants concernés. Sans ces repères, deux événements semblables peuvent appartenir à des cycles différents. Les exemples de journaux sont anonymisés et les identifiants techniques doivent l’être avant tout partage.

Ma méthode part du symptôme observable, formule plusieurs hypothèses concurrentes, puis cherche la preuve capable d’en éliminer une. Je ne commence pas par vider un cache, supprimer une clé ou réinstaller un agent : ces actions modifient précisément l’état qui permettrait de comprendre l’incident. La collecte initiale reste donc en lecture seule.

Une correction n’est proposée qu’après localisation de la phase en échec. Je distingue toujours le contournement temporaire, la correction causale et la correction structurelle. Le retour arrière est préparé avant la modification, puis le résultat est contrôlé sur un pilote représentatif avant toute généralisation.

• Objectif : identifier précisément la phase du cycle Win32 qui échoue
• Objectif : expliquer où trouver les preuves dans Intune, Windows et les journaux de l’installateur
• Objectif : corriger la cause sans modifier aveuglément les états internes de l’IME
• Périmètre : applications Win32 .intunewin exécutées en contexte SYSTEM ou utilisateur
• Périmètre : affectations Required et Available, dépendances, supersedence, exigences et détection
• Périmètre : postes Windows Entra joints ou hybrides gérés par Intune et disposant de l’IME

Architecture et fonctionnement général

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.

Prérequis techniques et préparation

Avant toute mise en œuvre, je fige le périmètre de test et je capture l’état initial. Cette photographie comprend les versions, les affectations, les autorités de gestion, les dépendances et les exceptions connues. Elle sert autant à interpréter le résultat qu’à construire le retour arrière.

Je vérifie les prérequis sur un appareil réellement représentatif. Une console qui autorise la création d’un profil ne prouve ni l’éligibilité du poste, ni la disponibilité effective de la fonctionnalité dans le tenant. Les prérequis réseau, licence, identité et système doivent tous être confirmés.

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

Procédure de mise en œuvre

La procédure suivante est volontairement découpée en points de contrôle. Je ne poursuis pas lorsqu’un résultat attendu manque : continuer masquerait la première divergence et produirait des symptômes secondaires plus difficiles à interpréter.

Les noms de groupes, profils, applications et fichiers sont des exemples. Je les remplace par les conventions de l’organisation, je documente la population ciblée et je conserve une preuve avant/après pour chaque changement.

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 standard reste la collecte en lecture seule, 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. Toute expérimentation de registre exige sauvegarde, isolation, niveau de script 2 minimum et rollback testé.

Scripts, commandes et exemples de lecture

Les commandes présentées servent à observer ou illustrer le fonctionnement. Les scripts de diagnostic restent de niveau 1, avec arrêt sur erreur et gestion globale de l’exception. Ils ne modifient pas le poste. Une remédiation serait au minimum de niveau 2, avec mode de simulation, journalisation adaptée au test et comportement de rollback explicitement validé.

Je lis toujours la sortie avec le contexte d’exécution. Une commande lancée dans la session de l’utilisateur ne voit pas nécessairement les mêmes certificats, chemins, variables, applications ou ruches de registre qu’un processus exécuté par l’Intune Management Extension sous SYSTEM.

# Exemple pédagogique non testé — niveau 1
$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

Validation et critères de contrôle

Je valide d’abord le résultat technique sur le poste, puis sa remontée dans le service. Le portail peut conserver un état ancien pendant un certain temps ; inversement, un état vert dans la console ne dispense pas de contrôler l’artefact local réellement attendu.

Le critère GO exige un résultat reproductible, une absence de régression sur les fonctions voisines, une documentation à jour et un retour arrière démontré. Le critère NO-GO s’applique dès qu’une dépendance n’est pas maîtrisée, qu’une partie du parc réagit différemment ou que l’état final ne peut pas être prouvé.

• 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

Journaux, diagnostic et constitution des preuves

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

Dépannage : symptômes, preuves et corrections

Je pars de la colonne Symptôme, mais je ne choisis jamais une correction sur ce seul indice. La colonne Preuve indique l’élément qui doit confirmer la cause. Si cette preuve manque, l’hypothèse reste ouverte et l’action proposée ne doit pas être appliquée comme une recette automatique.

Après correction, je reproduis le scénario initial et je compare les mêmes points de mesure. Un changement de symptôme n’est pas toujours une résolution : il peut simplement indiquer que le traitement progresse jusqu’à une nouvelle phase. La chronologie complète reste donc la référence.

Retour arrière et points de vigilance

Le retour arrière ne consiste pas seulement à retirer une affectation. Je restaure l’autorité précédente, la configuration ou la version attendue, puis je vérifie que le poste a effectivement reçu et appliqué ce nouvel état. Les caches et délais de remontée sont documentés au lieu d’être interprétés comme une absence de rollback.

Je conserve les preuves du pilote, le motif de la décision et les écarts rencontrés. Si le service cloud ou une interface évolue, je réévalue les étapes avant une nouvelle vague. Aucun succès obtenu uniquement sur le poste de développement ne constitue une validation de production.

• Rollback : désaffecter uniquement le groupe pilote
• Rollback : restaurer package, commande, détection et codes précédemment exportés
• Rollback : désinstaller la version testée ou restaurer le snapshot
• Vigilance : ne jamais supprimer une branche GRS complète comme action générique
• Vigilance : ne jamais publier le contenu d’IMECache sans vérifier les droits
• Vigilance : ne pas confondre succès du processus et succès de la détection