Sous le capot de l’IME : le cycle interne d’une application Win32

Résumé

L’Intune Management Extension complète le client MDM Windows pour les charges qui nécessitent une exécution locale riche. Pour une application Win32, l’IME ne se limite pas à lancer une commande : il évalue un graphe, gère le contenu, interprète le résultat et confirme l’état par la détection.

Le moteur fonctionne par cycles. Il reçoit une politique, identifie le contexte, calcule l’applicabilité, vérifie la détection, télécharge et prépare le contenu, lance l’installateur, interprète son code, réexécute la détection et construit le reporting. Chaque étape peut aboutir, attendre ou échouer indépendamment.

Les clés de registre et répertoires internes restent des preuves d’observation, pas des interfaces supportées à modifier pour piloter l’agent.

L’Intune Management Extension complète le client MDM Windows pour les charges qui nécessitent une exécution locale riche. Pour une application Win32, l’IME ne se limite pas à lancer une commande : il évalue un graphe, gère le contenu, interprète le résultat et confirme l’état par la détection.

Contexte, objectif et périmètre

Le canal MDM Windows sait appliquer des CSP, mais il n’a pas été conçu pour orchestrer tous les comportements d’un installateur Win32. Microsoft ajoute donc un service local capable de télécharger un package, de lancer un processus en contexte SYSTEM ou utilisateur, puis de vérifier un état arbitraire.

Le service et l’agent partagent une intention, mais pas un état instantané. Le portail peut afficher une information reçue lors du cycle précédent tandis que le poste a déjà commencé une nouvelle tentative. La corrélation temporelle explique ces écarts.

Je traite « Cycle interne Win32 dans l’IME » 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.

Pour expliquer la technologie, je sépare le plan de contrôle, le transport, les composants locaux et les données de résultat. Cette lecture évite d’attribuer au portail une décision prise par Windows, ou à un agent local une limitation qui appartient en réalité au service cloud, à la licence ou au modèle d’affectation.

Les détails internes observés dans les journaux ou le registre servent à établir une hypothèse de diagnostic. Ils ne deviennent pas pour autant une interface publique stable. Toute automatisation durable doit s’appuyer sur une API ou une configuration officiellement supportée, puis être revalidée quand la version du service ou du client change.

• Objectif : expliquer les composants et états du moteur Win32
• Objectif : montrer comment une politique devient une exécution locale
• Objectif : définir les preuves fiables et les limites des artefacts internes
• Périmètre : IME Windows et applications Win32
• Périmètre : contenu .intunewin, détection, dépendances, supersedence et reporting
• Périmètre : observations locales en lecture seule

Architecture et fonctionnement général

Intune calcule les applications requises ou disponibles à partir des affectations, groupes, filtres et relations. L’IME interroge le service lors de ses check-ins et peut recevoir une notification. La présence d’une application dans la politique ne signifie pas qu’elle sera exécutée : l’agent doit encore déterminer le contexte et l’applicabilité.

L’évaluation forme un graphe. Une dépendance doit atteindre son état avant l’application parente. Une supersedence décrit le remplacement d’une autre version et peut demander sa désinstallation. Exigences et détection peuvent court-circuiter l’enforcement sans démarrer l’installateur.

Le reporting est une projection des états locaux. ComplianceStateMessage et EnforcementStateMessage observés sous Win32Apps donnent des indices, mais leur schéma n’est pas une API publique. Je les associe toujours au journal et à l’heure de la tentative.

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.

• service Microsoft Intune Management Extension installé et démarré
• application Win32 affectée
• accès en lecture aux journaux et à la configuration Intune
• AppId et contexte de la tentative
• poste pilote avec horloge synchronisée

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.

Du contenu chiffré à IMECache

Le package .intunewin transporte le contenu préparé et ses métadonnées. L’IME le télécharge dans sa zone de contenu, contrôle son intégrité, le fait passer par les étapes de préparation puis l’extrait sous C:\Windows\IMECache pour l’exécution.

Les transitions Staging et Staged sont utiles pendant une tentative, mais leur persistance n’est pas garantie. Un contrôle de sécurité, un manque d’espace ou un fichier verrouillé peut arrêter la préparation avant même le lancement de l’installateur.

Je ne crée pas d’exclusion antimalware globale à partir d’une intuition. Je confirme l’événement EDR, limite l’exception au besoin prouvé et la valide avec l’équipe sécurité sur pilote.

SYSTEM, utilisateur et architecture

Sous SYSTEM, profil, certificats personnels, lecteurs réseau et variables diffèrent de ceux de l’utilisateur. Une commande valide en console interactive peut donc échouer dans l’IME. Un installateur qui attend une fenêtre reste bloqué en session 0.

Un processus 32 bits sur Windows 64 bits peut lire une autre vue du registre. La détection doit utiliser la même intention d’architecture que l’installation. Les chemins de profil doivent viser l’utilisateur concerné, pas le profil de SYSTEM.

Je rends l’installation indépendante de la session interactive, je documente le contexte et je teste l’artefact final avec les mêmes droits que l’agent.

États, GRS et frontière du support

Les branches Win32Apps et GRS rendent visibles des états d’enforcement et de planification, mais elles contiennent aussi historiques et contextes multiples.

Une valeur GRS nommée par l’AppId peut se trouver sous une sous-clé opaque partagée. Supprimer ce conteneur n’est donc pas une relance ciblée.

Je considère toute écriture directe comme une expérimentation non supportée sans laboratoire, sauvegarde et rollback. En exploitation, je corrige la politique ou le package puis j’utilise les déclencheurs Intune supportés.

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 {
  $service = Get-CimInstance Win32_Service -Filter "Name='IntuneManagementExtension'"
  [pscustomobject]@{ ServiceState=$service.State; StartMode=$service.StartMode; LogRoot='C:\ProgramData\Microsoft\IntuneManagementExtension\Logs'; Win32State=(Test-Path 'HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps'); IMECache=(Test-Path 'C:\Windows\IMECache') }
}
catch { Write-Error "Inventaire IME impossible : $($_.Exception.Message)"; exit 1 }

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

• service IME sain
• cycle complet identifiable par AppId
• contenu validé
• code correctement mappé
• détection finale cohérente
• reporting Intune reçu

Journaux, diagnostic et constitution des preuves

La meilleure preuve est une chronologie continue portant le même AppId. Je joins les lignes voisines afin de conserver le contexte et j’évite les extractions par mots-clés trop agressives qui éliminent la cause précédente.

NotificationInfra.log peut expliquer la notification, ClientCertCheck.log les contrôles de certificat et ClientHealth.log la santé de l’agent. Ils complètent AppWorkload.log sans le remplacer.

• IntuneManagementExtension.log : cycle général
• AppWorkload.log : traitement applicatif
• AppActionProcessor.log : détection et applicabilité
• AgentExecutor.log : scripts
• ClientCertCheck.log et ClientHealth.log : identité et santé
• NotificationInfra.log : notifications
• Win32AppInventory.log : inventaire

PolicyReceived AppId=<APP-ID> Intent=Required Context=Device
DetectionCheck Phase=PreInstall Result=False
ContentDownload Result=Success
Enforcement Command=install.cmd ExitCode=0
DetectionCheck Phase=PostInstall Result=True
Report Compliance=Compliant Enforcement=Success

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 : restaurer affectations et relations
• Rollback : revenir au package et à la détection validés
• Rollback : restaurer la VM après reproduction
• Vigilance : ne pas présenter une structure interne comme contrat stable
• Vigilance : ne pas modifier Win32Apps ou GRS pendant la collecte
• Vigilance : pseudonymiser les identifiants