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

L’essentiel

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.

Pourquoi cette technologie existe

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

Intune Data Warehouse et Power BI s’appuie sur la chaîne Intune → OData → Power Query → Model. 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 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. 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 HTTP 400, Totaux doublés et 0x80040E4E. 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. Intune ouvre la séquence: Alimente périodiquement le Data Warehouse. OData prend ensuite le relais: Expose collections, propriétés et métadonnées. Le traitement se poursuit avec Power Query, où Sélectionne, type et transforme les données. Enfin, Model ferme la boucle: Relations, mesures, RLS et visualisations. 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. « HTTP 400 » conduit d’abord à vérifier $metadata et requête minimale, car la cause possible est Filtre/propriété non supporté. Pour « Totaux doublés », la preuve utile devient Doublons côté dimension. Les cas « 0x80040E4E » et « Refresh Service échoue » 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 Intune Data Warehouse et Power BI expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions 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 doivent être réunies en même temps. La validation porte ensuite sur schéma confirmé, grains documentés, relations sans ambiguïté et mesures comparées à Intune. 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 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, compatibilité et limites de support

Le fonctionnement décrit suppose 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. Ces conditions permettent de distinguer une limite de Intune Data Warehouse et Power BI d’un scénario simplement non éligible.

• 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

Cycle de fonctionnement, étape par étape

Le cycle de Intune Data Warehouse et Power BI traverse Intune → OData → Power Query → Model. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Intune Data Warehouse et Power BI, les étapes « Découvrir le schéma », « Connecter Power BI », « Construire le modèle », « Publier et tester » séparent l’intention, son transport, son traitement et le résultat final.

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.

Interfaces d’observation, commandes et exemples

Les exemples rendent visibles $metadata du tenant, requête OData et paramètres, grain et cardinalités, historique de refresh. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Intune Data Warehouse et Power BI, 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.

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

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

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

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque schéma confirmé, grains documentés, relations sans ambiguïté et mesures comparées à Intune. Ces contrôles relient la configuration du service au résultat réellement observé.

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

Limites, modes de panne et lecture des erreurs

Les écarts connus de Intune Data Warehouse et Power BI incluent HTTP 400, Totaux doublés, 0x80040E4E, Refresh Service échoue. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de Intune Data Warehouse et Power BI commence sur le périmètre API Data Warehouse v1.0 et Power BI, devices, historique, enrollment, compliance, configuration et applications agrégées, complémentarité avec Graph et rapports export. Les limites et actions de réversibilité ci-dessous cadrent la progression.