Windows Update : identifier l’autorité réelle entre Intune, WUfB, WSUS, MECM et outils tiers

Résumé opérationnel

Intune peut configurer les CSP Update tandis qu’une GPO WSUS, le client MECM ou un agent tiers conserve la source de scan. Le poste applique alors une combinaison que le portail seul ne montre pas.

Je lis PolicyManager, Policies\Microsoft\Windows\WindowsUpdate, le workload co-management, les services WUA et WindowsUpdateClient/Operational dans la même fenêtre.

Je ne réinitialise pas SoftwareDistribution et je ne supprime pas les policies avant d’avoir identifié leur provenance. Ces actions masquent le conflit et peuvent interrompre d’autres déploiements.

Intune peut configurer les CSP Update tandis qu’une GPO WSUS, le client MECM ou un agent tiers conserve la source de scan. Le poste applique alors une combinaison que le portail seul ne montre pas.

Symptôme, contexte et périmètre de l’incident

Les anneaux Intune règlent offre et expérience, mais les anciennes valeurs WUServer/WUStatusServer et UseWUServer peuvent diriger le scan vers WSUS. Les scan source policies doivent être interprétées selon la version Windows.

En co-management, le workload Windows Update policies et l’état du client Configuration Manager déterminent qui pilote. Un basculement de workload sans retrait des anciennes policies laisse des traces concurrentes.

Je commence par nommer le propriétaire de la décision, la population concernée et la preuve attendue. Cette étape paraît administrative, mais elle évite qu’un réglage technique soit utilisé pour compenser une responsabilité non définie entre identité, sécurité, support et gestion du poste.

La console cloud représente une intention et un état remonté. Je la compare toujours au résultat local, à l’identité réellement utilisée et à l’heure du dernier traitement. Une valeur verte, une affectation ou un HTTP 200 ne suffit pas à prouver tout le parcours.

• Inclus dans l’analyse : Windows Update, WUfB, WSUS
• Inclus dans l’analyse : postes Windows et services Microsoft documentés
• Inclus dans l’analyse : pilote représentatif avant généralisation

Questions à résoudre et méthode de diagnostic

Pour diagnostiquer « Troubleshooting de l’autorité Windows Update », je pars du symptôme exact et de son horodatage. Je formule plusieurs causes possibles, puis je recherche la preuve qui permet de confirmer ou d’écarter chacune d’elles. Une affectation visible dans le portail, un code isolé ou un état ancien ne suffisent pas à établir la cause.

La première collecte reste en lecture seule : contexte utilisateur ou SYSTEM, version de Windows, version des composants, identifiants de corrélation, événements, journaux et état du registre. Je ne vide pas un cache et je ne supprime ni clé, ni certificat, ni objet avant d’avoir conservé ces éléments.

Je localise ensuite la première phase qui diverge, je corrige une seule cause à la fois et je reproduis le scénario initial. Je distingue le contournement temporaire de la correction causale, puis je valide le retour arrière sur un appareil pilote avant toute extension.

La chronologie est centrale : je rapproche l’heure du portail, celle du poste, les éventuels décalages UTC et les identifiants présents dans plusieurs journaux. Deux messages identiques peuvent appartenir à des tentatives différentes. Je conserve donc une fenêtre avant et après l’incident et j’indique clairement ce qui est confirmé, probable, encore hypothétique ou impossible à vérifier avec les données disponibles.

• Question à trancher : comprendre l’architecture et ses limites
• Question à trancher : mettre en œuvre un pilote observable
• Question à trancher : construire une exploitation avec critères GO/NO-GO

Cartographie du flux à diagnostiquer

Les anneaux Intune règlent offre et expérience, mais les anciennes valeurs WUServer/WUStatusServer et UseWUServer peuvent diriger le scan vers WSUS. Les scan source policies doivent être interprétées selon la version Windows.

En co-management, le workload Windows Update policies et l’état du client Configuration Manager déterminent qui pilote. Un basculement de workload sans retrait des anciennes policies laisse des traces concurrentes.

Les agents tiers peuvent désactiver des services, inscrire une source ou orchestrer les redémarrages. Je les inventorie via services, tâches, chemins programme et documentation fournisseur.

État initial et prérequis de collecte

Je fige l’état du poste avant toute correction : versions, heure, identité, contexte d’exécution, affectations, autorités de gestion et dernier cycle connu. Cette photographie permet de distinguer la cause initiale des effets produits par les essais suivants.

Je vérifie également que le compte, l’appareil, la licence, la connectivité et les composants nécessaires rendent le scénario réellement applicable. Un prérequis absent doit être traité comme une cause potentielle, pas comme un détail de préparation.

• architecture update cible
• workloads co-management connus
• GPO/WSUS inventoriés
• agents tiers identifiés
• journaux Windows Update et MECM
• poste pilote par population

Collecte des preuves : journaux, registre et états

Le diagnostic de « Troubleshooting de l’autorité Windows Update » relie l’heure de la demande, l’identité, l’objet cloud, le poste et le résultat final. Je conserve les identifiants de corrélation utiles, mais je masque UPN, DeviceId, TenantId, noms internes, secrets, certificats privés et contenus métiers avant tout partage.

Je différencie absence de configuration, non-applicabilité, attente, erreur transitoire, refus d’autorisation et échec du composant local. Ces états n’appellent pas la même correction. Répéter une synchronisation ne transforme pas une politique non applicable en politique valide.

La collecte initiale reste en lecture seule. Une remédiation réelle doit être écrite au minimum au niveau 2, proposer une simulation, borner sa cible et restaurer l’état précédent. Pour une opération tenant-wide, privilégiée ou critique, les niveaux 3 ou 4 et une approbation formelle sont nécessaires.

• Capturer policies CSP et GPO.
• Identifier workload co-management.
• Déterminer la source du dernier scan.
• Corréler contenu et orchestrateur.
• Vérifier services/tâches tiers
• Comparer rapport Intune au client
• Tester retrait d’une autorité sur pilote

Investigation pas à pas

Je suis l’ordre réel du traitement et je m’arrête à la première divergence démontrée. Poursuivre malgré une preuve manquante créerait des symptômes secondaires et rendrait la chronologie moins fiable.

Pour chaque étape, je note l’action, l’emplacement, le résultat attendu et la méthode de vérification. Les champs Impact et Retour arrière concernent l’éventuelle correction ; la phase d’observation reste en lecture seule autant que possible.

Fonctionnement détaillé et frontières de responsabilité

Les anneaux Intune règlent offre et expérience, mais les anciennes valeurs WUServer/WUStatusServer et UseWUServer peuvent diriger le scan vers WSUS. Les scan source policies doivent être interprétées selon la version Windows.

En co-management, le workload Windows Update policies et l’état du client Configuration Manager déterminent qui pilote. Un basculement de workload sans retrait des anciennes policies laisse des traces concurrentes.

Les agents tiers peuvent désactiver des services, inscrire une source ou orchestrer les redémarrages. Je les inventorie via services, tâches, chemins programme et documentation fournisseur.

• architecture update cible
• workloads co-management connus
• GPO/WSUS inventoriés
• agents tiers identifiés

Mise en œuvre, exploitation et cas limites

WindowsUpdateClient/Operational indique les scans, erreurs et contenus. Get-WindowsUpdateLog reconstruit les ETL lorsque le détail est nécessaire ; USOShared décrit l’orchestration.

Le registre PolicyManager matérialise les CSP, mais l’absence d’une valeur ne prouve pas aucune policy. Je complète avec MDM diagnostics, gpresult, RSOP et logs MECM WUAHandler/UpdatesDeployment.

La correction retire une seule autorité concurrente sur pilote, déclenche un nouveau scan et vérifie source, offre et reporting. Le rollback restaure la policy exportée et le workload précédent.

• Vérifier services/tâches tiers
• Comparer rapport Intune au client
• Tester retrait d’une autorité sur pilote

Méthode de validation à l’échelle du parc

Pour troubleshooting de l’autorité windows update, je constitue un échantillon qui couvre au minimum deux modèles matériels, plusieurs profils utilisateur, un site réseau contraint et les exceptions métier connues. Un résultat homogène sur des machines de laboratoire identiques ne démontre pas la robustesse de la configuration.

Je mesure la couverture, le taux de succès, le délai de convergence, le nombre d’exceptions, les incidents et le temps de retour à l’état connu. Les seuils sont définis avant le pilote afin de ne pas les adapter après coup pour justifier une généralisation.

Les cas négatifs font partie de la recette : appareil hors ligne, identité non éligible, permission absente, version non supportée, conflit volontaire et rollback. Le système doit échouer de manière visible et sûre, sans exposer de secret ni créer une dérive silencieuse.

La généralisation suit des anneaux dont la composition reste stable pendant l’observation. Chaque vague dispose d’un propriétaire, d’une fenêtre, d’une consigne support et d’un point d’arrêt. Je n’ouvre la vague suivante qu’après la clôture des écarts de la précédente.

Commandes et scripts de diagnostic en lecture seule

Les commandes de cette section servent à inventorier, corréler ou illustrer. Les scripts de diagnostic sont des exemples non testés de niveau 1 : arrêt sur erreur, gestion globale de l’exception et aucune modification volontaire du poste.

Je vérifie toujours le contexte d’exécution. Une commande lancée dans la session utilisateur n’observe pas forcément les mêmes certificats, variables, chemins ou ruches de registre qu’un processus exécuté sous SYSTEM.

# Exemple pédagogique non testé — niveau 1
$ErrorActionPreference = 'Stop'
try {
 foreach($p in @('HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate','HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\Update')){ if(Test-Path $p){Get-ItemProperty $p} }
 Get-Service wuauserv,bits,usosvc | Select-Object Name,Status,StartType
 Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 120 | Select-Object TimeCreated,Id,Message
}
catch { Write-Error "Collecte Windows Update impossible : $($_.Exception.Message)"; exit 1 }

Arbre de décision : symptômes, causes et corrections

Le symptôme oriente l’enquête, mais ne sélectionne jamais seul une correction. Je n’applique la réponse proposée que lorsque la preuve recherchée confirme la cause et que les autres hypothèses importantes sont écartées.

Après correction, je rejoue exactement le scénario initial avec les mêmes points de mesure. Si le symptôme se déplace vers une autre phase, je poursuis l’analyse au lieu de déclarer l’incident résolu.

Validation de la correction et critères de clôture

Je valide le comportement local, puis la remontée dans le service. Les délais du portail sont pris en compte, mais l’état attendu sur le poste doit être vérifiable immédiatement ou selon le cycle officiellement documenté.

La clôture exige un résultat reproductible, l’absence de régression, une cause documentée et une correction minimale. La généralisation reste NO-GO si le résultat varie entre deux postes comparables ou si le retour arrière n’est pas maîtrisé.

• Capturer policies CSP et GPO.
• Identifier workload co-management.
• Déterminer la source du dernier scan.
• Corréler contenu et orchestrateur.
• Vérifier services/tâches tiers
• Comparer rapport Intune au client
• Tester retrait d’une autorité sur pilote

Retour arrière, escalade et points de vigilance

Le rollback restaure l’état ou l’autorité précédente et doit lui aussi être vérifié sur le poste. Retirer une affectation sans confirmer la convergence locale ne constitue pas un retour arrière terminé.

Si la cause reste indéterminée, je conserve la chronologie, les journaux anonymisés, les identifiants de corrélation et la liste des hypothèses déjà écartées avant l’escalade. Je n’efface jamais les preuves pour tenter une réparation générique.

• Rollback : restaurer export GPO/Intune
• Rollback : revenir au workload précédent
• Rollback : réactiver l’agent tiers uniquement selon runbook
• Vigilance : ne pas vider les caches en première action
• Vigilance : ne pas déduire l’autorité d’une seule clé
• Vigilance : séparer qualité/feature/driver
• Vigilance : conserver heures UTC