Azure Automation et Microsoft Graph : construire un reporting Intune exploitable

L’essentiel

Un Automation Account héberge runbooks, modules, variables non secrètes, schedules et jobs. Une Managed Identity lui permet d’obtenir des tokens Entra sans stocker un mot de passe ou un certificat dans le code.

Le Graph PowerShell SDK n’est pas préchargé intégralement. J’importe Microsoft.Graph.Authentication et seulement les modules nécessaires, avec versions validées et compatibilité PowerShell contrôlée.

Pour les rapports Intune asynchrones, le runbook crée un exportJob, attend un état terminal avec backoff, télécharge l’archive temporaire, valide le schéma puis écrit dans un stockage durable protégé.

Un Automation Account héberge runbooks, modules, variables non secrètes, schedules et jobs. Une Managed Identity lui permet d’obtenir des tokens Entra sans stocker un mot de passe ou un certificat dans le code.

Pourquoi cette technologie existe

Le compte Automation définit la région, l’identité, la politique de réseau, les modules et la rétention des jobs. Dev, recette et production sont séparés afin de ne pas tester une permission ou un module sur le traitement quotidien.

La system-assigned Managed Identity convient à un compte unique; une user-assigned identity facilite une identité stable partagée, mais augmente le rayon d’impact. Les rôles Graph sont accordés au service principal correspondant.

Les runbooks PowerShell modernes utilisent le runtime supporté par les modules choisis. Je verrouille les versions de Microsoft.Graph.Authentication et des sous-modules plutôt que d’importer aveuglément tout le SDK.

Azure Automation pour le reporting Intune s’appuie sur la chaîne Schedule → Runbook → Identity → Storage. 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 abonnement Azure et Automation Account, Managed Identity dédiée, permissions Graph minimales, modules versionné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 Module introuvable, Managed Identity 403 et Job dépasse la durée. 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. Schedule ouvre la séquence: Déclenche un job avec paramètres figés. Runbook prend ensuite le relais: PowerShell orchestre Graph et contrôles. Le traitement se poursuit avec Identity, où Managed Identity reçoit les app roles minimaux. Enfin, Storage ferme la boucle: Raw, normalized et logs sont séparés. 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. « Module introuvable » conduit d’abord à vérifier Modules et job stream, car la cause possible est Import ou runtime incompatible. Pour « Managed Identity 403 », la preuve utile devient Service principal et token. Les cas « Job dépasse la durée » et « Fichier vide publié » 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 Azure Automation pour le reporting Intune expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions abonnement Azure et Automation Account, Managed Identity dédiée, permissions Graph minimales, modules versionnés doivent être réunies en même temps. La validation porte ensuite sur Créer l’environnement Automation de recette, Activer l’identité et accorder une lecture minimale, Importer les modules figés et Exécuter un runbook manuel borné. 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 Automation définit la région, l’identité, la politique de réseau, les modules et la rétention des jobs. Dev, recette et production sont séparés afin de ne pas tester une permission ou un module sur le traitement quotidien.

La system-assigned Managed Identity convient à un compte unique; une user-assigned identity facilite une identité stable partagée, mais augmente le rayon d’impact. Les rôles Graph sont accordés au service principal correspondant.

Les runbooks PowerShell modernes utilisent le runtime supporté par les modules choisis. Je verrouille les versions de Microsoft.Graph.Authentication et des sous-modules plutôt que d’importer aveuglément tout le SDK.

Prérequis, compatibilité et limites de support

Le fonctionnement décrit suppose abonnement Azure et Automation Account, Managed Identity dédiée, permissions Graph minimales, modules versionnés, stockage chiffré et rétention. Ces conditions permettent de distinguer une limite de Azure Automation pour le reporting Intune d’un scénario simplement non éligible.

• abonnement Azure et Automation Account
• Managed Identity dédiée
• permissions Graph minimales
• modules versionnés
• stockage chiffré et rétention
• schedule UTC
• alertes et runbook de reprise

Cycle de fonctionnement, étape par étape

Le cycle de Azure Automation pour le reporting Intune traverse Schedule → Runbook → Identity → Storage. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Azure Automation pour le reporting 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 Azure Automation pour le reporting Intune

Le compte Automation définit la région, l’identité, la politique de réseau, les modules et la rétention des jobs. Dev, recette et production sont séparés afin de ne pas tester une permission ou un module sur le traitement quotidien.

La system-assigned Managed Identity convient à un compte unique; une user-assigned identity facilite une identité stable partagée, mais augmente le rayon d’impact. Les rôles Graph sont accordés au service principal correspondant.

Les runbooks PowerShell modernes utilisent le runtime supporté par les modules choisis. Je verrouille les versions de Microsoft.Graph.Authentication et des sous-modules plutôt que d’importer aveuglément tout le SDK.

• abonnement Azure et Automation Account
• Managed Identity dédiée
• permissions Graph minimales
• modules versionnés

Traitement, exploitation et cas limites de Azure Automation pour le reporting Intune

Un schedule déclenche le runbook selon UTC. Les paramètres obligatoires, valeurs par défaut et fuseau sont documentés; un décalage heure d’été ne doit pas déplacer silencieusement la fenêtre de données.

Le runbook est idempotent: un identifiant de période et de rapport permet de détecter un fichier déjà validé. Une reprise ne duplique pas les lignes et ne remplace pas une archive saine par un job incomplet.

Graph peut retourner 429 avec Retry-After, 5xx temporaire ou un job encore inProgress. Le runbook applique backoff, jitter, limite globale de durée et sortie distincte pour erreur fonctionnelle et erreur transitoire.

• Valider archive, hash et schéma
• Tester 429, reprise et doublon
• Activer schedule et alertes

Lire les états propres à Azure Automation pour le reporting Intune

Le stockage sépare zone brute immuable, données normalisées et publication. Les URLs signées et tokens ne sont jamais conservés; les fichiers possèdent hash, taille, schéma, horodatage UTC et corrélation.

La supervision alerte sur absence de succès, durée anormale, volume nul, schéma modifié, throttling persistant et échec d’écriture. Un job Completed sans fichier valide reste un échec opérationnel.

Le rollback désactive le schedule, conserve les données validées et repasse au runbook précédent. Les permissions nouvelles sont révoquées après vérification qu’aucun autre workload ne partage l’identité.

• Module introuvable — Modules et job stream
• Managed Identity 403 — Service principal et token
• Job dépasse la durée — Timeline et Retry-After
• Fichier vide publié — Rows et schéma

Pilote et suivi opérationnel de Azure Automation pour le reporting Intune

Le pilote couvre le périmètre Azure Automation, Microsoft Graph, Intune, Managed Identity et contrôle Créer l’environnement Automation de recette. Activer l’identité et accorder une lecture minimale. Importer les modules figés. Les résultats sont segmentés selon les populations réellement concernées par Azure Automation pour le reporting Intune.

Les cas d’échec « Module introuvable », « Managed Identity 403 », « Job dépasse la durée » 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 MFA interdit le compte utilisateur non interactif, verrouiller les modules, ne pas loguer les URLs signées, distinguer job Azure réussi et donnée valide. 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 Créer l’environnement Automation de recette. Activer l’identité et accorder une lecture minimale. Importer les modules figés. Exécuter un runbook manuel borné. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Azure Automation pour le reporting 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 {
  Connect-MgGraph -Identity -NoWelcome
  $context = Get-MgContext
  $response = Invoke-MgGraphRequest -Method GET -Uri 'https://graph.microsoft.com/v1.0/deviceManagement/managedDevices?%24top=1&%24select=id,deviceName,lastSyncDateTime'
  [pscustomobject]@{TenantId=$context.TenantId;Count=$response.value.Count;CheckedAt=(Get-Date).ToUniversalTime()}
} catch { Write-Error "Test du runbook impossible : $($_.Exception.Message)"; exit 1 }
finally { Disconnect-MgGraph -ErrorAction SilentlyContinue }

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

La chronologie de Azure Automation pour le reporting Intune relie Schedule, Runbook, Identity, Storage. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Créer l’environnement Automation de recette. Activer l’identité et accorder une lecture minimale. Importer les modules figés. Exécuter un runbook manuel borné. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Import ou runtime incompatible », « App role absent », « Polling ou volume » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Créer l’environnement Automation de recette.
• Activer l’identité et accorder une lecture minimale.
• Importer les modules figés.
• Exécuter un runbook manuel borné.
• Valider archive, hash et schéma
• Tester 429, reprise et doublon
• Activer schedule et alertes

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque Créer l’environnement Automation de recette, Activer l’identité et accorder une lecture minimale, Importer les modules figés et Exécuter un runbook manuel borné. Ces contrôles relient la configuration du service au résultat réellement observé.

• Créer l’environnement Automation de recette.
• Activer l’identité et accorder une lecture minimale.
• Importer les modules figés.
• Exécuter un runbook manuel borné.
• Valider archive, hash et schéma
• Tester 429, reprise et doublon
• Activer schedule et alertes

Limites, modes de panne et lecture des erreurs

Les écarts connus de Azure Automation pour le reporting Intune incluent Module introuvable, Managed Identity 403, Job dépasse la durée, Fichier vide publié. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de Azure Automation pour le reporting Intune commence sur le périmètre Azure Automation, Microsoft Graph, Intune, Managed Identity, Endpoint & Automation — Schedule, Runbook, Identity, Storage, abonnement Azure et Automation Account, Managed Identity dédiée, permissions Graph minimales. Les limites et actions de réversibilité ci-dessous cadrent la progression.