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

L’essentiel

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.

Pourquoi cette technologie existe

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.

Device Query et KQL dans Intune s’appuie sur la chaîne Operator → Intune → WNS → Data. 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 capacité Intune Suite/add-on éligible, appareil corporate, Entra joined ou hybrid joined, permission Managed Devices/Query. 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 Timeout, Query limit exceeded et Résultat tronqué. 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. Operator ouvre la séquence: Sélectionne device et requête KQL autorisée. Intune prend ensuite le relais: Valide RBAC et envoie la demande. Le traitement se poursuit avec WNS, où Notifie le poste en ligne. Enfin, Data ferme la boucle: Le client interroge le schéma et retourne les lignes. 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. « Timeout » conduit d’abord à vérifier Connectivité et heure dernière activité, car la cause possible est Poste hors ligne ou WNS bloqué. Pour « Query limit exceeded », la preuve utile devient Compteur et heure. Les cas « Résultat tronqué » et « Colonne inconnue » 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 Device Query et KQL dans Intune expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions capacité Intune Suite/add-on éligible, appareil corporate, Entra joined ou hybrid joined, permission Managed Devices/Query doivent être réunies en même temps. La validation porte ensuite sur requête sous 2 048 caractères, résultat sous 128 Ko, réponse interprétable et zéro ligne distingué d’une erreur. 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 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, compatibilité et limites de support

Le fonctionnement décrit suppose capacité Intune Suite/add-on éligible, appareil corporate, Entra joined ou hybrid joined, permission Managed Devices/Query, WNS accessible. Ces conditions permettent de distinguer une limite de Device Query et KQL dans Intune d’un scénario simplement non éligible.

• 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

Cycle de fonctionnement, étape par étape

Le cycle de Device Query et KQL dans Intune traverse Operator → Intune → WNS → Data. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Device Query et KQL dans Intune, les étapes « Définir la question », « Construire une requête minimale », « Interpréter le résultat », « Capitaliser » séparent l’intention, son transport, son traitement et le résultat final.

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.

Interfaces d’observation, commandes et exemples

Les exemples rendent visibles licence/capacité, RBAC et scope tag, appareil corporate et Entra join, connectivité WNS. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Device Query et KQL dans 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.

// 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

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

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

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque requête sous 2 048 caractères, résultat sous 128 Ko, réponse interprétable et zéro ligne distingué d’une erreur. Ces contrôles relient la configuration du service au résultat réellement observé.

• 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

Limites, modes de panne et lecture des erreurs

Les écarts connus de Device Query et KQL dans Intune incluent Timeout, Query limit exceeded, Résultat tronqué, Colonne inconnue. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de Device Query et KQL dans Intune commence sur le périmètre postes Windows corporate Intune-managed, Entra joined ou hybrid joined, requêtes à la demande sur un appareil. Les limites et actions de réversibilité ci-dessous cadrent la progression.