Intune Application Inventory et Properties Catalog : construire un inventaire exploitable

Résumé

Properties Catalog définit les catégories et propriétés matérielles ou système qu’Intune doit collecter sur les postes Windows. Les résultats apparaissent dans Device Inventory et reposent sur le Microsoft Device Inventory Agent.

Application Inventory enrichit la visibilité logicielle par rapport à l’ancien rapport Discovered apps. Je conserve néanmoins la distinction entre application détectée, application gérée et application réellement utilisée.

Device Query interroge un poste à la demande ; l’inventaire collecte périodiquement pour le parc ; les rapports et le Data Warehouse répondent à d’autres horizons. Les combiner sans expliquer leur fraîcheur produit des chiffres contradictoires.

Properties Catalog définit les catégories et propriétés matérielles ou système qu’Intune doit collecter sur les postes Windows. Les résultats apparaissent dans Device Inventory et reposent sur le Microsoft Device Inventory Agent.

Contexte, objectif et périmètre

L’ancien inventaire applicatif Intune était souvent jugé trop lent ou trop pauvre pour les décisions opérationnelles. La plateforme de données Intune apporte des propriétés plus détaillées et une collecte configurable.

Collecter tout ce qui est disponible n’est pas une stratégie. Chaque catégorie augmente le volume, la surface de données et les questions de confidentialité. Je pars des cas d’usage : sécurité, renouvellement matériel, support, compatibilité ou licence.

Je traite « Application Inventory et Properties Catalog » 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 l’agent, la policy et le stockage
• Objectif : concevoir un catalogue minimal de propriétés
• Objectif : contrôler fraîcheur, couverture et qualité
• Périmètre : postes Windows corporate Intune ou co-managed éligibles
• Périmètre : inventaire matériel, système et applicatif
• Périmètre : consultation par poste et exploitation agrégée

Architecture et fonctionnement général

La policy est affectée aux groupes de postes. Au prochain check-in, Windows reçoit la sélection et l’agent collecte les catégories demandées. La première remontée peut demander jusqu’à la fenêtre documentée par Microsoft ; elle n’est pas instantanée.

Certaines propriétés minimales sont automatiquement ajoutées pour identifier le poste et structurer les données. La suppression d’une policy arrête la collecte mais les dernières données peuvent rester visibles pendant une durée documentée, actuellement jusqu’à 28 jours.

L’agent écrit ses journaux sous C:\Program Files\Microsoft Device Inventory Agent\Logs. Une absence de résultat doit être séparée en non-éligibilité, policy non reçue, collecte locale, upload ou affichage.

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.

• licence/capacité Intune confirmée
• appareil corporate Intune-managed ou co-managed supporté
• Entra joined ou hybrid joined
• rôle Policy and Profile Manager pour configurer
• objectif et base légale de collecte définis
• groupes pilotes stables
• durée de conservation comprise

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.

Inventaire applicatif : ce que signifie une ligne

Une ligne d’application décrit une observation sur un appareil, pas nécessairement une application distribuée par Intune. Je relie nom, éditeur, version et emplacement avant de dédupliquer les variantes.

Les applications non gérées peuvent être visibles selon propriété et type de device. La présence n’établit ni l’usage ni la conformité de licence. Un produit portable, un composant utilisateur ou une mise à jour peut échapper au modèle attendu.

Je conserve l’identifiant technique et la date de dernière observation. Regrouper uniquement par DisplayName fusionne parfois plusieurs produits ; séparer strictement chaque chaîne peut au contraire gonfler le catalogue.

Properties Catalog et minimisation

Je sélectionne les catégories nécessaires plutôt que tout activer. BIOS et TPM servent à la préparation firmware ; batterie et disque au renouvellement ; chiffrement à la sécurité ; réseau au support. Chaque usage possède un accès RBAC et une durée.

Certaines catégories ne peuvent être arrêtées qu’en retirant toutes leurs propriétés. Je documente cette granularité avant de promettre une suppression immédiate d’une donnée isolée.

Les informations du client peuvent être altérées par un administrateur local. Pour une décision de sécurité, je croise l’inventaire avec conformité, attestation ou Defender au lieu de lui attribuer une confiance qu’il n’a pas.

Fraîcheur, co-management et sources concurrentes

Device Inventory Intune et Resource Explorer Configuration Manager peuvent coexister sur un appareil tenant attach. Je nomme toujours la source dans le rapport et je n’aligne pas les lignes sur le seul nom du poste.

Une valeur vide peut signifier propriété non demandée, collecte non terminée, donnée non applicable ou échec. Le tableau de bord doit distinguer ces états au lieu de les convertir tous en Inconnu.

Pour une décision urgente sur un poste, Device Query est plus adapté. Pour une tendance de parc, l’inventaire et les exports sont adaptés. Pour un modèle historique, je vérifie les capacités du Data Warehouse ou du reporting export.

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 {
  [pscustomobject]@{
    ComputerName = $env:COMPUTERNAME
    BiosVersion  = (Get-CimInstance Win32_BIOS).SMBIOSBIOSVersion
    MemoryGB     = [math]::Round((Get-CimInstance Win32_ComputerSystem).TotalPhysicalMemory / 1GB, 1)
    TpmReady     = (Get-Tpm).TpmReady
  }
  Get-ChildItem -LiteralPath 'C:\Program Files\Microsoft Device Inventory Agent\Logs' -ErrorAction SilentlyContinue |
    Select-Object Name, Length, LastWriteTime
}
catch { Write-Error "Contrôle inventaire 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é.

• couverture pilote mesurée
• fraîcheur connue
• valeurs locales concordantes
• données minimisées
• RBAC vérifié
• cas vide distingués
• rapport indique source et date

Journaux, diagnostic et constitution des preuves

Je collecte profil, affectation, dernier check-in, journaux agent et heure de dernière donnée affichée. Une capture de la console seule ne localise pas la rupture.

Les logs Device Inventory Agent peuvent être collectés avec l’action de diagnostic Intune. Je minimise les données avant transfert et je respecte les règles internes de conservation.

• profil et propriétés
• affectation effective
• version/éligibilité du poste
• logs Device Inventory Agent
• heure de collecte
• heure d’affichage
• comparaison locale
• taux de couverture

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 : retirer l’affectation pilote
• Rollback : supprimer le profil si aucune autre audience
• Rollback : attendre l’expiration documentée des données résiduelles
• Vigilance : suppression policy non instantanée sur données
• Vigilance : inventaire n’est pas preuve d’usage
• Vigilance : ne pas mélanger source ConfigMgr et Intune
• Vigilance : revalider les propriétés disponibles