• Guide, Sistemi Operativi
• 5 Novembre 2026

Chiunque gestisca infrastrutture sa bene cosa significhi affrontare un server che, dopo un aggiornamento, rifiuta di ripartire. Se l’incidente capita nel datacenter aziendale la situazione è gestibile, ma se accade su una macchina remota o in una filiale priva di presidio IT, il blocco dell’avvio si trasforma rapidamente in un’emergenza operativa, fatta di sessioni KVM remote spesso instabili o costose trasferte d’urgenza.

Gli eventi degli ultimi anni hanno reso evidente come i metodi tradizionali di recupero non siano più sufficienti a garantire la continuità operativa richiesta dai moderni carichi di lavoro. Con l’introduzione di Quick Machine Recovery, Microsoft porta anche su Windows Server 2025 una tecnologia pensata per risolvere alla radice questi scenari di disservizio, rendendo il sistema operativo capace di auto-ripararsi in caso di fallimento critico del boot.

Di Quick Machine Recovery ne avevamo parlato nel precedente articolo Quick Machine Recovery in Windows 11 – ICT Power

Sotto il cofano, la funzionalità sfrutta l’ambiente di diagnostica di Windows Recovery Environment (WinRE) integrandolo direttamente con i servizi di Windows Update. Quando la macchina rileva un blocco persistente durante la sequenza di avvio, avvia autonomamente una sessione di ripristino con connettività di rete, scarica la correzione mirata distribuita da Microsoft e la applica senza richiedere l’intervento manuale dell’amministratore né il ripristino completo da backup, abbattendo drasticamente i tempi di fermo macchina.

Per un approfondimento su WinRE vi rimando alla mia guida Gestire la Windows Recovery partition in Windows 10 e 11: eliminazione, estensione del disco e ricreazione di WinRE – ICT Power

Auto-remediation e Cloud Remediation

Il funzionamento e l’efficacia di Quick Machine Recovery si poggiano su due componenti distinte ma strettamente interconnesse, che è fondamentale comprendere per configurare al meglio la funzionalità: la Cloud Remediation e la Auto-remediation. Ciascuna di esse governa una fase specifica del processo di recupero e, pur operando in sinergia, rispondono a requisiti e logiche differenti.

La Cloud Remediation rappresenta l’abilitazione tecnologica che permette all’ambiente di ripristino di uscire dal suo tradizionale isolamento offline. Quando questa impostazione è attiva, il sistema autorizza l’ambiente Windows Recovery Environment (WinRE) a inizializzare la scheda di rete del server, a ottenere un indirizzo IP e a stabilire una connessione cifrata e sicura (via HTTPS) verso i server di Windows Update. È proprio grazie alla Cloud Remediation che il server, pur non potendo completare il boot, riesce a interrogare i database Microsoft per verificare se per il crash riscontrato esista una patch correttiva o una mitigazione ufficiale, procedendo poi al suo eventuale download.

Figura 1: Cloud Remediation

La Auto-remediation costituisce invece l’autorizzazione all’azione e all’autonomia decisionale della macchina. Una volta che la Cloud Remediation ha individuato e scaricato il pacchetto correttivo idoneo, la Auto-remediation permette al sistema di applicare direttamente e senza alcun intervento umano le modifiche necessarie sull’immagine offline del sistema operativo (come la rimozione di un file, il rollback di un aggiornamento o la sostituzione di un driver corrotto) per poi procedere al riavvio automatico. Se questa policy non fosse abilitata, il server si limiterebbe a mostrare a schermo o in console le informazioni sulla disponibilità di una soluzione, attendendo l’approvazione manuale di un amministratore prima di procedere con l’installazione del fix, vanificando di fatto l’obiettivo di un ripristino tempestivo e non presidiato.

Figura 2: Auto-remediation

Come funziona Quick Machine Recovery: il flusso operativo

Lo schema architetturale rilasciato da Microsoft illustra chiaramente la logica decisionale e la sequenza dei passaggi con cui Quick Machine Recovery affronta e risolve un blocco all’avvio.

Il flusso si articola in cinque passaggi chiave:

1. Rilevamento del crash e mancato avvio (Fase 1) Durante la fase di boot il server riscontra un errore irreversibile (“Your device ran into a problem and needs to restart”). Di fronte all’impossibilità di caricare il sistema operativo, la macchina non resta bloccata in un loop infinito di crash ma attiva il meccanismo di recupero indirizzando l’esecuzione verso l’ambiente dedicato.
2. Inizializzazione della rete in WinRE (Fase 2) Il sistema avvia l’ambiente Windows Recovery Environment (WinRE) e predispone lo stack di rete locale, mostrando a schermo la fase di collegamento (“Connecting to network…”). La scheda di rete ottiene la configurazione IP e stabilisce una connessione sicura verso l’infrastruttura cloud.
3. Interrogazione dei servizi cloud di ripristino (Fase 3) WinRE contatta i server di Windows Update trasmettendo i dettagli diagnostici relativi all’errore di stop rilevato sul server e allo stato attuale della build, verificando l’esistenza di una mitigazione nota per lo specifico problema.
4. Verifica della disponibilità della soluzione e ciclo di scansione (Fase 4) A questo punto il processo segue un bivio logico basato sulla presenza del fix:

• Se la soluzione non è ancora disponibile (No): Il server mostra una schermata informativa avvisando che il problema non può essere risolto immediatamente in automatico (“Your device ran into a problem and couldn’t be repaired automatically”). Il sistema imposta quindi un timer di attesa ed esegue scansioni a intervalli regolari (Looped Scan), riprovando a interrogare il cloud fino a quando il pacchetto correttivo non viene rilasciato da Microsoft.
• Se la soluzione è disponibile (Yes): WinRE procede immediatamente al download del pacchetto di correzione (“Downloading solution”), validandone crittograficamente l’integrità.

1. Applicazione mirata e ripristino del sistema (Fase 5) Il fix viene applicato direttamente all’immagine offline del sistema operativo. Completata l’installazione della patch, la macchina esegue un riavvio pulito tornando alla consueta schermata di accesso e ripristinando la piena operatività dei servizi.

Figura 3: Fasi del processo di Quick Machine Recovery

Come abilitare e configurare Quick Machine Recovery su Windows Server 2025

Un dettaglio fondamentale da cui partire: su Windows Server 2025, Quick Machine Recovery è disabilitata di default.

Inoltre, per poter accedere a questa tecnologia, la macchina deve necessariamente avere installato l’aggiornamento cumulativo di ottobre 2026 (KB5126646) o build successive. Senza questa specifica patch (o i successivi update mensili che la includono), le policy necessarie non saranno visibili e il sistema non supporterà l’inizializzazione del recupero tramite rete in WinRE.

La configurazione può essere gestita localmente (tramite l’Editor Criteri di Gruppo Locali) o, molto più comodamente in ambienti di produzione, centralizzata tramite una GPO di dominio in Active Directory.

Aprite l’editor dei criteri di gruppo e navigate nel percorso Computer Configuration > Administrative Templates > System > Quick Machine Recovery. Abilitate la policy Enable Cloud Remediation. Impostate lo stato su Enabled per autorizzare l’ambiente di ripristino a connettersi ai servizi cloud di Microsoft e ricercare le correzioni mirate.

Figura 4: Abilitazione del criterio Enable Cloud Remediation

Aprite la policy Enable Auto Remediation e impostatela su Enabled. Questo passaggio permette al sistema di installare autonomamente i pacchetti correttivi scaricati senza attendere una conferma manuale dell’operatore.

Figura 5: Configurazione della policy Enable Auto Remediation per consentire l’installazione automatica e non presidiata dei pacchetti di correzione locali

Dopo aver autorizzato la remediation cloud e l’applicazione automatica dei pacchetti, potete definire con precisione il comportamento temporale di Quick Machine Recovery intervenendo sui due criteri dedicati agli intervalli di esecuzione. Queste impostazioni vi permettono di allineare i tentativi di recupero agli SLA della vostra infrastruttura e ai tempi di tolleranza al disservizio.

Il primo parametro da configurare è Set Recovery Retry Interval. Questo criterio determina l’intervallo, espresso in minuti, che deve intercorrere tra un tentativo di ripristino e il successivo.

Il secondo parametro è Set Total Recovery Wait Time. Questa voce stabilisce il tempo massimo complessivo, sempre espresso in minuti, che l’engine di ripristino può impiegare per l’insieme di tutti i tentativi di recupero prima di desistere definitivamente e consentire al server di proseguire con l’avvio standard o di entrare nell’ambiente di ripristino tradizionale.

Figura 6: Configurazione avanzata dei criteri temporali Set Recovery Retry Interval e Set Total Recovery Wait Time per la gestione della frequenza dei tentativi e del timeout complessivo di remediation

L’effetto dell’abilitazione nell’ambiente di ripristino

Riavviando il server in modalità di emergenza o accedendo alla schermata More recovery options, potrete notare la comparsa del riquadro dedicato con l’icona del cloud: Quick machine recovery (“Let your device search for solutions to repair itself”).

La presenza di questa opzione conferma che la macchina ha recepito correttamente le direttive e che il sistema è ora pronto a inizializzare la scheda di rete verso Microsoft Update, sia in caso di avvio manuale guidato dall’operatore sia durante i tentativi di remediation automatica non presidiata.

Figura 7: Comparsa della voce Quick machine recovery nel menu More recovery options di WinRE a seguito dell’abilitazione del criterio Enable Cloud Remediation tramite Group Policy

Verifica e ripristino delle impostazioni di recovery

Per convalidare con precisione che le configurazioni definite tramite i criteri di gruppo siano state correttamente recepite e scritte all’interno dell’ambiente di recupero, la documentazione ufficiale di Microsoft mette a disposizione un comando dedicato integrato nell’utilità reagentc.exe.

Eseguendo una sessione di PowerShell o prompt dei comandi con privilegi elevati, potete lanciare il comando:

Come potete osservare nell’output restituito in formato XML, il comando elenca in modo trasparente l’effettivo stato operativo applicato a Windows Recovery Environment (WinRE):

• CloudRemediation state=”1″: certifica che l’abilitazione alla ricerca di soluzioni correttive tramite cloud è attiva.
• AutoRemediation state=”1″: conferma che l’applicazione automatica dei pacchetti senza richiesta di intervento manuale è abilitata.
• totalwaittime=”15″ e waitinterval=”3″: riflettono esattamente i valori in minuti che avete impostato nelle policy per il tempo massimo complessivo di attesa e per l’intervallo tra i vari tentativi di scansione.

Nel caso in cui abbiate l’esigenza di effettuare un rollback, azzerare le configurazioni personalizzate o ripristinare il comportamento predefinito del sistema, potete disabilitare o reimpostare su Not Configured i criteri di gruppo corrispondenti. Una volta forzato l’aggiornamento con gpupdate /force, rilanciando reagentc.exe /getrecoverysettings potrete verificare che i flag tornino allo stato predefinito (con remediation disattivata), garantendo così un controllo puntuale e verificabile del ciclo di vita della funzionalità.

    Figura 8: Verifica delle impostazioni di recovery

Testare Quick Machine Recovery in ambiente controllato (Test Mode)

Prima di procedere con la distribuzione delle policy in produzione, potete validare l’intera catena di autoriparazione sfruttando la modalità di test integrata nel sistema operativo. Microsoft ha infatti previsto un ambiente simulato che vi consente di verificare il corretto funzionamento dell’auto remediation e della connettività in Windows Recovery Environment (WinRE) senza dover provocare un reale arresto anomalo del server.

L’avvio della simulazione richiede due semplici istruzioni da eseguire all’interno di una sessione di PowerShell o del prompt dei comandi con privilegi elevati:

Il primo comando predispone l’ambiente di recupero impostando il flag per la modalità simulata, mentre il secondo forza il riavvio della macchina direttamente all’interno della partizione di ripristino al boot successivo. A questo punto vi basterà riavviare il server.

Figura 9: Abilitazione della modalità di test e configurazione del riavvio automatico in WinRE

Durante la sequenza di avvio, la macchina entrerà automaticamente in WinRE ed eseguirà il ciclo di remediation simulando un crash critico. A video noterete l’indicazione esplicita [Test Mode] Looking for solutions…, a conferma che l’engine di recupero sta analizzando il sistema e tentando di instaurare il collegamento di rete per scaricare i contenuti di riparazione. Se il server dispone di una connessione Ethernet attiva (o di un profilo WiFi compatibile configurato per la connessione automatica in WinRE), l’ambiente stabilirà la connessione in totale autonomia. Una volta completato il ciclo di verifica, la macchina eseguirà un riavvio standard tornando direttamente al desktop di Windows.

Figura 10: Schermata di avvio del server durante il Test Mode mentre WinRE verifica la connettività e simula la ricerca della soluzione

Considerazioni operative e limiti attuali

L’introduzione di Quick Machine Recovery su Windows Server 2025 segna senza dubbio una svolta fondamentale nella gestione della resilienza del sistema operativo, trasformando un ambiente storicamente statico e reattivo come WinRE in un vero e proprio strumento autonomo di autoriparazione. Tuttavia, prima di procedere con l’attivazione massiva tramite GPO sull’intera infrastruttura, dovete valutare con attenzione alcuni aspetti architetturali e operativi.

Il primo fattore critico riguarda la connettività di rete in fase di boot. In molti scenari enterprise i server di produzione sono attestati su VLAN isolate prive di accesso diretto a Internet, oppure necessitano di proxy autenticati o regole firewall estremamente stringenti per raggiungere il cloud. Poiché WinRE opera con uno stack di rete essenziale, dovete accertarvi che i dispositivi possano ottenere i corretti parametri IP e che la risoluzione DNS e il traffico HTTPS verso gli endpoint di Windows Update siano effettivamente consentiti a livello perimetrale senza richiedere certificati utente o login su captive portal. In assenza di accesso alla rete esterna, la Cloud Remediation non potrà completare il recupero.

Un secondo elemento da tenere a mente è la natura del problema. Quick Machine Recovery è progettato specificamente per risolvere incidenti derivanti da aggiornamenti software difettosi, driver corrotti o blocchi noti già mappati e mitigati da Microsoft nel cloud. Non si tratta di una soluzione onnicomprensiva: guasti hardware a monte (come guasti al controller di storage o banchi di memoria RAM fallati), corruzioni logiche gravi del file system o disservizi specifici legati al database dei servizi applicativi interni richiederanno sempre il tradizionale intervento sistemistico o il ripristino da backup.

Conclusioni

L’introduzione di Quick Machine Recovery su Windows Server 2025 rappresenta un passo avanti concreto verso l’auto-riparazione delle infrastrutture mission-critical. La possibilità di delegare a WinRE la risoluzione automatica dei blocchi all’avvio, dialogando direttamente con Windows Update, riduce drasticamente i tempi di disservizio ed evita interventi manuali complessi, soprattutto negli scenari distribuiti o nelle filiali prive di personale tecnico locale.

La tecnologia non va intesa come un sostituto dei piani di backup e disaster recovery, ma come una linea di difesa automatizzata contro gli aggiornamenti problematici. Il consiglio è di testarne subito l’efficacia in un ambiente di laboratorio o su un gruppo pilota di macchine, calibrando con attenzione i criteri di Cloud Remediation, Auto Remediation e i timeout operativi. Una volta validata la connettività in ambiente di ripristino, potrete distribuire le policy tramite GPO sull’intero dominio, dotando la vostra infrastruttura di una tutela fondamentale contro i fermi macchina imprevisti.