Pilotes et firmwares : orchestrer Windows Update, Intune et Microsoft Graph

L’essentiel

Une driver update policy inscrit les appareils dans la gestion cloud des pilotes. Intune transmet affectation, approbations et pauses à Windows Autopatch; Windows Update détermine les mises à jour réellement applicables.

Le mode automatique simplifie l’approbation selon le service; le mode manuel permet de sélectionner les drivers après inventaire. Je recommande une seule policy de drivers par appareil pour éviter des décisions difficiles à expliquer: dans certains conflits, une approbation peut gagner sur une pause.

Les APIs Windows Updates sous /admin/windows/updates permettent de manipuler catalogues, déploiements et audiences selon le type de contenu. Toute automatisation vérifie v1.0/beta, permissions WindowsUpdates.ReadWrite.All, rôle et idempotence.

Une driver update policy inscrit les appareils dans la gestion cloud des pilotes. Intune transmet affectation, approbations et pauses à Windows Autopatch; Windows Update détermine les mises à jour réellement applicables.

Pourquoi cette technologie existe

Les pilotes et firmwares peuvent corriger sécurité et stabilité, mais ils touchent stockage, réseau, affichage, BIOS et périphériques. La stratégie exige davantage de représentativité matérielle qu’un anneau de qualité Windows classique.

Un outil OEM peut publier plus tôt ou proposer du contenu absent de Windows Update. Je documente l’autorité choisie par modèle et évite deux moteurs capables de flasher le même firmware.

Pilotes et firmwares avec Intune et Graph s’appuie sur la chaîne OEM → Intune → Autopatch → WUA. 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 et Entra/Intune éligibles, source de scan Windows Update, télémétrie/diagnostic requis, inventaire modèles/BIOS/drivers. 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 Driver absent du catalogue, Approuvé mais non offert et Pause inefficace. 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. OEM ouvre la séquence: Publie métadonnées et contenu Windows Update. Intune prend ensuite le relais: Policy, approbation, pause et audience. Le traitement se poursuit avec Autopatch, où Orchestration cloud et reporting. Enfin, WUA ferme la boucle: Applicabilité, téléchargement, installation et reboot. 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. « Driver absent du catalogue » conduit d’abord à vérifier WU Catalog et inventaire matériel, car la cause possible est Non publié/non applicable. Pour « Approuvé mais non offert », la preuve utile devient WindowsUpdateClient et policy. Les cas « Pause inefficace » et « Firmware é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 Pilotes et firmwares avec Intune et Graph expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions licence et Entra/Intune éligibles, source de scan Windows Update, télémétrie/diagnostic requis, inventaire modèles/BIOS/drivers doivent être réunies en même temps. La validation porte ensuite sur policy unique par device, échantillon par modèle, versions avant/après et aucun incident critique. 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’appareil affecté à une policy remonte les drivers applicables. En mode manuel, l’administrateur approuve et planifie un contenu. L’offre dépend encore de la classification Windows Update et du matériel détecté.

Les paramètres d’expérience et deadline proviennent des politiques Windows Update. Une policy driver ne remplace donc pas la conception des redémarrages, heures actives et notifications.

Graph représente un déploiement et son audience. Les appareils Entra sont membres ou exclusions, et l’ajout peut entraîner leur inscription au service pour le contenu. Un statut 202 Accepted exige un suivi asynchrone.

Prérequis, compatibilité et limites de support

Le fonctionnement décrit suppose licence et Entra/Intune éligibles, source de scan Windows Update, télémétrie/diagnostic requis, inventaire modèles/BIOS/drivers, une seule policy driver par device recommandée. Ces conditions permettent de distinguer une limite de Pilotes et firmwares avec Intune et Graph d’un scénario simplement non éligible.

• licence et Entra/Intune éligibles
• source de scan Windows Update
• télémétrie/diagnostic requis
• inventaire modèles/BIOS/drivers
• une seule policy driver par device recommandée
• anneau de laboratoire matériel
• permission et rôle Graph minimaux

Cycle de fonctionnement, étape par étape

Le cycle de Pilotes et firmwares avec Intune et Graph traverse OEM → Intune → Autopatch → WUA. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Pilotes et firmwares avec Intune et Graph, les étapes « Cartographier le matériel », « Créer la policy pilote », « Approuver par vague », « Automatiser après stabilisation » séparent l’intention, son transport, son traitement et le résultat final.

Applicabilité et publication OEM

Seuls les drivers publiés dans Windows Update et applicables à au moins un appareil de la policy apparaissent. Une absence ne prouve pas qu’aucune version OEM n’existe.

Je recherche le nom exact dans Microsoft Update Catalog et les notes OEM. La version de package ne suffit pas toujours à ordonner deux firmwares; date, ciblage matériel et recommandations constructeur comptent.

Les périphériques branchables peuvent recevoir un driver si l’OEM l’a publié et qu’il est applicable. Le pilote doit donc couvrir les docks et accessoires réellement utilisés.

Conflits de policies et autorité

Microsoft permet plusieurs policies driver mais le déconseille. Si un contenu est approuvé dans l’une et mis en pause dans l’autre, l’approbation peut l’emporter. Une policy unique simplifie la preuve.

Je vérifie ExcludeWUDriversInQualityUpdate et les anciens paramètres GPO. Les policies driver dédiées et l’inclusion générale de drivers ne doivent pas produire un parcours incompris.

Un outil OEM reste possible lorsque Windows Update ne couvre pas le besoin, mais il possède une population exclusive et une liste de contenus. Deux autorités de firmware sur le même modèle constituent un NO-GO.

Graph, audiences et automatisation

Les APIs Windows Updates utilisent les permissions WindowsUpdates.Read.All ou ReadWrite.All et des rôles supportés. Les pages beta rappellent que leur usage production n’est pas garanti; je vérifie chaque ressource dans v1.0.

Je calcule l’audience souhaitée depuis des groupes et inventaires, puis je compare à l’audience actuelle. L’automatisation ajoute et retire uniquement le delta, avec un plafond par exécution.

Le 202 de updateAudience confirme l’acceptation, pas la fin. Je relis l’audience, le déploiement, les rapports et l’état local avant de déclarer la vague réussie.

Interfaces d’observation, commandes et exemples

Les exemples rendent visibles modèle/MTM et BIOS, driver actuel/cible, policy et approbation, source de scan. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Pilotes et firmwares avec Intune et Graph, 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 {
  $bios = Get-CimInstance Win32_BIOS
  $drivers = Get-CimInstance Win32_PnPSignedDriver | Where-Object { $_.DeviceName -and $_.DriverVersion } |
    Select-Object DeviceName, Manufacturer, DriverProviderName, DriverVersion, DriverDate, InfName
  [pscustomobject]@{ BiosVersion=$bios.SMBIOSBIOSVersion; BiosDate=$bios.ReleaseDate; DriverCount=$drivers.Count }
  $drivers | Sort-Object DeviceName
}
catch { Write-Error "Inventaire pilotes impossible : $($_.Exception.Message)"; exit 1 }

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

J’analyse WindowsUpdateClient/Operational, SetupAPI.dev.log, UpdateSessionOrchestration.etl et les rapports Driver Updates. Pour firmware, j’ajoute événements OEM/UEFI et état d’alimentation.

Le registre WindowsUpdate aide à confirmer la source et les policies, mais le résultat d’applicabilité se lit dans la séquence de scan. Je conserve update ID, modèle, driver actuel/cible et heure.

• modèle/MTM et BIOS
• driver actuel/cible
• policy et approbation
• source de scan
• WindowsUpdateClient
• SetupAPI.dev.log
• reporting Intune
• restart/incident post-install

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque policy unique par device, échantillon par modèle, versions avant/après et aucun incident critique. Ces contrôles relient la configuration du service au résultat réellement observé.

• policy unique par device
• échantillon par modèle
• versions avant/après
• aucun incident critique
• reporting cohérent
• rollback OEM disponible
• automation WhatIf et delta testés

Limites, modes de panne et lecture des erreurs

Les écarts connus de Pilotes et firmwares avec Intune et Graph incluent Driver absent du catalogue, Approuvé mais non offert, Pause inefficace, Firmware é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 Pilotes et firmwares avec Intune et Graph commence sur le périmètre policies Windows Driver Updates Intune/Autopatch, drivers et firmwares publiés sur Windows Update, Windows Updates API Graph. Les limites et actions de réversibilité ci-dessous cadrent la progression.