Su alcuni server Windows Server 2016 l’aggiornamento del Servicing Stack di giugno 2024 (KB5039334) può apparire e installarsi anche con gli Aggiornamenti automatici disattivati. In questa guida spiego perché accade, come verificarlo nei log e come governare gli SSU senza sorprese.
Panoramica del caso reale
Un amministratore ha riscontrato l’installazione “spontanea” del pacchetto di manutenzione KB5039334 su più istanze di Windows Server 2016, nonostante criteri aziendali con download/installa manuale e flussi di patching guidati da WSUS/SCCM. La domanda chiave era se si trattasse di un comportamento forzato da Microsoft e da cosa dipendesse.
Il punto è che stiamo parlando di un Servicing Stack Update (SSU): un aggiornamento del motore che applica tutti gli altri aggiornamenti. Gli SSU hanno una priorità speciale e seguono regole di distribuzione differenti dai classici “Cumulative/Quality Update”.
Che cosa sono gli SSU e perché hanno priorità
Gli SSU aggiornano il servicing stack, cioè il componente del sistema (incluso il CBS – Component Based Servicing) che installa gli update, gestisce DISM/SFC e abilita la riparazione dei componenti. Senza un servicing stack integro, il sistema può non riuscire a ricevere le future patch di sicurezza.
Questo spiega due conseguenze operative fondamentali:
- Pre‑requisito di installazione: gli SSU devono essere presenti prima di qualsiasi Cumulative/Monthly Rollup/Quality Update. In genere, quando manca l’SSU richiesto, il sistema o WSUS non offrono l’LCU fino a quando l’SSU non è stato applicato.
- Non disinstallabilità: per loro natura modificano il motore di aggiornamento; una volta applicati, non sono rimovibili. Il sistema conserva la coerenza del motore per garantire aggiornamenti futuri.
Perché l’installazione avviene senza intervento
Per il caso specifico di Windows Server 2016, l’SSU di giugno 2024 (identificato come KB5039334) è classificato tra gli aggiornamenti di sicurezza/importanti e sostituisce l’SSU precedente della stessa famiglia. Quando il canale attivo è Windows Update, la pagina ufficiale del pacchetto indica espressamente che l’aggiornamento viene scaricato e installato automaticamente. Questo comportamento è intenzionale, perché l’SSU tutela la capacità del sistema di patcharsi in seguito.
In rari scenari, la logica del client Windows Update può dare priorità all’SSU per preservare l’integrità del motore, anche quando il flusso normale prevede l’installazione manuale. Inoltre, alcune azioni amministrative possono aprire una finestra di opportunità per il download di update critici: ad esempio un GPUPDATE /FORCE reimposta e riapplica temporaneamente i criteri, e nel breve intervallo i valori di default permettono al client di contattare il servizio e prendere elementi marcati come essenziali.
Comportamento su WSUS e Configuration Manager
Quando la distribuzione è governata da WSUS/SCCM, la dinamica cambia:
- Classificazione: KB5039334 è sincronizzato nella categoria Security Updates. Ciò significa che, se si usa WSUS, l’SSU appare nel catalogo ed è idoneo alla distribuzione; non viene però installato finché non viene approvato (salvo che i client riescano a raggiungere Windows Update pubblico per altre ragioni di rete o policy).
- Nessuna interruzione: gli SSU tipicamente non richiedono riavvii e hanno dimensioni ridotte (ordine di decine di MB). Questo li rende ideali per approvazioni “a basso impatto” nei periodi di manutenzione.
- Co‑impacchettamento su piattaforme più recenti: da Windows 10 2004/20H2 e Windows Server più moderni, Microsoft ha introdotto il pacchetto combinato SSU+LCU. Per Windows Server 2016, ambiente legacy, l’SSU resta un pacchetto autonomo, quindi può seguire la logica di priorità sopra descritta.
Impossibilità di rimozione e impatto sul riavvio
Gli SSU non sono disinstallabili. Questo non è un bug ma una misura di sicurezza: una volta aggiornato con successo, il motore di manutenzione non può tornare a uno stato più vecchio senza compromettere la pipeline di patching.
Dal punto di vista della continuità operativa, gli SSU in genere non richiedono riavvio. In uno scenario standard di produzione non causano downtime del servizio applicativo.
Come dimostrare da dove è arrivata l’installazione
Per rispondere a un audit interno o ricostruire la catena degli eventi, conviene seguire un percorso di verifica ripetibile. Di seguito una traccia concreta, basata su log di sistema e strumenti integrati.
Event Viewer e cronologia
- System → WindowsUpdateClient: cerca l’Event ID 19 (installazione riuscita), Event ID 20 (installazione fallita) e Event ID 22 (riavvio richiesto). Nel dettaglio dell’evento compare il nome dell’aggiornamento con il relativo KB.
- Applications and Services Logs → Microsoft → Windows → WindowsUpdateClient → Operational: vista più granulare, utile per correlare l’avvio dell’installazione con la sorgente (WSUS/MU) e l’ora.
- System → User32, Service Control Manager: eventi 1074/1076, 7035/7036 aiutano a ricostruire eventuali riavvii o start/stop dei servizi di Windows Update.
WindowsUpdate.log e CBS.log
Dalla versione 1607 in poi, WindowsUpdate.log è generato su richiesta:
PowerShell
Esegui come amministratore
Get-WindowsUpdateLog -LogPath C:\Temp\WindowsUpdate.log
Per il motore di manutenzione, il riferimento è C:\Windows\Logs\CBS\CBS.log. In questo file è possibile cercare il nome del pacchetto (per esempio “KB5039334”) e i relativi codici di stato del CBS.
Tabella rapida di analisi
| Log | Percorso | Cosa cercare | Esempio pratico |
|---|---|---|---|
| Event Viewer | System → Microsoft‑Windows‑WindowsUpdateClient | ID 19/20/22, dettagli KB e origine | “Installation Successful: Security Update for Windows (KB5039334)” |
| Operational | Applications and Services Logs → Microsoft → Windows → WindowsUpdateClient → Operational | Fasi di download/installazione, sorgente WSUS/MU | “Start installing update KB5039334 from WU” |
| WindowsUpdate.log | Generato con Get-WindowsUpdateLog | Codici WU, endpoint contattati, enforcement | “AU: Found 1 updates and 1 are applicable” |
| CBS.log | C:\Windows\Logs\CBS\CBS.log | Transazioni CBS, esito dei pacchetti | “Package KB5039334: State: Installed” |
Strategie per evitare installazioni non pianificate
Se l’obiettivo è impedire che il sistema prenda iniziative non previste, bisogna agire a più livelli. Qui una checklist operativa ragionata: scegli i blocchi in base alla tua tolleranza al rischio e ai requisiti di compliance.
Impostazioni di criteri
- Configurare la posizione dell’aggiornamento intranet: abilita Specify intranet Microsoft update service location e punta a WSUS. Questo riduce drasticamente la probabilità che i client escano su Internet per aggiornarsi.
- Impedire connessioni ai servizi pubblici: abilita Do not connect to any Windows Update Internet locations per rimuovere anche il pulsante “Controlla online” e costringere il client a restare nel perimetro WSUS/SCCM.
- Gestire l’automazione: imposta Configure Automatic Updates su Disabled (o su una modalità di notifica compatibile con la tua finestra di manutenzione).
- Evitare finestre transitorie: nei playbook di automazione evita di lanciare
GPUPDATE /FORCEsu server sensibili durante orari di produzione; l’intervallo di ricalcolo dei criteri può esporre a controlli immediati della disponibilità aggiornamenti.
Controllo del servizio
- Windows Update service (
wuauserv): se serve un freeze totale, imposta l’avvio su Disabled e arresta il servizio. Ricorda che questo blocca anche l’accesso alle future patch finché non lo riabiliti. - Servizi correlati (BITS, CryptSvc): spesso non è necessario toccarli per gli SSU; evita cambi non indispensabili per non introdurre effetti collaterali.
Governance via WSUS/SCCM
- Anello dedicato agli SSU: crea una regola o un gruppo di approvazione che tratti gli SSU separatamente, con un ciclo rapido e senza riavvio.
- Manutenzione ordinata: approva l’SSU poche ore (o giorni) prima della finestra LCU. Così hai la certezza che il motore sia pronto senza impatti sul servizio.
- Connettività: assicurati che i server non possano raggiungere gli endpoint pubblici di Windows Update se l’unica sorgente autorizzata è WSUS/SCCM. Applica filtri di egress sul proxy/firewall coerenti con la tua policy.
Monitoraggio e allarmi
- Metti sotto sorveglianza gli Event ID 19/20/22 e le stringhe “Servicing Stack Update” nei log.
- Genera un WindowsUpdate.log in caso di comportamento sospetto e archivialo per audit.
- Scrivi regole SIEM per correlare “installazione SSU” e “modifica criteri/riavvio servizi” nella stessa finestra temporale.
Comandi pronti all’uso
Verifica se l’SSU è presente tramite DISM o PowerShell:
cmd
DISM /Online /Get-Packages | findstr 5039334
PowerShell
Get-WindowsPackage -Online | Where-Object PackageName -match '5039334' |
Select-Object PackageName, ReleaseType, InstallTime
Estrai rapidamente gli ultimi eventi di aggiornamento:
PowerShell
Get-WinEvent -FilterHashtable @{
LogName = 'System'
ProviderName = 'Microsoft-Windows-WindowsUpdateClient'
Id = 19,20,22
} -MaxEvents 200 |
Select-Object TimeCreated, Id, LevelDisplayName, Message
Controlla l’effettiva applicazione dei criteri lato client:
cmd
gpresult /h C:\Temp\gpresult-wu.html && start C:\Temp\gpresult-wu.html
Domande frequenti
È “normale” che l’SSU si installi da solo?
Sì, quando il canale è Windows Update la documentazione del pacchetto dichiara che l’aggiornamento viene scaricato e installato automaticamente. Su WSUS/SCCM, invece, resta sotto approvazione amministrativa, a meno di configurazioni di rete/policy che consentano l’accesso a Internet.
Perché proprio questo pacchetto?
Gli SSU correggono il motore di aggiornamento; per questo Microsoft li tratta come prerequisiti di sicurezza con priorità massima. Nel caso di giugno 2024 sostituisce un SSU precedente, consentendo l’installazione delle cumulative successive.
Posso disinstallarlo?
No: gli SSU non sono disinstallabili. Per tornare indietro servirebbe ripristinare l’immagine o una snapshot del sistema, pratica non raccomandata salvo test di laboratorio.
Serve il riavvio?
Nella maggior parte dei casi no. Tuttavia, se stai installando altre patch in coda, l’LCU potrebbe richiedere un riavvio: non confondere l’effetto dell’LCU con quello dell’SSU.
Perché ho visto l’installazione dopo un aggiornamento dei criteri?
Durante GPUPDATE /FORCE i criteri vengono ricalcolati; nell’intervallo transitorio i valori di default possono permettere al client di controllare Windows Update, catturando gli SSU critici disponibili.
Questa dinamica riguarda anche piattaforme più nuove?
Sulle versioni più recenti molte release combinano SSU e LCU in un unico pacchetto, riducendo la necessità di gestire l’SSU come elemento separato. Su Windows Server 2016, invece, l’SSU resta autonomo e va previsto nel processo.
Playbook operativo
- Fotografa lo stato: esegui i comandi di verifica pacchetti e la raccolta dei log.
- Controlla WSUS/SCCM: verifica se l’SSU è stato sincronizzato e approvato; confronta l’orario di installazione con quello di eventuali anelli di distribuzione.
- Revisione GPO: conferma Do not connect to any Windows Update Internet locations, Configure Automatic Updates, e la posizione WSUS.
- Rete: verifica che i server non abbiano egress aperti verso servizi pubblici di Windows Update quando ciò non è previsto.
- Stagionatura SSU: definisci un anello “SSU” veloce e continuo, separato dagli LCU, per anticipare di qualche giorno la finestra di patching.
Rischi del blocco totale del motore di aggiornamento
Disattivare servizi o impedire ogni accesso a Windows Update può sembrare la soluzione più sicura, ma introduce rischi reali: perdita di idoneità a ricevere patch, accumulo di gap di sicurezza e possibili errori futuri nella pipeline di aggiornamento. Se scegli il blocco totale, documenta bene chi riabilita e quando, e pianifica una finestra per riallineare SSU e cumulative nel più breve tempo possibile.
Conclusioni
L’installazione automatica di KB5039334 su Windows Server 2016 è un comportamento atteso nel momento in cui il dispositivo può utilizzare Windows Update: un SSU è critico per la stabilità del meccanismo di patching, perciò Microsoft ne facilita la distribuzione. In infrastrutture governate da WSUS/SCCM, l’SSU resta sotto il tuo controllo: organizzalo in un anello dedicato, approvalo in anticipo rispetto alla finestra LCU e monitora i log per assicurarti che la catena resti coerente. Se invece serve un controllo assoluto, blocca a livello di policy, servizio e rete, consapevole che così facendo rinvii la capacità di ricevere gli aggiornamenti di sicurezza successivi.
Riferimenti pratici senza link
- Nota ufficiale del pacchetto SSU: disponibile tramite la pagina di supporto del KB.
- FAQ sugli SSU: linee guida generali su priorità, prerequisiti e non disinstallabilità.
- Articolo su comportamenti durante il ricalcolo dei criteri e possibili installazioni inattese in seguito a
GPUPDATE /FORCE. - Documentazione su log di Windows Update e uso di
Get-WindowsUpdateLog, oltre ai dettagli suCBS.log. - Nota sul co‑impacchettamento SSU+LCU introdotto nelle versioni più recenti di Windows/Windows Server.
Suggerimento finale: crea un cruscotto che mostri “stato SSU” per ogni server. Basta un report SCCM/WSUS o uno script che interroga Get-WindowsPackage e invia i risultati a un datastore centrale. Se il cruscotto diventa rosso, hai una settimana per rimettere in pari il motore prima della successiva cumulative: niente sorprese, niente corse.