Intune Device Query : interroger un poste presque en temps réel avec KQL

Résumé

Device Query envoie une requête à un appareil sélectionné et attend une réponse immédiate. WNS transporte la notification ; si le poste ou WNS est indisponible, la requête échoue au lieu de retourner un ancien inventaire.

Le langage ressemble à KQL mais s’applique au schéma Intune Data Platform supporté : BiosInfo, Process, WindowsRegistry, WindowsService, WindowsEvent, WindowsQfe et autres entités documentées.

La limite de 15 requêtes par minute, 2 048 caractères d’entrée et 128 Ko de résultat impose des requêtes ciblées. Une requête enregistrée doit documenter son intention, ses limites et l’interprétation de chaque résultat.

Device Query envoie une requête à un appareil sélectionné et attend une réponse immédiate. WNS transporte la notification ; si le poste ou WNS est indisponible, la requête échoue au lieu de retourner un ancien inventaire.

Contexte, objectif et périmètre

Le support a souvent le choix entre une donnée d’inventaire ancienne et une prise de contrôle intrusive. Device Query apporte une troisième voie pour vérifier un service, une clé, un fichier ou une mise à jour à la demande.

Ce n’est ni une base de données historique ni un moteur de remédiation. Il ne parcourt pas tout le parc depuis la fiche d’un appareil et ne garantit pas qu’une valeur locale fournie par un poste administrable soit inviolable.

Je traite « Device Query et KQL dans Intune » 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 le trajet d’une requête
• Objectif : écrire des requêtes bornées et interprétables
• Objectif : industrialiser une bibliothèque support avec RBAC
• Périmètre : postes Windows corporate Intune-managed
• Périmètre : Entra joined ou hybrid joined
• Périmètre : requêtes à la demande sur un appareil

Architecture et fonctionnement général

Le compte doit voir l’appareil et disposer de Managed Devices/Query, via Help Desk Operator ou un rôle personnalisé. Les scope tags et permissions de lecture restent déterminants.

Intune utilise WNS comme dépendance obligatoire pour la communication en temps réel. Un proxy ou pare-feu qui bloque WNS transforme une requête valide en timeout.

Le moteur local expose uniquement les entités et colonnes documentées. La sortie est renvoyée au portail et n’est pas un accès PowerShell arbitraire au poste.

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.

• capacité Intune Suite/add-on éligible
• appareil corporate
• Entra joined ou hybrid joined
• permission Managed Devices/Query
• WNS accessible
• schéma Data Platform consulté
• procédure d’usage et journalisation support

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.

Choisir l’entité et projeter tôt

WindowsService répond à un état de service ; Process à une exécution ; WindowsRegistry à une valeur ; WindowsQfe aux correctifs ; EncryptableVolume à BitLocker. Je ne collecte pas Process quand WindowsService suffit.

project limite les colonnes retournées et where réduit les lignes. Cette discipline évite la troncature 128 Ko et rend le résultat compréhensible dans un ticket.

Les opérateurs ne sont pas tous ceux de Kusto complet. Je respecte les limitations documentées, notamment certaines formes de like, now() et WindowsRegistry.

Temps réel, WNS et erreurs de transport

Temps réel signifie que la demande part vers le poste au moment de l’exécution. Cela ne promet pas une réponse si l’appareil dort, n’a pas de réseau ou ne reçoit pas WNS.

Je différencie timeout, limite de requêtes, requête invalide et zéro résultat. Réexécuter quinze fois un timeout ne corrige pas la connectivité et consomme la limite par minute.

Pour un poste hors ligne, l’inventaire récent ou les données Defender peuvent répondre partiellement. Je nomme alors clairement la fraîcheur et la source.

Confiance, confidentialité et exploitation

Microsoft indique qu’un utilisateur administrateur peut modifier certaines informations côté client. Une requête registre n’est donc pas une attestation cryptographique. Pour la conformité, je croise avec les mécanismes de sécurité adaptés.

Les requêtes WindowsEvent ou Process peuvent révéler des noms utilisateur, chemins ou arguments. Je limite la projection et j’anonymise le résultat avant de l’ajouter à un ticket partagé.

Une bibliothèque support est versionnée. Chaque requête possède un propriétaire, une date de revalidation, un exemple positif/négatif et la conduite à tenir ; sinon elle devient une collection de snippets incompris.

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.

// Service IME et état courant
WindowsService
| where ServiceName == 'IntuneManagementExtension'
| project ServiceName, State, StartMode, PathName

// Correctifs Windows les plus récents
WindowsQfe
| project HotFixId, InstalledOn
| order by InstalledOn desc

// Valeur métier précise, à adapter à un chemin non sensible
WindowsRegistry('HKEY_LOCAL_MACHINE\SOFTWARE\Fabrikam')
| where ValueName == 'Version'
| project ValueName, ValueData

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

• requête sous 2 048 caractères
• résultat sous 128 Ko
• réponse interprétable
• zéro ligne distingué d’une erreur
• aucune donnée excessive
• bibliothèque validée L1/L2

Journaux, diagnostic et constitution des preuves

Pour un échec, je conserve l’heure, le texte de requête, le device, le statut et le message sans recopier les données métiers. Je vérifie ensuite l’état réseau et WNS.

Je ne transforme pas Device Query en polling. La limite et le caractère interactif imposent un usage ponctuel ; l’inventaire ou une API de reporting conviennent mieux à la collecte régulière.

• licence/capacité
• RBAC et scope tag
• appareil corporate et Entra join
• connectivité WNS
• requête exacte
• taille/nombre de lignes
• message d’erreur
• seconde preuve si décision sensible

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 : aucun changement poste
• Rollback : retirer une requête enregistrée obsolète
• Rollback : révoquer le rôle personnalisé si périmètre incorrect
• Vigilance : WNS obligatoire
• Vigilance : 15 requêtes/minute
• Vigilance : données client non attestées
• Vigilance : Device Query n’est pas un moteur de remédiation