Managed Installer avec Intune et App Control : fonctionnement, limites et déploiement

L’essentiel

Intune peut désigner l’Intune Management Extension comme Managed Installer. Une collection spéciale AppLocker reconnaît alors le processus d’installation et Windows marque les fichiers qu’il écrit comme provenant d’une source gérée.

La politique App Control doit activer l’option Managed Installer pour utiliser cette origine comme motif d’autorisation. Une règle Deny explicite reste prioritaire et les fichiers installés avant l’activation ne sont pas marqués rétroactivement.

Je recommande Managed Installer comme une source de confiance parmi d’autres, pas comme l’unique modèle. Les composants système, pilotes, applications auto-mises à jour et fichiers copiés par des processus non suivis exigent des règles complémentaires.

Intune peut désigner l’Intune Management Extension comme Managed Installer. Une collection spéciale AppLocker reconnaît alors le processus d’installation et Windows marque les fichiers qu’il écrit comme provenant d’une source gérée.

Pourquoi cette technologie existe

Le mécanisme repose sur une collection AppLocker ManagedInstaller. Le processus reconnu et les processus enfants qu’il lance sont suivis afin que les fichiers écrits reçoivent une information d’origine dans le système de fichiers.

Une politique App Control n’utilise cette information que si l’option Enabled Managed Installer est activée. Dans une policy XML, elle correspond à l’option 13; dans Intune, les contrôles intégrés peuvent configurer ce comportement.

Le marquage concerne les fichiers déposés après que le Managed Installer est opérationnel. Une application déjà installée doit être redéployée, réparée ou autorisée par une autre règle; activer la policy ne transforme pas rétroactivement ses fichiers.

Managed Installer avec Intune s’appuie sur la chaîne AppLocker → IME → Origin → App Control. Comprendre le rôle de chaque étape permet de distinguer la demande envoyée, le traitement réellement effectué et l’état finalement observé.

Les dépendances importantes sont Intune Management Extension saine, App Control compatible et versionné, AppLocker Application Identity disponible, applications Win32 de test. Elles font partie du fonctionnement de la technologie: leur absence peut expliquer un résultat sans remettre en cause le composant étudié.

Les cas limites les plus utiles à connaître sont Pas d’événement 8002, Fichier ancien bloqué et Updater bloqué. Ils montrent où le modèle nominal peut diverger et quelles données permettent de lire cette divergence.

Le parcours devient plus concret en suivant les composants dans leur ordre réel. AppLocker ouvre la séquence: Désigne IME comme installateur géré. IME prend ensuite le relais: Lance le processus et ses enfants suivis. Le traitement se poursuit avec Origin, où Windows marque les fichiers écrits. Enfin, App Control ferme la boucle: Autorise l’origine sauf Deny prioritaire. Cette lecture évite de confondre un ordre envoyé avec son exécution, puis son exécution avec l’état restitué à l’administrateur. Elle indique aussi où chercher l’heure, l’identité et le résultat qui permettront de rapprocher deux observations.

Les limites se comprennent mieux à partir de situations concrètes. « Pas d’événement 8002 » conduit d’abord à vérifier AppLocker EXE and DLL, car la cause possible est IME non reconnue. Pour « Fichier ancien bloqué », la preuve utile devient Date et origine. Les cas « Updater bloqué » et « Fichier marqué mais bloqué » montrent enfin que deux symptômes proches peuvent appartenir à des phases différentes. Cette distinction n’est pas un détour de dépannage: elle fait partie du modèle de fonctionnement et explique la manière dont Managed Installer avec Intune expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions Intune Management Extension saine, App Control compatible et versionné, AppLocker Application Identity disponible, applications Win32 de test doivent être réunies en même temps. La validation porte ensuite sur Activer Managed Installer sur le groupe pilote, Vérifier AppLocker et événement 8002, Activer l’option 13 dans App Control Audit et Redéployer une application de test. Ce croisement est important: un prérequis confirme que le scénario peut fonctionner, alors qu’un contrôle de validation prouve qu’il a effectivement fonctionné. Il reste donc possible d’avoir une plateforme éligible mais mal configurée, ou une première exécution réussie dont l’état n’est pas encore visible dans le service. Le modèle présenté dans cet article sert précisément à lire ces écarts sans attribuer trop vite le résultat au mauvais composant. Il donne aussi au support un vocabulaire commun pour décrire l’étape atteinte et la preuve encore manquante.

Architecture, composants et flux de données

Le mécanisme repose sur une collection AppLocker ManagedInstaller. Le processus reconnu et les processus enfants qu’il lance sont suivis afin que les fichiers écrits reçoivent une information d’origine dans le système de fichiers.

Une politique App Control n’utilise cette information que si l’option Enabled Managed Installer est activée. Dans une policy XML, elle correspond à l’option 13; dans Intune, les contrôles intégrés peuvent configurer ce comportement.

Le marquage concerne les fichiers déposés après que le Managed Installer est opérationnel. Une application déjà installée doit être redéployée, réparée ou autorisée par une autre règle; activer la policy ne transforme pas rétroactivement ses fichiers.

Prérequis, compatibilité et limites de support

Le fonctionnement décrit suppose Intune Management Extension saine, App Control compatible et versionné, AppLocker Application Identity disponible, applications Win32 de test, événements AppLocker et Code Integrity. Ces conditions permettent de distinguer une limite de Managed Installer avec Intune d’un scénario simplement non éligible.

• Intune Management Extension saine
• App Control compatible et versionné
• AppLocker Application Identity disponible
• applications Win32 de test
• événements AppLocker et Code Integrity
• groupe Audit dédié
• plan d’autorisation alternatif

Cycle de fonctionnement, étape par étape

Le cycle de Managed Installer avec Intune traverse AppLocker → IME → Origin → App Control. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Managed Installer avec Intune, les étapes « Identifier les composants », « Observer le traitement », « Relier les états », « Valider le modèle » séparent l’intention, son transport, son traitement et le résultat final.

Fonctionnement détaillé de Managed Installer avec Intune

Le mécanisme repose sur une collection AppLocker ManagedInstaller. Le processus reconnu et les processus enfants qu’il lance sont suivis afin que les fichiers écrits reçoivent une information d’origine dans le système de fichiers.

Une politique App Control n’utilise cette information que si l’option Enabled Managed Installer est activée. Dans une policy XML, elle correspond à l’option 13; dans Intune, les contrôles intégrés peuvent configurer ce comportement.

Le marquage concerne les fichiers déposés après que le Managed Installer est opérationnel. Une application déjà installée doit être redéployée, réparée ou autorisée par une autre règle; activer la policy ne transforme pas rétroactivement ses fichiers.

• Intune Management Extension saine
• App Control compatible et versionné
• AppLocker Application Identity disponible
• applications Win32 de test

Traitement, exploitation et cas limites de Managed Installer avec Intune

Le suivi des processus a des limites. Certains installateurs extraient dans un contexte différent, délèguent à un service, téléchargent après le premier lancement ou utilisent un mécanisme de mise à jour autonome. Je teste le cycle installation, mise à jour, réparation et désinstallation.

Les règles Deny priment sur la confiance Managed Installer. Cette propriété permet de bloquer explicitement un binaire connu, mais explique aussi pourquoi un fichier correctement marqué peut rester refusé.

Le canal AppLocker EXE and DLL doit contenir un événement 8002 avec PolicyName MANAGEDINSTALLER lorsque l’IME est reconnue. Les événements 8003 ou 8004 indiquent que la règle ManagedInstaller ne correspond pas au processus.

• Contrôler origine et événements
• Tester update, repair et Deny
• Passer Enforced après couverture

Lire les états propres à Managed Installer avec Intune

fsutil permet de contrôler les attributs d’origine sur un fichier dans le cadre du guide Microsoft. Je réserve cette collecte à un laboratoire et je compare un fichier installé avant activation, un fichier redéployé et un fichier copié manuellement.

La policy Intune Managed Installer et la policy App Control ont des cycles de convergence distincts. Je prouve leur présence toutes les deux avant de conclure sur le déploiement de l’application.

Le rollback retire d’abord le mode Enforced ou déploie la policy App Control de remplacement testée, puis retire la configuration Managed Installer selon la procédure AppLocker. L’ordre évite de laisser des applications métier sans règle d’autorisation.

• Pas d’événement 8002 — AppLocker EXE and DLL
• Fichier ancien bloqué — Date et origine
• Updater bloqué — Parent process et CI
• Fichier marqué mais bloqué — Policy et événement

Pilote et suivi opérationnel de Managed Installer avec Intune

Le pilote couvre le périmètre Managed Installer, Intune Management Extension, App Control, AppLocker et contrôle Activer Managed Installer sur le groupe pilote. Vérifier AppLocker et événement 8002. Activer l’option 13 dans App Control Audit. Les résultats sont segmentés selon les populations réellement concernées par Managed Installer avec Intune.

Les cas d’échec « Pas d’événement 8002 », « Fichier ancien bloqué », « Updater bloqué » sont reproduits lorsque c’est possible. Ils vérifient que l’écart reste visible et que la procédure indique une preuve exploitable.

Le suivi après déploiement conserve marquage non rétroactif, Deny prioritaire, auto-updaters à tester, ne pas confondre IME installée et IME reconnue. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Interfaces d’observation, commandes et exemples

Les exemples rendent visibles Activer Managed Installer sur le groupe pilote. Vérifier AppLocker et événement 8002. Activer l’option 13 dans App Control Audit. Redéployer une application de test. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Managed Installer avec Intune, les interfaces documentées restent la référence de conception. Les fichiers, tâches ou clés observés localement servent à expliquer un état précis et peuvent évoluer avec le composant.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
  Get-Service AppIDSvc,IntuneManagementExtension | Select-Object Name,Status,StartType
  Get-WinEvent -LogName 'Microsoft-Windows-AppLocker/EXE and DLL' -MaxEvents 120 |
    Where-Object { $_.Id -in 8002,8003,8004 } | Select-Object TimeCreated,Id,Message
  CiTool.exe -lp -json
} catch { Write-Error "Collecte Managed Installer impossible : $($_.Exception.Message)"; exit 1 }

Observabilité : où lire l’état réel

La chronologie de Managed Installer avec Intune relie AppLocker, IME, Origin, App Control. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Activer Managed Installer sur le groupe pilote. Vérifier AppLocker et événement 8002. Activer l’option 13 dans App Control Audit. Redéployer une application de test. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « IME non reconnue », « Pas de marquage rétroactif », « Processus hors chaîne IME » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Activer Managed Installer sur le groupe pilote.
• Vérifier AppLocker et événement 8002.
• Activer l’option 13 dans App Control Audit.
• Redéployer une application de test.
• Contrôler origine et événements
• Tester update, repair et Deny
• Passer Enforced après couverture

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque Activer Managed Installer sur le groupe pilote, Vérifier AppLocker et événement 8002, Activer l’option 13 dans App Control Audit et Redéployer une application de test. Ces contrôles relient la configuration du service au résultat réellement observé.

• Activer Managed Installer sur le groupe pilote.
• Vérifier AppLocker et événement 8002.
• Activer l’option 13 dans App Control Audit.
• Redéployer une application de test.
• Contrôler origine et événements
• Tester update, repair et Deny
• Passer Enforced après couverture

Limites, modes de panne et lecture des erreurs

Les écarts connus de Managed Installer avec Intune incluent Pas d’événement 8002, Fichier ancien bloqué, Updater bloqué, Fichier marqué mais bloqué. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de Managed Installer avec Intune commence sur le périmètre Managed Installer, Intune Management Extension, App Control, AppLocker, Modern Workplace Lab — AppLocker, IME, Origin, App Control, Intune Management Extension saine, App Control compatible et versionné, AppLocker Application Identity disponible. Les limites et actions de réversibilité ci-dessous cadrent la progression.