Origini di analisi Windows Update: verificare ogni classe prima di chiudere una lacuna WSUS

Cosa indica l’assenza di un marcatore WSUS sulle origini di analisi Windows Update

Le origini di analisi Windows Update determinano dove un client cerca gli aggiornamenti. Un valore WUServer raccolto risponde a una domanda più limitata: l’audit ha trovato una stringa di server WSUS non vuota in una GPO? Questa stringa non consente di stabilire quali classi di aggiornamenti utilizzino il server, se il criterio raggiunga un determinato computer o se la sua ultima analisi sia riuscita.

Iniziate la revisione di un rilievo WSUS dalla strategia di aggiornamento prevista. Un’organizzazione può gestire i client centralmente scegliendo Windows Update come origine. Viceversa, un URL WSUS può esistere in un criterio mentre una popolazione interessata utilizza un’altra origine o non riesce a completare le analisi. Trattate la configurazione dei criteri, le analisi riuscite e la conformità delle patch installate come tre insiemi distinti di evidenze.

Questa procedura riguarda il comportamento dei client Windows 10/11 documentato da Microsoft. Il criterio dell’origine di analisi si applica a Windows 10 versione 2004 e successive, con i prerequisiti di manutenzione documentati, e a Windows 11. Registrate edizione, versione, build e metodo di gestione prima di applicarlo. Non estendete la tabella del comportamento dei client qui sotto a ogni versione di Windows Server; valutate i server in base ai propri criteri supportati e al progetto di distribuzione. Le indicazioni Microsoft sull’origine di analisi definiscono questo ambito client.

Funzionamento: quattro classi di aggiornamenti con impostazioni predefinite diverse

Microsoft consente di selezionare separatamente WSUS o Windows Update per gli aggiornamenti delle funzionalità, della qualità, dei driver e del firmware, e degli altri prodotti Microsoft. Una migrazione può quindi spostare una classe prima delle altre. Un registro di audit richiede un’origine per ogni classe, invece di un’unica etichetta come «gestito nel cloud» o «utilizza WSUS».

La tabella seguente riassume il comportamento di analisi predefinito documentato per i client Windows supportati. Leggetela insieme al risultato effettivo dei criteri su ogni popolazione:

Microsoft identifica anche una trappola di migrazione: Do not allow update deferral policies to cause scans against Windows Update, il precedente criterio di doppia analisi, non è supportato su Windows 11 ed è sostituito dal criterio dell’origine di analisi su Windows 10. Configurarli entrambi su Windows 10 impedisce gli aggiornamenti da Windows Update. Inventariate questo criterio precedente prima di modificare le nuove impostazioni di origine. Queste distinzioni provengono dal riferimento sul comportamento di analisi di Windows Update e WSUS.

La selezione dell’origine è inoltre distinta dalla rendicontazione e dalla distribuzione dei contenuti. Specify intranet Microsoft update service location contiene un campo per il server di rilevamento/download e un campo per il server delle statistiche. Possono puntare allo stesso server, ma hanno scopi diversi. Un server di download alternativo facoltativo cambia la posizione da cui vengono scaricati i file. Non sostituisce la necessità di stabilire l’origine di analisi prevista. Le impostazioni aggiuntive di Windows Update di Microsoft descrivono questi campi e le opzioni di download.

Un endpoint HTTPS richiede una propria convalida del trasporto. Utilizzate i nostri controlli TLS di WSUS e degli URL client per questa revisione. Qui occorre determinare quale origine debba utilizzare ogni classe di aggiornamenti e se il client l’abbia effettivamente analizzata con successo.

Rilevamento: riconciliare i criteri applicati con le evidenze del client

Passaggio 1: identificare le popolazioni e i responsabili dei criteri

Suddividete il parco per build del sistema operativo, metodo di gestione e ambito significativo dei criteri. Includete i client remoti e ogni popolazione che debba mantenere un’origine di aggiornamento locale. Per ciascuna popolazione, chiedete chi sia responsabile degli aggiornamenti delle funzionalità, della qualità, dei driver/firmware e degli altri prodotti; quali classi debbano utilizzare WSUS o Windows Update; e quali vincoli di rete si applichino.

Raccogliete il risultato delle GPO applicate su un computer rappresentativo di ogni ambito, poi estendete la verifica ai computer interessati. Il riferimento Microsoft del comando gpresult documenta l’ambito computer e l’output dettagliato:

gpresult /scope computer /v

Esaminate le impostazioni effettive e le GPO che vi contribuiscono. Un criterio visibile nell’inventario del dominio può non essere pertinente per questo computer. Per i client gestiti tramite MDM o in cogestione, raccogliete anche i criteri di gestione assegnati ed effettivi dal sistema di gestione esistente. Il solo output GPO non consente di stabilire il risultato CSP. Risolvete le divergenze con i responsabili della gestione; non presumete che l’esistenza di un criterio indichi quale autorità prevalga.

Passaggio 2: esaminare WSUS e le impostazioni di origine specifiche per classe

Il criterio di origine è Specify source service for specific classes of Windows Updates, nel percorso:

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

Per i client gestiti tramite CSP, Microsoft elenca quattro criteri:

La guida alla configurazione dell’origine di analisi indica di configurarli tutti e quattro quando si utilizzano i CSP. Il riferimento Update CSP documenta 0 per Windows Update e 1 per WSUS per queste impostazioni di origine. Avverte inoltre che i criteri non hanno effetto se Update/UpdateServiceUrl non è stato configurato correttamente per puntare a WSUS. Verificate applicabilità e prerequisiti prima di interpretare un valore configurato.

Su un computer di destinazione, il comando seguente utilizza la sintassi di reg query documentata da Microsoft per leggere ricorsivamente il ramo dei criteri Windows Update:

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

Il riferimento delle impostazioni Windows Update documenta WUServer e WUStatusServer sotto questo ramo, e UseWUServer sotto la relativa sottochiave AU. Esaminate insieme l’endpoint di aggiornamento configurato, l’endpoint delle statistiche e l’impostazione di utilizzo di WSUS. Sono osservazioni sulla configurazione locale, non risultati di connessione riuscita. L’assenza di output deve essere riconciliata con l’ambito dei criteri e il metodo di gestione.

Microsoft raccomanda di configurare le origini di analisi tramite GPO o CSP anziché con scritture dirette nel registro. Le indicazioni sull’origine di analisi avvertono specificamente che una modifica basata sul registro richiede anche UseUpdateClassPolicySource, altrimenti l’origine non cambia. Utilizzate il processo di gestione dei criteri supportato per le correzioni; non aggiungete una stringa solo per soddisfare un rilevatore.

Passaggio 3: raccogliere un’analisi riuscita e un inventario separato delle patch

Sul client Windows, il riferimento Microsoft di Get-WindowsUpdateLog documenta la conversione delle tracce ETL di Windows Update in un log leggibile:

Get-WindowsUpdateLog

Questo converte le tracce diagnostiche; non avvia un’analisi né certifica l’installazione degli aggiornamenti. Utilizzate la diagnostica client conservata e i registri delle analisi della piattaforma di gestione esistente per indagare sul servizio effettivamente contattato, sul completamento dell’analisi, sui timestamp e sugli errori. Allegate l’identità del dispositivo e la finestra temporale delle evidenze. Se i registri disponibili non consentono di stabilire una classe o un’origine, contrassegnate quella parte della matrice come sconosciuta invece di dedurla da un URL.

Confrontate poi l’inventario degli aggiornamenti installati con la baseline delle patch applicabile all’organizzazione. Registrate separatamente la freschezza dell’inventario, l’applicabilità, i risultati di installazione e il lavoro in sospeso. Un’analisi riuscita può individuare aggiornamenti che restano non installati. Un endpoint delle statistiche valorizzato o un contatto recente con la gestione non può sostituire queste evidenze di installazione.

Correzione: risolvere le divergenze di origine dimostrate (Remediation)

Passaggio 1: costruire la matrice di origini, classi e popolazioni

Create una copia di questo foglio per ogni popolazione. Le celle indicano evidenze da raccogliere, non esempi di risultati di un ambiente:

Mantenete separate l’origine prevista e quella effettiva. Se una popolazione gestita utilizza intenzionalmente Windows Update, documentate la decisione, i criteri che la regolano, il responsabile e le evidenze di analisi/installazione. Installare WSUS per far scomparire un marcatore di audit non risponderebbe a queste domande operative.

Passaggio 2: modificare il criterio responsabile in un ambito pilota

Correggete solo la discrepanza supportata dal foglio. Per i client destinati a utilizzare WSUS, convalidate la configurazione del servizio intranet e le selezioni per classe tramite il processo GPO o CSP responsabile. Per una transizione pianificata con origini miste, impostate ogni classe sulla sua origine approvata e configurate tutte e quattro le impostazioni CSP quando questo è il metodo di distribuzione.

Riconciliate i vecchi controlli di doppia analisi prima del pilota. Esaminate anche Do not connect to any Windows Update Internet locations dove si applica: Microsoft avverte che questa impostazione può impedire il funzionamento dei servizi pubblici, compresi i criteri client Windows Update e Delivery Optimization. Una decisione di origine cloud richiede vincoli di rete e di criteri compatibili. Seguite il comportamento documentato delle impostazioni Windows Update, anziché rimuovere le restrizioni in modo generalizzato senza verificarne lo scopo.

Mantenete il server di rilevamento, la destinazione di rendicontazione e il server di download facoltativo allineati al progetto approvato. Conservate la configurazione precedente per il ripristino e concordate una finestra temporale delle evidenze del pilota con il responsabile degli aggiornamenti. Configuration Manager o altri sistemi di gestione esistenti richiedono una propria revisione della configurazione client; questa procedura non sostituisce quel processo di gestione.

Passaggio 3: ripetere le stesse misurazioni prima di estendere la modifica

Dopo l’applicazione del criterio, ripetete le letture GPO e del registro, raccogliete nuove evidenze MDM dove pertinente e osservate analisi riuscite verso il servizio previsto. Indagate su analisi fallite, origini non previste o evidenze mancanti prima di estendere la modifica. Verificate la conformità delle installazioni in modo indipendente dopo la finestra di distribuzione.

Allegate queste evidenze al processo di audit AD ricorrente e alla cadenza di verifica dopo le modifiche. Ricontrollate la matrice dopo variazioni dell’ambito dei criteri, delle responsabilità di gestione o dell’accesso alla rete. Un revisore successivo dovrebbe poter distinguere l’uso intenzionale di Windows Update da un criterio perso o da una raccolta incompleta.

Come EtcSec rileva questo problema

L’implementazione esaminata di etc-collector per PA038_WSUS_NOT_CONFIGURED analizza le GPOPolicies raccolte. Una stringa WUServer non vuota in qualsiasi GPO imposta il conteggio a 0. Se non ci sono criteri, o se ogni valore disponibile è assente o vuoto, restituisce un rilievo di gravità Low con conteggio 1. Questo conteggio non descrive il numero di client non gestiti o privi di patch.

Il parser di Registry.pol esaminato mappa una stringa non vuota denominata WUServer quando la chiave del registro contiene windowsupdate. La routine di raccolta SMB ignora le letture di file non riuscite in questi punti di chiamata e mantiene comunque l’oggetto del criterio GPO. Un file di criterio mancante o illeggibile può quindi lasciare assenti i dati attesi senza un risultato separato di errore di lettura in questo punto.

Questo controllo non risolve l’applicazione delle GPO per destinazione, i collegamenti, i filtri o la precedenza. Non convalida l’URL o il protocollo, non esamina UseWUServer o WUStatusServer, non raccoglie le impostazioni di origine CSP, non distingue le classi di aggiornamenti, non verifica la connettività, non conferma un’analisi riuscita né inventaria le patch installate. Un marcatore positivo in una GPO non pertinente può soddisfare il controllo lasciando irrisolta la popolazione in esame.

Utilizzate il rilievo per avviare la verifica specifica della popolazione descritta sopra. Conservate le decisioni intenzionali di origine cloud e gli elementi sconosciuti della raccolta nel registro di audit. Risolvete il problema operativo solo quando l’origine prevista, i criteri client effettivi, le analisi riuscite e l’inventario separato delle installazioni sono stati riconciliati.