Sources de recherche Windows Update : vérifier chaque classe avant de clore un écart WSUS

Ce que l’absence de marqueur WSUS révèle sur les sources de recherche Windows Update

Les sources de recherche Windows Update déterminent où un client recherche ses mises à jour. Une valeur WUServer collectée répond à une question plus étroite : l’audit a-t-il trouvé une chaîne de serveur WSUS non vide dans une GPO ? Cette chaîne ne permet pas d’établir quelles classes de mises à jour utilisent ce serveur, si la stratégie atteint un ordinateur donné, ni si sa dernière recherche a réussi.

Commencez l’examen d’un constat WSUS par la stratégie de mise à jour prévue. Une organisation peut gérer ses clients de manière centralisée tout en choisissant Windows Update comme source. À l’inverse, une URL WSUS peut exister dans une stratégie alors qu’une population concernée utilise une autre source ou ne parvient pas à terminer ses recherches. Traitez la configuration des stratégies, les recherches réussies et la conformité des correctifs installés comme trois ensembles de preuves distincts.

Cette procédure couvre le comportement des clients Windows 10/11 documenté par Microsoft. La stratégie de source de recherche s’applique à Windows 10 version 2004 et ultérieures, avec les prérequis de maintenance documentés, ainsi qu’à Windows 11. Consignez l’édition, la version, la build et le mode de gestion avant de l’appliquer. N’étendez pas le tableau de comportement des clients ci-dessous à toutes les versions de Windows Server ; évaluez les serveurs selon leurs propres stratégies prises en charge et leur conception de déploiement. Les consignes Microsoft sur les sources de recherche définissent ce périmètre client.

Fonctionnement : quatre classes de mises à jour avec des valeurs par défaut différentes

Microsoft permet de choisir séparément entre WSUS et Windows Update pour les mises à jour de fonctionnalités, de qualité, de pilotes et de microprogrammes, ainsi que pour les mises à jour des autres produits Microsoft. Une migration peut donc déplacer une classe avant les autres. Un dossier d’audit doit indiquer une source pour chaque classe, plutôt qu’une simple étiquette comme « géré dans le cloud » ou « utilise WSUS ».

Le tableau suivant résume le comportement de recherche par défaut documenté pour les clients Windows pris en charge. Lisez-le en parallèle du résultat réel des stratégies sur chaque population :

Microsoft signale aussi un piège de migration : Do not allow update deferral policies to cause scans against Windows Update, l’ancienne stratégie de double recherche, n’est pas prise en charge sur Windows 11 et est remplacée par la stratégie de source de recherche sur Windows 10. Configurer les deux sur Windows 10 empêche les mises à jour depuis Windows Update. Inventoriez cette stratégie héritée avant de modifier les nouveaux paramètres de source. Ces distinctions proviennent de la référence sur le comportement de recherche de Windows Update et WSUS.

Le choix de la source est également distinct de la remontée d’informations et de la livraison du contenu. Specify intranet Microsoft update service location comporte un champ de serveur de détection/téléchargement et un champ de serveur de statistiques. Ils peuvent pointer vers le même serveur, mais remplissent des fonctions différentes. Un serveur de téléchargement alternatif facultatif modifie l’emplacement de téléchargement des fichiers. Il ne remplace pas la nécessité d’établir la source de recherche prévue. Les paramètres supplémentaires de Windows Update de Microsoft décrivent ces champs et ces options de téléchargement.

Un point de terminaison HTTPS nécessite sa propre validation du transport. Utilisez nos contrôles TLS WSUS et des URL clientes pour cet examen. Ici, il s’agit de déterminer quelle source chaque classe de mises à jour doit utiliser et si le client y a effectivement effectué une recherche réussie.

Détection : rapprocher les stratégies appliquées des preuves clientes

Étape 1 : identifier les populations et les responsables des stratégies

Segmentez le parc par build du système d’exploitation, mode de gestion et périmètre de stratégie pertinent. Incluez les clients distants et toute population devant conserver une source de mise à jour sur site. Pour chaque population, demandez qui est responsable des mises à jour de fonctionnalités, de qualité, de pilotes/microprogrammes et des autres produits ; quelles classes doivent utiliser WSUS ou Windows Update ; et quelles contraintes réseau s’appliquent.

Collectez le résultat des GPO appliquées sur une cible représentative de chaque périmètre, puis étendez la vérification aux ordinateurs concernés. La référence Microsoft de la commande gpresult documente le périmètre ordinateur et la sortie détaillée :

gpresult /scope computer /v

Examinez les paramètres réels et les GPO qui y contribuent. Une stratégie visible dans l’inventaire du domaine peut ne pas concerner cet ordinateur. Pour les clients gérés par MDM ou en cogestion, collectez également les stratégies de gestion affectées et effectives depuis le système de gestion existant. La sortie GPO seule ne permet pas d’établir le résultat CSP. Résolvez les divergences avec les responsables de gestion concernés ; ne supposez pas que l’existence d’une stratégie indique quelle autorité l’emporte.

Étape 2 : examiner les paramètres WSUS et les sources propres à chaque classe

La stratégie de source est Specify source service for specific classes of Windows Updates, située sous :

Computer Configuration > Administrative Templates > Windows Components > Windows Update > Manage updates offered from Windows Server Update Service.

Pour les clients gérés par CSP, Microsoft répertorie quatre stratégies :

Le guide de configuration des sources de recherche demande de configurer les quatre lors de l’utilisation des CSP. La référence du CSP Update documente 0 pour Windows Update et 1 pour WSUS dans ces paramètres de source. Elle avertit également que les stratégies sont sans effet si Update/UpdateServiceUrl n’a pas été correctement configuré pour pointer vers WSUS. Vérifiez l’applicabilité et les prérequis avant d’interpréter une valeur configurée.

Sur une cible, la commande suivante utilise la syntaxe reg query documentée par Microsoft pour lire récursivement la branche de stratégie Windows Update :

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /s

La référence des paramètres Windows Update documente WUServer et WUStatusServer sous cette branche, ainsi que UseWUServer sous sa sous-clé AU. Examinez ensemble le point de terminaison de mise à jour configuré, celui des statistiques et le paramètre d’utilisation de WSUS. Il s’agit d’observations de configuration locale, pas de résultats de connexion réussie. Toute absence de sortie doit être rapprochée du périmètre des stratégies et du mode de gestion.

Microsoft recommande de configurer les sources de recherche par GPO ou CSP plutôt que par écriture directe dans le registre. Ses consignes précisent qu’une modification par le registre nécessite également UseUpdateClassPolicySource, faute de quoi la source ne change pas. Utilisez le processus de stratégie pris en charge pour les corrections ; n’ajoutez pas une chaîne simplement pour satisfaire un détecteur.

Étape 3 : collecter une recherche réussie et un inventaire distinct des correctifs

Sur le client Windows, la référence Microsoft de Get-WindowsUpdateLog documente la conversion des traces ETL Windows Update en journal lisible :

Get-WindowsUpdateLog

Cette commande convertit les traces de diagnostic ; elle ne lance pas de recherche et ne certifie pas l’installation des mises à jour. Utilisez les diagnostics clients conservés et les enregistrements de recherche de la plateforme de gestion existante pour examiner le service réellement contacté, la fin de la recherche, les horodatages et les échecs. Joignez l’identité de l’appareil et la fenêtre de collecte des preuves. Si les enregistrements disponibles ne permettent pas d’établir une classe ou une source, marquez cette partie de la matrice comme inconnue au lieu de la déduire d’une URL.

Comparez ensuite l’inventaire des mises à jour installées au référentiel de correctifs applicable de l’organisation. Consignez séparément la fraîcheur de l’inventaire, l’applicabilité, les résultats d’installation et les travaux en attente. Une recherche réussie peut découvrir des mises à jour qui restent non installées. Un point de terminaison de statistiques renseigné ou un contact récent avec la gestion ne remplace pas ces preuves d’installation.

Remédiation : corriger les divergences de source démontrées (Remediation)

Étape 1 : construire la matrice des sources, classes et populations

Créez une copie de cette fiche pour chaque population. Les cellules indiquent les preuves à collecter, pas des exemples de résultats obtenus dans un environnement :

Gardez la source prévue et la source effective distinctes. Si une population gérée utilise intentionnellement Windows Update, documentez cette décision, les stratégies qui la régissent, le responsable et les preuves de recherche/d’installation. Installer WSUS pour faire disparaître un marqueur d’audit ne répondrait pas à ces questions opérationnelles.

Étape 2 : modifier la stratégie responsable dans un périmètre pilote

Corrigez uniquement l’écart étayé par la fiche. Pour les clients censés utiliser WSUS, validez la configuration du service intranet et les choix par classe à travers le processus GPO ou CSP responsable. Pour une transition planifiée vers des sources mixtes, affectez à chaque classe sa source approuvée et configurez les quatre paramètres CSP lorsque ce mode de déploiement est utilisé.

Rapprochez les anciens contrôles de double recherche avant le pilote. Examinez aussi Do not connect to any Windows Update Internet locations là où cette stratégie s’applique : Microsoft avertit que ce paramètre peut empêcher les services publics, notamment les stratégies clientes Windows Update et Delivery Optimization, de fonctionner. Le choix d’une source cloud nécessite des contraintes réseau et de stratégie compatibles. Suivez le comportement documenté des paramètres Windows Update, plutôt que de supprimer largement les restrictions sans vérifier leur objectif.

Gardez le serveur de détection, la destination de remontée des informations et le serveur de téléchargement facultatif alignés sur la conception approuvée. Conservez la configuration antérieure pour le retour arrière et convenez d’une fenêtre de collecte des preuves du pilote avec le responsable des mises à jour. Configuration Manager ou toute autre gestion existante exige son propre examen de configuration cliente ; cette procédure ne remplace pas ce processus de gestion.

Étape 3 : répéter les mêmes mesures avant d’étendre le changement

Après l’application de la stratégie, relancez les lectures GPO et du registre, collectez des preuves MDM fraîches lorsque c’est pertinent et observez des recherches réussies auprès du service prévu. Examinez les recherches en échec, les sources non prévues et les preuves manquantes avant d’étendre le changement. Contrôlez séparément la conformité des installations après la fenêtre de déploiement.

Joignez ces preuves au processus d’audit AD récurrent et au rythme de vérification après changement. Revérifiez la matrice après toute modification du périmètre des stratégies, des responsabilités de gestion ou de l’accès réseau. Un examinateur ultérieur doit pouvoir distinguer une utilisation intentionnelle de Windows Update d’une stratégie perdue ou d’une collecte incomplète.

Comment EtcSec détecte ce problème

L’implémentation examinée d’etc-collector pour PA038_WSUS_NOT_CONFIGURED analyse les GPOPolicies collectées. Une chaîne WUServer non vide dans n’importe quelle GPO fixe le compteur à 0. En l’absence de stratégies, ou si toutes les valeurs disponibles sont absentes ou vides, elle renvoie un constat de sévérité Low avec un compteur à 1. Ce compteur ne décrit pas le nombre de clients non gérés ou non corrigés.

Le parseur Registry.pol examiné mappe une chaîne non vide nommée WUServer lorsque la clé de registre contient windowsupdate. La routine de collecte SMB ignore les lectures de fichiers infructueuses à ces points d’appel tout en conservant l’objet de stratégie GPO. Un fichier de stratégie absent ou illisible peut donc laisser les données attendues absentes sans résultat distinct d’erreur de lecture à cet endroit.

Ce contrôle ne résout pas l’application des GPO par cible, les liens, le filtrage ni la priorité. Il ne valide pas l’URL ou le protocole, n’examine pas UseWUServer ou WUStatusServer, ne collecte pas les paramètres de source CSP, ne distingue pas les classes de mises à jour, ne teste pas la connectivité, ne confirme pas une recherche réussie et n’inventorie pas les correctifs installés. Un marqueur positif dans une GPO sans rapport peut satisfaire le contrôle tout en laissant la population examinée sans conclusion.

Utilisez le constat pour ouvrir la vérification propre à chaque population décrite ci-dessus. Conservez les décisions intentionnelles de source cloud et les inconnues de collecte dans le dossier d’audit. Ne résolvez le problème opérationnel qu’après rapprochement de la source prévue, des stratégies clientes effectives, des recherches réussies et de l’inventaire distinct des installations.