Microsoft Graph Reports Export API : industrialiser les exports Intune

L’essentiel

Le point d’entrée deviceManagement/reports/exportJobs reçoit un reportName et des options comme select, filter, format et localization selon le rapport. La liste des noms et propriétés disponibles est documentée séparément et évolue.

La création retourne un objet de job. Le client interroge ensuite son statut jusqu’à completion, récupère l’URL temporaire, télécharge l’archive et traite le CSV ou JSON; il doit aussi gérer failed, expiration et réponses throttled.

Je sépare collecte brute, normalisation et restitution. Chaque fichier possède horodatage UTC, reportName, paramètres, version de schéma, hash et identifiant de corrélation, sans token ni URL signée conservés dans les logs.

Le point d’entrée deviceManagement/reports/exportJobs reçoit un reportName et des options comme select, filter, format et localization selon le rapport. La liste des noms et propriétés disponibles est documentée séparément et évolue.

Pourquoi cette technologie existe

L’API d’export unifie les rapports migrés vers la nouvelle infrastructure Intune. Je pars de la page des rapports et propriétés disponibles afin d’utiliser le reportName et les colonnes exacts plutôt que de deviner le schéma.

Le POST sur exportJobs contient le format, la sélection de colonnes, un filtre OData lorsque le rapport le supporte et éventuellement la localisation. Réduire select limite le volume, l’exposition de données et les ruptures de schéma.

Le service traite le job de manière asynchrone. La réponse fournit un identifiant; le client interroge l’objet sans boucle agressive et respecte Retry-After ou un backoff exponentiel avec jitter.

Export API des rapports Intune s’appuie sur la chaîne POST → Poll → Download → Pipeline. 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 licence Intune active, identité Graph dédiée, permissions minimales approuvées, reportName et schéma documenté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 400 Bad Request, 403 Forbidden et 429 Too Many Requests. 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. POST ouvre la séquence: Création exportJob avec reportName. Poll prend ensuite le relais: Suivi asynchrone avec backoff. Le traitement se poursuit avec Download, où Archive temporaire CSV ou JSON. Enfin, Pipeline ferme la boucle: Validation, historique et publication. 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. « 400 Bad Request » conduit d’abord à vérifier Body et catalogue, car la cause possible est ReportName ou filtre invalide. Pour « 403 Forbidden », la preuve utile devient Token claims et RBAC. Les cas « 429 Too Many Requests » et « URL expirée » 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 Export API des rapports Intune expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions licence Intune active, identité Graph dédiée, permissions minimales approuvées, reportName et schéma documentés doivent être réunies en même temps. La validation porte ensuite sur Choisir reportName et colonnes officielles, Créer un exportJob pilote, Poller avec backoff jusqu’au statut terminal et Télécharger sans journaliser l’URL. 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

L’API d’export unifie les rapports migrés vers la nouvelle infrastructure Intune. Je pars de la page des rapports et propriétés disponibles afin d’utiliser le reportName et les colonnes exacts plutôt que de deviner le schéma.

Le POST sur exportJobs contient le format, la sélection de colonnes, un filtre OData lorsque le rapport le supporte et éventuellement la localisation. Réduire select limite le volume, l’exposition de données et les ruptures de schéma.

Le service traite le job de manière asynchrone. La réponse fournit un identifiant; le client interroge l’objet sans boucle agressive et respecte Retry-After ou un backoff exponentiel avec jitter.

Prérequis, compatibilité et limites de support

Le fonctionnement décrit suppose licence Intune active, identité Graph dédiée, permissions minimales approuvées, reportName et schéma documentés, stockage temporaire protégé. Ces conditions permettent de distinguer une limite de Export API des rapports Intune d’un scénario simplement non éligible.

• licence Intune active
• identité Graph dédiée
• permissions minimales approuvées
• reportName et schéma documentés
• stockage temporaire protégé
• backoff et limites de taille
• contrôles qualité et rétention

Cycle de fonctionnement, étape par étape

Le cycle de Export API des rapports Intune traverse POST → Poll → Download → Pipeline. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Export API des rapports Intune, les étapes « Identifier les composants », « Observer le traitement », « Relier les états », « Valider le modèle » séparent l’intention, son transport, son traitement et le résultat final.

Fonctionnement détaillé de Export API des rapports Intune

L’API d’export unifie les rapports migrés vers la nouvelle infrastructure Intune. Je pars de la page des rapports et propriétés disponibles afin d’utiliser le reportName et les colonnes exacts plutôt que de deviner le schéma.

Le POST sur exportJobs contient le format, la sélection de colonnes, un filtre OData lorsque le rapport le supporte et éventuellement la localisation. Réduire select limite le volume, l’exposition de données et les ruptures de schéma.

Le service traite le job de manière asynchrone. La réponse fournit un identifiant; le client interroge l’objet sans boucle agressive et respecte Retry-After ou un backoff exponentiel avec jitter.

• licence Intune active
• identité Graph dédiée
• permissions minimales approuvées
• reportName et schéma documentés

Traitement, exploitation et cas limites de Export API des rapports Intune

Quand le statut est completed, la propriété url pointe vers une archive à durée limitée. Je la télécharge immédiatement dans un stockage temporaire protégé et je ne journalise pas l’URL, car elle peut embarquer une signature d’accès.

L’archive contient un ou plusieurs fichiers selon le rapport et le format. Le pipeline vérifie extension, taille maximale, hash, encodage, colonnes obligatoires et nombre de lignes avant de déplacer le fichier vers l’historique.

Un statut failed est conservé avec le message et les request-id, mais sans bearer token. Les erreurs 401 et 403 sont séparées d’un reportName invalide, d’un filtre non supporté, d’un 429 ou d’une indisponibilité 5xx.

• Valider archive et schéma
• Comparer un échantillon au portail
• Planifier avec alertes et rétention

Lire les états propres à Export API des rapports Intune

L’identité d’automatisation reçoit la permission Graph la moins privilégiée indiquée pour l’API et, si nécessaire, les droits Intune associés. Managed identity ou certificat est préféré à un secret longue durée.

La fréquence tient compte des limites publiées, du volume et de la fraîcheur métier. Je ne lance pas un export complet toutes les minutes si une extraction quotidienne répond à l’objectif; je répartis les jobs et historise les succès.

Le contrôle de qualité compare quelques appareils au portail, mesure la couverture, détecte les colonnes ajoutées ou supprimées et refuse de publier un dataset incomplet. La Data Warehouse reste plus adaptée à certaines analyses historiques et relationnelles.

• 400 Bad Request — Body et catalogue
• 403 Forbidden — Token claims et RBAC
• 429 Too Many Requests — Retry-After
• URL expirée — Job completed time

Pilote et suivi opérationnel de Export API des rapports Intune

Le pilote couvre le périmètre Microsoft Graph, Intune reports, Export API, Automation et contrôle Choisir reportName et colonnes officielles. Créer un exportJob pilote. Poller avec backoff jusqu’au statut terminal. Les résultats sont segmentés selon les populations réellement concernées par Export API des rapports Intune.

Les cas d’échec « 400 Bad Request », « 403 Forbidden », « 429 Too Many Requests » sont reproduits lorsque c’est possible. Ils vérifient que l’écart reste visible et que la procédure indique une preuve exploitable.

Le suivi après déploiement conserve endpoint beta à revalider avant production, ne jamais loguer token ou URL signée, respecter Retry-After, un export réussi ne garantit pas la couverture. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Interfaces d’observation, commandes et exemples

Les exemples rendent visibles Choisir reportName et colonnes officielles. Créer un exportJob pilote. Poller avec backoff jusqu’au statut terminal. Télécharger sans journaliser l’URL. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Export API des rapports 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.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
  $uri = 'https://graph.microsoft.com/beta/deviceManagement/reports/exportJobs'
  $body = @{reportName='Devices';format='csv';select=@('DeviceId','DeviceName','OSVersion')} | ConvertTo-Json
  $job = Invoke-MgGraphRequest -Method POST -Uri $uri -Body $body -ContentType 'application/json'
  do { Start-Sleep -Seconds 10; $state = Invoke-MgGraphRequest -Method GET -Uri "$uri/$($job.id)" } while ($state.status -in @('notStarted','inProgress'))
  if ($state.status -ne 'completed') { throw "Export en échec : $($state.status)" }
  [pscustomobject]@{Id=$state.id;Status=$state.status;ExpirationDateTime=$state.expirationDateTime}
} catch { Write-Error "Export Intune impossible : $($_.Exception.Message)"; exit 1 }

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

La chronologie de Export API des rapports Intune relie POST, Poll, Download, Pipeline. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Choisir reportName et colonnes officielles. Créer un exportJob pilote. Poller avec backoff jusqu’au statut terminal. Télécharger sans journaliser l’URL. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « ReportName ou filtre invalide », « Permission ou rôle absent », « Polling ou cadence excessive » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Choisir reportName et colonnes officielles.
• Créer un exportJob pilote.
• Poller avec backoff jusqu’au statut terminal.
• Télécharger sans journaliser l’URL.
• Valider archive et schéma
• Comparer un échantillon au portail
• Planifier avec alertes et rétention

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque Choisir reportName et colonnes officielles, Créer un exportJob pilote, Poller avec backoff jusqu’au statut terminal et Télécharger sans journaliser l’URL. Ces contrôles relient la configuration du service au résultat réellement observé.

• Choisir reportName et colonnes officielles.
• Créer un exportJob pilote.
• Poller avec backoff jusqu’au statut terminal.
• Télécharger sans journaliser l’URL.
• Valider archive et schéma
• Comparer un échantillon au portail
• Planifier avec alertes et rétention

Limites, modes de panne et lecture des erreurs

Les écarts connus de Export API des rapports Intune incluent 400 Bad Request, 403 Forbidden, 429 Too Many Requests, URL expirée. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de Export API des rapports Intune commence sur le périmètre Microsoft Graph, Intune reports, Export API, Automation, Endpoint & Automation — POST, Poll, Download, Pipeline, licence Intune active, identité Graph dédiée, permissions minimales approuvées. Les limites et actions de réversibilité ci-dessous cadrent la progression.