Risolto loop di avvio dopo aggiornamento su Windows Server 2016 con RAID

In uno dei nostri ambienti di produzione basati su Windows Server 2016, ci siamo trovati di fronte a un problema critico subito dopo l’installazione di un aggiornamento cumulativo: il server rimaneva bloccato nella schermata “Preparazione di Windows – Non spegnere il computer”, per poi riavviarsi in loop continuo.

Il comportamento era sintomo di un malfunzionamento del Component Store (WinSxS), il cuore del sistema di gestione aggiornamenti e componenti di Windows. In questo articolo spieghiamo come abbiamo diagnosticato e risolto il problema, riportando il server in stato operativo senza reinstallare l’ambiente.

– Analisi del problema

Durante l’avvio, il sistema non completava mai la fase di configurazione degli aggiornamenti e si riavviava ciclicamente. Nemmeno la modalità provvisoria o il ripristino automatico erano in grado di risolvere la situazione.

Abbiamo quindi avviato il server nell’ambiente di ripristino di Windows (WinRE) per operare con i comandi offline di manutenzione immagine.

dism /image:C:\ /cleanup-image /checkhealth
dism /image:C:\ /cleanup-image /restorehealth

Entrambi restituivano l’errore 0x800f081f, indicando l’impossibilità di trovare i file di origine necessari alla riparazione del sistema.

– Riparazione con DISM e ISO di Windows Server 2016

Per ripristinare il Component Store, abbiamo montato la ISO ufficiale di Windows Server 2016 tramite Lenovo XClarity Controller, rendendola disponibile come unità virtuale (E:).

dism /image:C:\ /cleanup-image /restorehealth /source:wim:E:\sources\install.wim:2 /limitaccess /ScratchDir:C:\Scratch

Dopo diversi tentativi, il processo si è completato con successo:

“Operazione di ripristino riuscita.”

Questo ha ricostruito completamente il WinSxS e risolto le azioni di aggiornamento in sospeso che impedivano l’avvio del sistema.

– Caricamento dei driver RAID in ambiente di ripristino

Durante le prime fasi di diagnosi ci siamo accorti che, all’interno dell’ambiente di ripristino, Windows non caricava i driver del controller RAID installato nel sistema (nel nostro caso un ThinkSystem RAID 930-8i).

Questo comportava che i volumi logici non risultassero visibili con il comando diskpart → list volume, impedendo di accedere al disco del sistema (C:).

La soluzione è stata caricare manualmente i driver del controller:

1. Abbiamo scaricato dal sito Lenovo i driver più recenti del controller RAID.
2. Abbiamo estratto il pacchetto (file .exe) con 7-Zip, poiché i file di installazione non sono riconosciuti nativamente da WinRE.
3. All’interno dell’archivio, abbiamo individuato i file .INF necessari al caricamento manuale.
4. Abbiamo montato l’immagine ISO o IMG contenente i driver come unità virtuale tramite XClarity Controller.
5. Da prompt dei comandi di WinRE abbiamo eseguito:

   drvload E:\percorsi\driver\megaraid.inf

Dopo il caricamento, il comando wmic logicaldisk get name ha mostrato correttamente il volume C:, consentendoci di procedere con la riparazione tramite DISM.

Questo passaggio è fondamentale su hardware server con controller dedicati: senza il driver RAID, l’ambiente di ripristino non è in grado di accedere ai dischi e qualsiasi tentativo di manutenzione fallisce.

– Verifica e pulizia post-ripristino

Dopo la riparazione, abbiamo eseguito:

sfc /scannow

per verificare e ripristinare eventuali file di sistema danneggiati.

Successivamente, abbiamo pulito i componenti residui e rimosso versioni obsolete dei file:

dism /online /cleanup-image /startcomponentcleanup /resetbase

– Ripristino del database di Windows Update

Il tool di risoluzione problemi di Windows segnalava un errore nel “controllo del database di Windows Update”. Abbiamo quindi rigenerato manualmente la cache degli aggiornamenti rinominando le cartelle di sistema:

net stop wuauserv
net stop bits
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start wuauserv
net start bits

Questo ha permesso di ricreare un database pulito, eliminando riferimenti a patch corrotte o incomplete.

– Risultato finale

Dopo il riavvio, il server si è avviato correttamente senza più blocchi o loop di aggiornamento. Tutti i servizi di produzione sono tornati operativi e Windows Update è stato riallineato con il sistema.

• nessuna reinstallazione del sistema operativo;
• dati e configurazioni preservati;
• stabilità del sistema completamente ripristinata.

– Lezioni apprese e prevenzione

Abbiamo riscontrato che i loop post-aggiornamento su Windows Server 2016 derivano spesso da azioni pendenti nel processo di servicing. Per ridurre il rischio, consigliamo di:

• utilizzare strumenti come PSWindowsUpdate o WSUS Offline Update per applicare patch in modo transazionale;
• installare sempre prima il Servicing Stack Update (SSU) e poi il Cumulative Update (CU);
• eseguire periodicamente la pulizia del Component Store:

  dism /online /cleanup-image /startcomponentcleanup /resetbase

– Conclusione

Grazie a un intervento mirato con DISM, al caricamento manuale dei driver RAID e all’uso dell’immagine originale di Windows Server 2016 come sorgente, siamo riusciti a ripristinare completamente un sistema in produzione bloccato da un aggiornamento fallito.

L’esperienza conferma l’importanza di conoscere e utilizzare correttamente gli strumenti di manutenzione avanzata di Windows Server, in modo da prevenire fermi imprevisti e ridurre i tempi di downtime.

---

– Autore

LandLogic – Soluzioni IT e infrastrutture aziendali
Siamo specializzati in sistemi Windows Server, ambienti virtualizzati, automazione IT e sicurezza aziendale.
🔗 www.landlogic.it