Microsoft AZ-801: Aggiornamento e Gestione delle Patch di Windows Server — Guida allo studio

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Fa parte della Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La gestione delle patch in Windows Server copre i carichi di lavoro on-premise e quelli ospitati su Azure, combinando WSUS per flussi di lavoro di approvazione granulari, le policy di Windows Update for Business (WUfB) per implementazioni basate su anelli (ring), l’orchestrazione basata su Azure per la scalabilità e una solida reportistica di conformità. Una strategia di successo standardizza le origini di scansione, isola gli anelli di test e pilota, controlla i riavvii all’interno delle finestre di manutenzione e pulisce continuamente i metadati per mantenere le prestazioni prevedibili. Gli amministratori ibridi devono anche comprendere le moderne funzionalità di Azure come Update Management Center, l’applicazione automatica di patch per le VM guest e l’hotpatching per Windows Server Azure Edition per ridurre al minimo i tempi di inattività mantenendo al contempo la postura di sicurezza.

Architettura e Amministrazione di WSUS

Una topologia WSUS ben progettata parte da un server upstream che sincronizza i metadati (e facoltativamente i contenuti) da Microsoft Update. I server downstream si sottoscrivono a quel server upstream. In modalità replica, un server downstream eredita approvazioni, gruppi di computer e impostazioni dall’upstream per un controllo centralizzato, ideale per le filiali. In modalità autonoma, i server downstream ricevono i metadati degli aggiornamenti ma prendono le proprie decisioni di approvazione, utile quando i team regionali controllano la manutenzione. La sincronizzazione dovrebbe essere pianificata giornalmente per i metadati con lingue, prodotti e classificazioni selezionati. Per implementazioni di grandi dimensioni, configurare SSL (porta 8531) per proteggere il traffico di scansione dei client e la replica tra server WSUS.

Le regole di approvazione rendono operativi gli anelli (ring). Le regole di approvazione automatica possono approvare immediatamente gli Aggiornamenti di Sicurezza (e facoltativamente gli Aggiornamenti Critici) per un gruppo di pre-produzione, mentre altri anelli vengono ritardati di giorni o settimane. Utilizzare approvazioni esplicite con scadenze (deadline) per le implementazioni su larga scala; le scadenze forzano l’installazione entro un tempo specificato, indipendentemente dalle “ore di attività” del client. I gruppi di computer definiscono gli anelli e i livelli dei carichi di lavoro (server Pilota, Generali e Critici). L’assegnazione ai gruppi può essere lato server o lato client. Con il targeting lato server, i nuovi client compaiono in Unassigned Computers e gli amministratori li spostano nei gruppi WSUS. Con il targeting lato client, una Group Policy imposta TargetGroup e TargetGroupEnabled in modo che le macchine si auto-registrìno in un gruppo WSUS nominato alla prima scansione, una soluzione migliore per il posizionamento su larga scala e dinamico basato su OU.

Le GPO client devono indirizzare l’Agente di Windows Update a WSUS abilitando l’impostazione Specify intranet Microsoft update service location (sia per il servizio di aggiornamento che per il server delle statistiche). Impostare Configure Automatic Updates (ad es. opzione 4, download automatico e installazione pianificata) e Automatic Updates detection frequency per controllare la cadenza delle scansioni. Per i server, impostare No auto-restart with logged on users e Turn off auto-restart for updates during active hours per evitare riavvii inopportuni; quindi, coordinare il comportamento di riavvio utilizzando finestre di manutenzione o strumenti di orchestrazione. Se nell’ambiente esistono policy di WUfB, impedire ai client di bypassare WSUS abilitando l’impostazione Do not allow update deferral policies to cause scans against Windows Update.

Prestazioni sostenute richiedono una corretta igiene di WSUS. La Pulizia Guidata di WSUS (WSUS Cleanup Wizard) rimuove gli aggiornamenti sostituiti e scaduti, elimina i file di aggiornamento obsoleti e rimuove i computer inattivi che non hanno contattato WSUS entro un intervallo di tempo prestabilito. Automatizzare la pulizia con uno script tramite Invoke-WsusServerCleanup ed eseguirlo dopo le sincronizzazioni che importano grandi lotti di aggiornamenti.

La manutenzione del database di WSUS non è facoltativa per garantire scalabilità e stabilità. Gli aggiornamenti scaduti dovrebbero essere rifiutati; gli aggiornamenti sostituiti possono essere rifiutati dopo che il loro sostituto ha raggiunto uno stato stabile in produzione. Eseguire regolarmente la reindicizzazione e l’aggiornamento delle statistiche su SUSDB con lo script di Microsoft WSUSDBMaintenance.sql. Non fare affidamento sulla riduzione (shrinking); concentrarsi sulla salute degli indici. Per ambienti molto grandi, migrare SUSDB da WID a un’istanza completa di SQL Server per sfruttare l’indicizzazione avanzata, un I/O migliore e la pianificazione nativa di SQL Agent. Evitare di selezionare troppi prodotti e lingue: limitarsi a ciò che si distribuisce effettivamente per ridurre il churn dei metadati e l’onere di approvazione.

Aggiornamento orchestrato dal cloud: WUfB, Update Management Center, VM Guest Patching e Hotpatch

Windows Update for Business controlla quando i dispositivi ricevono gli aggiornamenti delle funzionalità (Feature update) e di qualità (Quality update) direttamente dalla CDN di Microsoft, utilizzando rinvii e pause basati su anelli (ring). Le policy di rinvio (tramite GPO o Intune) impostano Select when Preview Builds and Feature Updates are received e Select when Quality Updates are received. I valori tipici sono da 0 a 365 giorni per i Feature update e da 0 a 35 giorni per i Quality update. La sospensione degli aggiornamenti (Pause updates) interrompe l’installazione dei Feature o Quality update per un massimo di 35 giorni a partire da una data di inizio specificata, utile per bloccare un rollout mentre si indaga su un problema. Gli anelli (ring) sono implementati come assegnazioni di policy separate con diversi parametri di rinvio e pausa, passando da un gruppo IT/Pilota a un rilascio esteso (Broad) man mano che la fiducia aumenta. Utilizzare questa modalità quando non sono necessarie le approvazioni di WSUS o quando si preferiscono la distribuzione dei contenuti e le misure di sicurezza del cloud.

L’Update Management Center (UMC) in Azure modernizza l’orchestrazione per le VM di Azure e i server abilitati per Arc. Le pianificazioni delle valutazioni (Assessment schedule) definiscono quando le macchine calcolano gli aggiornamenti mancanti e il loro stato di conformità, solitamente su base giornaliera per mantenere aggiornate le dashboard. Le policy di patch definiscono cosa e quando installare: si scelgono le classificazioni, si includono/escludono KB, si definiscono finestre di manutenzione con fusi orari, si imposta il comportamento di riavvio (riavvia se necessario, sempre o mai) e si selezionano le opzioni di orchestrazione. L’ambito dinamico (Dynamic scoping) associa una policy a un insieme variabile di macchine utilizzando sottoscrizioni, gruppi di risorse, posizioni o tag; man mano che vengono aggiunte macchine con tag corrispondenti, queste vengono incluse automaticamente. Questo risolve la governance su larga scala senza dover mantenere manualmente elenchi di destinazioni. Per i set di disponibilità (availability set) e i set di scalabilità (scale set), UMC scagliona l’applicazione delle patch tra i domini di aggiornamento (update domain) per preservare il quorum e l’integrità del servizio.

L’applicazione automatica delle patch al sistema operativo guest della VM (Automatic VM guest patching) delega la selezione e l’installazione degli aggiornamenti critici (Critical) e di sicurezza (Security) alla piattaforma Azure. La valutazione viene eseguita con una cadenza gestita da Azure; l’orchestrazione delle patch rispetta i costrutti di disponibilità per minimizzare l’impatto. Le impostazioni di riavvio sono configurabili su IfRequired, Always o Never; selezionare Never solo se si dispone di un coordinamento esterno per i riavvii. Per i server che richiedono più dei soli aggiornamenti di sicurezza o che necessitano di specifiche finestre di blocco (blackout window), utilizzare le distribuzioni di patch pianificate di UMC invece della modalità completamente automatica.

L’Hotpatching elimina i riavvii per la maggior parte degli aggiornamenti di sicurezza mensili sulle immagini Azure supportate di Windows Server Azure Edition. Le versioni del sistema operativo supportate includono Windows Server 2022 Datacenter: Azure Edition e le versioni successive di Azure Edition. Il modello di manutenzione (servicing model) alterna mesi di baseline e mesi di hotpatch. Un mese di baseline fornisce un aggiornamento cumulativo che stabilisce una nuova linea di base e richiede un riavvio; i mesi di hotpatch successivi applicano patch in memoria senza riavvio, riducendo significativamente i tempi di inattività. Pianificare la manutenzione attorno ai mesi di baseline e utilizzare UMC o le policy per garantire che venga applicata almeno una baseline per ciclo, in modo da incorporare le modifiche non applicabili tramite hotpatch.

Reportistica di conformità e Azure Update Management (legacy)

La reportistica sulla conformità degli aggiornamenti deve soddisfare sia le esigenze di visibilità a livello dirigenziale sia l’analisi operativa della causa radice (root-cause analysis). I report di Windows Update for Business forniscono insight a livello di singolo dispositivo e aggregati sullo stato degli aggiornamenti, sui blocchi di salvaguardia (safeguard holds), sull’adozione delle versioni delle funzionalità e sulla diagnostica dei fallimenti. I dispositivi inviano i dati diagnostici richiesti a un’area di lavoro Log Analytics associata alla soluzione di reporting; l’onboarding può essere effettuato tramite Intune, chiavi di registro GPO per il Commercial ID o Azure Arc per i server. Utilizzare le cartelle di lavoro (workbook) integrate di Azure Monitor per suddividere i dati di conformità per anello (ring), versione del sistema operativo e categoria di aggiornamento; aggiungere i grafici critici alle dashboard di Azure per la visibilità del NOC.

Azure Update Management (legacy) combinava un account Azure Automation con un’area di lavoro Log Analytics. Le macchine (VM di Azure e server abilitati per Arc) riportavano i dati di valutazione a Log Analytics; le distribuzioni pianificate invocavano i runbook di Automation per orchestrare l’installazione delle patch entro finestre di manutenzione definite. I parametri controllati includevano le classificazioni, i KB inclusi/esclusi, gli script pre- e post-installazione e la policy di riavvio. Sebbene sia stato sostituito da Update Management Center, la versione legacy di Update Management rimane importante negli ambienti brownfield; la pianificazione della migrazione dovrebbe mappare le pianificazioni, gli ambiti (scope) e i comportamenti dei runbook alle policy di patching e allo scoping dinamico di UMC.

La classificazione e la gravità delle patch vengono spesso confuse, ma entrambe sono importanti per le policy. Aggiornamenti di sicurezza (Security updates) è la classificazione per gli aggiornamenti che risolvono le vulnerabilità. All’interno degli aggiornamenti di sicurezza, i livelli di gravità del Microsoft Security Response Center sono Critico (Critical), Importante (Important), Moderato (Moderate) e Basso (Low). Critico indica tipicamente l’esecuzione di codice in modalità remota o un impatto di tipo wormable su vasta scala; Importante spesso include l’elevazione dei privilegi o la divulgazione di informazioni; Moderato e Basso riflettono una sfruttabilità limitata o la presenza di mitigazioni. Nelle policy di WSUS e Azure, è preferibile distribuire rapidamente gli aggiornamenti di sicurezza (di tutte le gravità) agli anelli pilota (pilot ring) e ampliare la distribuzione man mano che la telemetria conferma la stabilità, pianificando invece gli aggiornamenti qualitativi non di sicurezza (Quality updates) in base alla tolleranza al cambiamento del business.

Infine, è necessario mantenere un ritmo operativo. Rifiutare regolarmente gli aggiornamenti scaduti e sostituiti dopo la convalida, eseguire mensilmente la procedura guidata di pulizia e la manutenzione degli indici SQL, risolvere i problemi dei client che non contattano WSUS o Azure entro gli SLA e valutare continuamente i rinvii degli anelli (ring) e la logica di pausa. Per le flotte ibride, standardizzare l’origine della scansione per ogni dispositivo su WSUS o WUfB; non mescolare le due fonti su un singolo server. Utilizzare Azure Arc per unificare la governance in modo che i server cloud e on-premise appaiano in un unico fabric di conformità.

Scenario pratico

Fabrikam, Inc. gestisce 600 macchine Windows Server: 250 on-premise dietro a rigidi controlli sul traffico in uscita (egress), 250 VM di Azure che ospitano applicazioni a più livelli (tiered) e 100 VM di Azure con Windows Server 2022 Datacenter: Azure Edition. Hanno bisogno di un patching prevedibile il martedì con tempi di inattività minimi, reportistica centralizzata e nessun targeting manuale.

1. Stabilire le origini della scansione e gli anelli (ring)

• Per i server on-premise, implementare un server WSUS centrale upstream nel datacenter con due server di replica downstream nelle filiali. Applicare il targeting lato client tramite GPO in modo che i server si auto-registrìno nei gruppi WSUS Pilot-Servers, Broad-Servers e Finance-Servers. Questo garantisce un’approvazione deterministica dei contenuti senza scansioni verso Internet.
• Per le VM di Azure, utilizzare Update Management Center con scoping dinamico basato su tag come Ring=Pilot o Ring=Broad per evitare elenchi gestiti manualmente. Questo allinea automaticamente le macchine cloud all’intento dell’anello man mano che vengono provisionate. Perché: WSUS soddisfa le restrizioni sul traffico in uscita e consente approvazioni granulari; UMC fornisce orchestrazione su scala cloud e governance basata su tag.

2. Definire la strategia di approvazione e rinvio

• In WSUS, approvare automaticamente gli Aggiornamenti di sicurezza (Security Updates) per i Pilot-Servers immediatamente; approvarli per i Broad-Servers con una scadenza di 7 giorni. Gli aggiornamenti qualitativi non di sicurezza (Quality updates) vengono prima approvati per i Pilot-Servers e promossi dopo la verifica.
• In UMC, creare due policy di patching: Pilot installa gli aggiornamenti di Sicurezza e Qualitativi il giorno successivo al Patch Tuesday; Broad rinvia gli aggiornamenti Qualitativi di 7 giorni. Entrambe le policy utilizzano l’opzione di riavvio se necessario (reboot if required) entro una finestra di manutenzione di 2 ore. Perché: Gli anelli (ring) permettono di individuare precocemente le regressioni, mantenendo al contempo un tempo di remediation (risoluzione) breve per le vulnerabilità.

3. Abilitare l’hotpatching sui server Azure Edition

• Migrare le VM Azure Edition idonee a immagini abilitate per l’hotpatching e registrarle nelle policy di patching di UMC che rispettano i mesi di riferimento (baseline). Assicurarsi che almeno una baseline venga applicata per ogni ciclo di baseline. Perché: L’hotpatching elimina la maggior parte dei riavvii sui 100 server Azure Edition, preservando gli SLA pur applicando le correzioni di sicurezza mensili.

4. Configurare il patching automatico del sistema operativo guest delle VM per i casi limite

• Per le VM di utilità a basso rischio, abilitare il patching automatico del sistema operativo guest delle VM (AutomaticByPlatform) limitato agli aggiornamenti di Sicurezza con riavvio se necessario, al di fuori dell’orario di lavoro. Perché: Riduce il carico operativo sui sistemi dove un controllo granulare non è necessario.

5. Rafforzare le GPO per i client WSUS

• Impostare le policy Specify intranet Microsoft update service location, Configure Automatic Updates, la frequenza di rilevamento e Do not allow update deferral policies to cause scans against Windows Update. Configurare No auto-restart with logged on users per i server. Perché: Previene conflitti sull’origine della scansione e riavvii indesiderati durante l’orario di servizio.

6. Implementare la reportistica di conformità

• Eseguire l’onboarding di tutti i server ai report di Windows Update for Business utilizzando Azure Arc per i server on-premise e l’integrazione nativa per le VM di Azure, inviando i dati diagnostici richiesti a un’area di lavoro Log Analytics dedicata. Pubblicare le cartelle di lavoro (workbook) di Azure Monitor segmentate per anello (ring) e ambiente. Perché: Reportistica da un unico pannello di controllo (single-pane) per tutto l’ambiente ibrido, con capacità di analisi dettagliata (drill-down) per la diagnostica dei fallimenti.

7. Mantenere l’integrità di WSUS e le prestazioni del database

• Mensilmente, eseguire la procedura guidata di pulizia di WSUS (WSUS Cleanup Wizard) per la potatura di aggiornamenti scaduti/sostituiti e computer obsoleti, rifiutare gli aggiornamenti sostituiti dopo la convalida ed eseguire lo script WSUSDBMaintenance.sql per reindicizzare il SUSDB. Limitare i prodotti/lingue a quelli effettivamente distribuiti da Fabrikam. Perché: Mantiene veloci le operazioni di sincronizzazione e approvazione, riduce i tempi di scansione dei client e previene l’aumento incontrollato delle dimensioni (bloat) del database.

8. Orchestrazione di finestre di rollout sicure

• In UMC, impostare il parallelismo per rispettare i set di disponibilità e le zone, garantendo un patching scaglionato. Per i cluster on-premise, coordinarsi con il Cluster-Aware Updating o applicare le patch ai nodi in sequenza tramite pianificazioni di manutenzione. Perché: Preserva la disponibilità delle applicazioni mentre vengono applicati gli aggiornamenti.

Questo approccio combina WSUS dove lo scoping verso Internet è limitato, l’orchestrazione nativa di Azure per l’elasticità, l’hotpatch per minimizzare i riavvii e una reportistica di conformità unificata, il tutto mappato a una governance basata su anelli (ring) che bilancia la velocità della sicurezza con la stabilità.

← Crittografia · Tutti i domini · Hyper-V →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Microsoft →