Intune Data Warehouse et Power BI : construire un modèle de reporting exploitable

Résumé

Intune Data Warehouse expose des données Intune au format OData v4 pour l’analyse historique et les rapports. L’URL et le $metadata du tenant constituent le contrat réel du modèle disponible.

Les collections ne partagent pas toutes le même grain. devices décrit un état courant, devicePropertyHistories un instantané historique et certaines collections des comptes agrégés. Les joindre sans pré-agrégation produit des doublons et des totaux faux.

Je recommande le connecteur Flux OData ou la méthode Intune v2 documentée, une identité de rafraîchissement au moindre privilège, un modèle en étoile et des contrôles de cardinalité avant toute visualisation.

Intune Data Warehouse expose des données Intune au format OData v4 pour l’analyse historique et les rapports. L’URL et le $metadata du tenant constituent le contrat réel du modèle disponible.

Contexte, objectif et périmètre

Les rapports intégrés répondent aux besoins courants, mais les opérations ont souvent besoin de tendances, corrélations et historiques personnalisés. Data Warehouse répond à ce besoin sans devenir une source temps réel.

Le schéma évolue. Des entités historiques ont été retirées et les capacités OData ne sont pas uniformes. Une requête valide sur une collection peut échouer sur une autre si elle utilise un filtre non supporté.

Je traite « Intune Data Warehouse et Power BI » 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 architecture et fraîcheur
• Objectif : construire un modèle sans relations ambiguës
• Objectif : sécuriser le rafraîchissement et valider les mesures
• Périmètre : API Data Warehouse v1.0 et Power BI
• Périmètre : devices, historique, enrollment, compliance, configuration et applications agrégées
• Périmètre : complémentarité avec Graph et rapports export

Architecture et fonctionnement général

Le service Data Warehouse est séparé des ressources Graph temps réel. Il optimise l’analytique et l’historique, avec une fraîcheur et une rétention propres aux collections.

OData expose des dimensions et faits. Les clés techniques comme deviceKey servent aux relations ; l’identifiant Entra ou Intune répond à d’autres usages. Les dimensions de libellés évitent de coder durablement des valeurs numériques susceptibles d’évoluer.

Power Query doit limiter colonnes et lignes le plus tôt possible, dans les limites du service. Power BI construit ensuite un modèle en étoile où les relations un-à-plusieurs suivent le grain et restent à sens unique par défaut.

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.

• URL OData du tenant
• rôle Intune RBAC suffisant sans Global Administrator
• Power BI Desktop supporté
• espace de travail et identité de refresh gouvernés
• dictionnaire de données et objectifs KPI

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.

Le grain avant la relation

devices porte l’état courant d’un appareil. devicePropertyHistories produit des observations par date et device. enrollmentActivities contient déjà des comptes agrégés par dimensions. Additionner ou joindre ces lignes sans respecter leur grain multiplie les résultats.

Je décris chaque table par sa clé candidate, sa date, son niveau de détail et ses dimensions. Avant une relation un-à-plusieurs, je contrôle que le côté un ne contient aucun doublon.

L’erreur Power BI 0x80040E4E peut refléter une cardinalité incorrecte. Je vérifie d’abord clés et doublons avant de modifier régionalisation ou connecteur.

OData, filtres et schéma vivant

$metadata révèle la casse exacte des propriétés, leurs types et les collections exposées. Je le conserve avec la version du modèle pour détecter une évolution.

La prise en charge de $filter est limitée et dépend des propriétés, souvent DateKey ou RowLastModifiedDateTimeUTC. Je ne suppose pas que $expand, $count ou $orderby fonctionneront partout parce qu’ils appartiennent à OData.

La version beta facilite l’exploration mais peut casser. Un rapport de production reste sur v1.0 sauf décision explicite, preuve de valeur et plan de migration.

Choisir Data Warehouse, Graph ou Reports

Data Warehouse convient aux tendances et jointures analytiques. Graph deviceManagement répond mieux à une lecture opérationnelle d’objet. Reports Export API couvre certains exports Intune non présents dans Warehouse.

Je n’utilise pas Data Warehouse pour déclencher une remédiation en temps réel. Sa fraîcheur n’est pas celle d’un contrôle direct du device.

Un même tableau de bord peut combiner plusieurs sources si leur fréquence, identité et grain sont clairement indiqués. Sans cela, l’utilisateur compare des données qui ne décrivent pas la même fenêtre.

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.

let
    Source = OData.Feed(
        "https://fef.<tenant>.manage.microsoft.com/ReportingService/DataWarehouseFEService/devices?api-version=v1.0",
        null,
        [Implementation = "2.0"]
    ),
    Selected = Table.SelectColumns(Source, {"deviceKey", "deviceName", "osVersion", "lastSyncDateTime"})
in
    Selected

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

• schéma confirmé
• grains documentés
• relations sans ambiguïté
• mesures comparées à Intune
• refresh réussi
• RLS et partage testés

Journaux, diagnostic et constitution des preuves

Je journalise durée, volume et heure de chaque refresh. Une erreur HTTP 400 après ajout d’un filtre conduit à vérifier sa prise en charge dans la collection, pas à conclure que l’API est indisponible.

Je compare quelques devices connus entre Intune et Power BI, puis les comptes agrégés. Les écarts attendus liés à la fraîcheur sont documentés ; les écarts inexpliqués bloquent la publication.

• $metadata du tenant
• requête OData et paramètres
• grain et cardinalités
• historique de refresh
• identité et RBAC
• comparaison avec rapports Intune

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 : conserver ancien PBIX pendant la fenêtre
• Rollback : désactiver refresh du nouveau dataset
• Rollback : réaffecter utilisateurs à l’ancien rapport
• Vigilance : ne pas utiliser Global Administrator
• Vigilance : ne pas coder en dur des enums non documentées
• Vigilance : ne pas utiliser beta sans dérogation