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.

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.

• Windows Update, WUfB, WSUS
• Under the Hood — Policy, Scan, Content, Orchestrator
• architecture update cible, workloads co-management connus, GPO/WSUS inventoriés

Questions à résoudre et méthode de diagnostic

Pour Troubleshooting de l’autorité Windows Update, l’enquête suit le parcours Policy → Scan → Content → Orchestrator. L’étape utile n’est pas celle qui affiche le dernier message: c’est la première dont le résultat ne correspond plus au fonctionnement attendu.

Les premiers contrôles portent sur Capturer policies CSP et GPO, Identifier workload co-management et Déterminer la source du dernier scan. Ils permettent de dater le problème et de séparer un défaut de ciblage, de transport ou d’exécution avant d’envisager une correction.

Les symptômes « Intune policy verte, aucune offre, Drivers jamais proposés et Dual scan inattendu » peuvent se ressembler à l’écran tout en provenant de causes différentes. Chaque branche de diagnostic associe donc un signal, une preuve et une action de correction précise.

• Capturer policies CSP et GPO.
• Identifier workload co-management.
• Déterminer la source du dernier scan.

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

L’état initial de Troubleshooting de l’autorité Windows Update doit couvrir architecture update cible, workloads co-management connus, GPO/WSUS inventoriés, agents tiers identifiés. Cette photographie est prise avant de relancer un traitement ou de modifier une affectation.

Les couches Policy, Scan, Content, Orchestrator sont contrôlées séparément. Un prérequis absent devient alors une cause identifiable, au lieu d’être noyé dans les effets des essais suivants.

• 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

La chronologie de Troubleshooting de l’autorité Windows Update relie Policy, Scan, Content, Orchestrator. Les heures et identifiants communs indiquent si les informations décrivent la même tentative.

Les états sont lus à partir de Capturer policies CSP et GPO. Identifier workload co-management. Déterminer la source du dernier scan. Corréler contenu et orchestrateur. Cette séquence sépare une absence de configuration d’un traitement en attente ou d’un échec confirmé.

Les causes « Scan WSUS persistant », « ExcludeWUDrivers ou policy dédiée », « Anciennes policies », « Workload/client » restent des hypothèses jusqu’à ce que la preuve indiquée dans la matrice les confirme.

• 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

L’investigation suit l’ordre Policy → Scan → Content → Orchestrator. La première divergence confirmée détermine la branche suivante et évite de multiplier les symptômes secondaires.

Pour Troubleshooting de l’autorité Windows Update, les contrôles « Reproduire le symptôme », « Contrôler le ciblage », « Corréler les états » précisent à la fois l’emplacement, le résultat attendu et la vérification à effectuer.

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.

Les mesures portent sur Capturer policies CSP et GPO. Identifier workload co-management. Déterminer la source du dernier scan. Corréler contenu et orchestrateur. Elles sont définies avant le pilote de Troubleshooting de l’autorité Windows Update afin que les seuils ne soient pas déplacés après l’observation.

Les cas « Intune policy verte, aucune offre », « Drivers jamais proposés », « Dual scan inattendu », « MECM continue updates » servent de scénarios négatifs. Ils vérifient que l’échec reste visible, localisable et associé à une correction précise.

La généralisation de Troubleshooting de l’autorité Windows Update tient compte de ne pas vider les caches en première action, ne pas déduire l’autorité d’une seule clé, séparer qualité/feature/driver, conserver heures UTC. Chaque vague se ferme après lecture de ces points et validation du retour à l’état connu.

Commandes et scripts de diagnostic en lecture seule

Les exemples ci-dessous contrôlent Capturer policies CSP et GPO. Identifier workload co-management. Déterminer la source du dernier scan. Corréler contenu et orchestrateur. Leur sortie doit être rapprochée de l’heure de l’incident et du contexte d’exécution concerné.

Pour Troubleshooting de l’autorité Windows Update, les données utiles se lisent dans les états locaux, les journaux et les rapports cités dans chaque exemple. Une valeur isolée ne remplace pas cette corrélation.

# Collecte de diagnostic
$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 }

$ErrorActionPreference = 'Stop'
try {
  $paths = @(
    'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate',
    'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\Update'
  )
  foreach ($path in $paths) {
    if (Test-Path -LiteralPath $path) { Get-ItemProperty -LiteralPath $path }
  }
  Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 120 |
    Select-Object TimeCreated,Id,LevelDisplayName,Message
}
catch {
  Write-Error "Collecte impossible : $($_.Exception.Message)"
  exit 1
}

[06:00:00.118] Policy   WUServer=<WSUS-URL> DisableDualScan=<VALUE>
[06:00:01.008] MECM     WUAHandler Source=WSUS Assignment=<ID>
[06:00:02.884] WUClient ScanService=<SERVICE-ID> Started
[06:00:18.552] WUClient Result=<HRESULT> UpdatesFound=0
[06:00:20.010] Intune   UpdateRing=<POLICY> PerSetting=<STATE>

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

La matrice couvre notamment Intune policy verte, aucune offre, Drivers jamais proposés, Dual scan inattendu, MECM continue updates. Ces symptômes servent de points d’entrée; la preuve indiquée dans la même ligne confirme ou écarte la cause.

Après correction, les contrôles Capturer policies CSP et GPO, Identifier workload co-management et Déterminer la source du dernier scan sont rejoués dans les mêmes conditions pour vérifier que le problème n’a pas simplement changé de phase.

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

La correction de Troubleshooting de l’autorité Windows Update est validée avec les mêmes points de mesure que le diagnostic initial. Le résultat local et l’état remonté dans le service doivent raconter la même chronologie.

• 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 retour arrière de Troubleshooting de l’autorité Windows Update restaure l’état connu décrit ci-dessous. Sa réussite se vérifie sur le poste et dans le service, pas seulement par la disparition d’une affectation.

Une escalade conserve les preuves correspondant à Capturer policies CSP et GPO. Identifier workload co-management. Déterminer la source du dernier scan. Corréler contenu et orchestrateur. ainsi que les causes déjà écartées.