Windows Server in crisi dopo gli aggiornamenti di aprile: cosa sta succedendo
Quando Microsoft rilascia aggiornamenti fuori programma per the server , è un segnale forte: qualcosa è andato storto. Dopo il Patch Tuesday di aprile 2026, the update ha causato problemi seri su più versioni di Windows Server. Non si tratta di un semplice glitch o di un errore visivo: sono stati colpiti il processo di installazione, l’authentication e persino l’avvio dei sistemi. In un ambiente aziendale, questi problemi possono bloccare l’intera operation , con conseguenze gravi.
Il primo guaio riguarda l’aggiornamento di sicurezza KB5082063, che su Windows Server 2025 non si installa correttamente. Si verificano automatic rollback , blocchi e errori durante l’installazione. Ma il problema più grave è un ciclo di riavvio infinito su alcuni controller di dominio dopo l’aggiornamento cumulativo. Alla base c’è il crash del servizio LSASS (Autorità di Sicurezza Locale), fondamentale per la gestione delle policy, l’accesso utente e la creazione dei token. Quando LSASS si interrompe, Windows riavvia il sistema per protect integrity . Il risultato è un loop che rende il server inutilizzabile.
Microsoft ha rilasciato patch di emergenza: KB5091157 per Windows Server 2025, KB5091575 per il 2022, e altri per versioni precedenti. C’è però una differenza cruciale: solo l’update per il 2025 risolve entrambi i problemi, mentre quelli per le versioni più vecchie correggono soltanto i crash di LSASS. Questo suggerisce che i due bug abbiano technical origins diverse, nonostante siano emersi insieme. L’aggiornamento per il 2025 include anche una correzione per un problema aggiuntivo legato a BitLocker.
Infatti, alcuni server con Windows Server 2025 possono avviarsi in modalità di recupero BitLocker dopo l’update, chiedendo la chiave di ripristino al boot. Per sistemi gestiti da remoto o senza accesso fisico immediato, questa è una critical situation . Senza la chiave a portata di mano, il ripristino richiede intervento manuale, ritardi e rischio di downtime prolungato. È un problema subdolo, perché può presentarsi anche durante la configurazione iniziale di un nuovo server.
Gestire gli aggiornamenti mensili di Microsoft richiede caution , soprattutto sui controller di dominio. Stabilità e sicurezza non sempre vanno di pari passo nel breve termine. Dopo l’installazione, è essenziale monitorare i log di sistema, gli eventi di LSASS e lo stato dei servizi di autenticazione. Anche piccoli segnali di instabilità possono innescare effetti a catena. Distribuire gli update in modo graduale e testarli prima in ambienti di staging simili alla produzione è una best practice che riduce il rischio, anche se non lo elimina del tutto.
Un crash di LSASS che causa reboot infiniti? Non è solo un bug, è un system failure fallimento del sistema. Su un dominio critico, questo può fermare un'intera azienda.
Per fortuna uso Azure con hotpatch. Ma il fatto che il problema colpire anche i nuovi setup è inaccettabile. Microsoft doveva testare meglio prima del rollout.
Patch fuori programma su più versioni: segno che la quality control qualità del controllo sta scivolando. Siamo passati da "aggiornamenti affidabili" a "rischi calcolati".
La richiesta della chiave BitLocker al boot senza preavviso è pura follia. Chi ha server in datacenter remoti si ritrova bloccato senza soluzioni immediate.
Perché non rilasciano un tool automatico per verificare la compatibilità prima dell'update? Una simple check verifica semplice potrebbe evitare metà di questi disastri.
Ormai aspetto sempre 48 ore prima di applicare patch su produzione. Non è paranoia, è risk management gestione del rischio. Questo caso ne è la prova vivente.