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

Résumé

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.

Contexte, objectif et périmètre

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.

Je traite « Pilotes et firmwares avec Intune et Graph » 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 la chaîne d’approbation et d’applicabilité
• Objectif : construire des anneaux par modèle et criticité
• Objectif : automatiser les audiences avec garde-fous
• Périmètre : policies Windows Driver Updates Intune/Autopatch
• Périmètre : drivers et firmwares publiés sur Windows Update
• Périmètre : Windows Updates API Graph

Architecture et fonctionnement général

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

• 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

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.

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.

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.

# Exemple pédagogique non testé — niveau 1
$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 }

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

• 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

Journaux, diagnostic et constitution des preuves

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

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 : pause/exclusion du contenu
• Rollback : retirer audience pilote
• Rollback : installer version précédente uniquement si OEM supporte le downgrade
• Rollback : restaurer policy/audience snapshot
• Vigilance : firmware peut être non réversible
• Vigilance : alimentation requise
• Vigilance : beta Graph à revalider
• Vigilance : approbation peut gagner sur pause multi-policy