Il problema: un dispositivo che non si avvia più è un’emergenza, non un ticket

Chiunque gestisca una flotta di endpoint Windows conosce lo scenario: un aggiornamento difettoso, un driver incompatibile o una configurazione errata mandano in loop di crash un gruppo di macchine proprio durante la finestra di manutenzione. Il risultato classico è una coda di ticket, tecnici che girano fisicamente tra le postazioni con una chiavetta USB di ripristino e ore di produttività perse. Microsoft ha introdotto Quick Machine Recovery (QMR) esattamente per affrontare questo tipo di incidente: una funzionalità, disponibile sia su Windows 11 (24H2 e successive) sia su Windows Server 2025, che prova a correggere automaticamente i guasti di avvio diffusi sfruttando Windows Update direttamente dall’ambiente di ripristino.

In questo articolo vediamo come funziona QMR, come si configura nei diversi scenari (locale, Group Policy, Intune/Recovery CSP), quali sono i valori predefiniti per edizione e perché, prima di attivarla in produzione, serve un piano di pilot e di rollback.

Cos’è Quick Machine Recovery e come funziona

QMR si basa su Startup Repair e sul Windows Recovery Environment (WinRE), ma con una differenza fondamentale: può connettersi alla rete per scaricare da Windows Update i rimedi che Microsoft ha già identificato per un determinato guasto, invece di limitarsi alla diagnosi locale. Il processo si articola in quattro fasi:

1. Device crash: il dispositivo non riesce ad avviarsi ripetutamente e il sistema attiva il ripristino automatico.
2. Boot to recovery: la macchina entra in WinRE.
3. Connessione di rete: se la cloud remediation è abilitata, il dispositivo si collega alla rete e interroga Windows Update per cercare un rimedio conosciuto.
4. Remediation: se un rimedio viene trovato, viene scaricato e applicato; se non viene trovato, in base alla configurazione l’utente viene guidato verso altre opzioni di ripristino oppure il sistema ritenta automaticamente a intervalli regolari.

Se il rimedio ha successo, la macchina si avvia normalmente in Windows; in caso contrario torna a WinRE e il ciclo si ripete, fino al raggiungimento del timeout configurato.

Le due impostazioni che contano davvero

• Cloud remediation: se attiva, il dispositivo usa la rete e Windows Update durante il recovery; se disattivata, resta tutto locale con il solo Startup Repair tradizionale.
• Auto remediation: se attiva, la ricerca del rimedio parte automaticamente, con scansione singola (default) oppure a intervalli ripetuti per un tempo massimo configurabile; se disattivata, serve l’intervento manuale dell’utente o del tecnico.

Valori predefiniti: non tutte le edizioni si comportano uguale

Un punto che genera spesso confusione nei team IT è che QMR non ha lo stesso comportamento out-of-the-box ovunque. Ecco la tabella dei default:

Un dettaglio importante: se non si configura esplicitamente la cloud remediation, il suo valore predefinito cambia automaticamente nel momento in cui un dispositivo passa da “non gestito” a “gestito” (ad esempio quando viene iscritto a Intune). Se invece l’amministratore ha impostato un valore esplicito, quello resta valido indipendentemente dallo stato di gestione.

Come verificare e configurare QMR

Lo strumento principale da riga di comando è reagentc.exe, lo stesso binario storicamente usato per gestire WinRE. Per leggere la configurazione attuale, da un prompt dei comandi con privilegi elevati:

reagentc.exe /getrecoverysettings

L’output è un XML simile a questo:

<?xml version='1.0' encoding='utf-8'?>
<WindowsRE>
    <WifiCredential>
        <Wifi ssid="ContosoWiFi" password="ContosoWiFiPassword" />
    </WifiCredential>
    <CloudRemediation state="1" />
    <AutoRemediation state="1" totalwaittime="2400" waitinterval="120"/>
</WindowsRE>

Attenzione alle credenziali: questo output può contenere la password della rete Wi-Fi usata per il recovery in chiaro. Non va mai salvato in repository Git, ticket di supporto, screenshot o log conservati a lungo termine: va trattato come un segreto a tutti gli effetti.

Per impostare una configurazione, si usa un file XML revisionato (non un esempio copiato a caso, visto che contiene tempi di attesa e, potenzialmente, credenziali):

reagentc.exe /setrecoverysettings /path settings.xml
reagentc.exe /info
reagentc.exe /clearrecoverysettings

/info verifica lo stato di WinRE, non il successo di un’eventuale remediation già applicata; /clearrecoverysettings rimuove la configurazione locale, ma se il dispositivo è gestito da GPO o Intune queste impostazioni possono essere ripristinate automaticamente al giro successivo di applicazione delle policy.

Group Policy su Windows Server 2025

Sui server, il percorso della policy è:

Configurazione computer > Modelli amministrativi > Sistema > Quick Machine Recovery

Per verificare l’esito dell’applicazione della policy su un server:

gpresult /scope computer /r

Un’insidia comune: lo stato “Not Configured” nella GPO non equivale a “disabilitato”. Semplicemente restituisce il controllo alle impostazioni locali o ai default di edizione, che per Server 2025 significano cloud remediation disattivata. Se l’obiettivo è abilitarla sui server, va impostata esplicitamente.

Gestione su larga scala: Recovery CSP e Intune

Per un parco macchine Windows 11 gestito, la via consigliata è la Recovery CSP tramite Intune, che permette di definire centralmente cloud remediation, auto remediation e i parametri di timing:

• Intervallo di retry: da 0 a 4320 minuti (0 significa un solo tentativo, nessun ciclo).
• Attesa totale: da 1 a 4320 minuti; il retry non può superare l’attesa totale.

Questi non sono valori “raccomandati” da Microsoft, ma limiti tecnici di configurazione: il budget di attesa va scelto in base al Recovery Time Objective del workload interessato, e va definito a priori chi ha l’autorità di interrompere l’attesa e innescare il fallback manuale (reinstallazione, supporto di ripristino, intervento on-site).

I requisiti minimi di build per i nodi gestiti via CSP sono 24H2 build 26100.8737 e 25H2 build 26200.8737 o versioni successive; su Windows Server 2025 serve inoltre l’aggiornamento di sicurezza di ottobre 2026 o successivo.

Test mode: utile, ma con un limite importante

Microsoft offre una modalità di test per simulare l’auto remediation senza attendere un guasto reale:

reagentc.exe /SetRecoveryTestmode
reagentc.exe /BootToRe

Dopo il riavvio, se la macchina entra in WinRE invece che nella simulazione, occorre selezionare Continue, tornare in Windows ed eseguire:

reagentc.exe /Disable
reagentc.exe /Enable

prima di ripetere il test. Il limite da tenere bene a mente: questa modalità di test è disponibile solo sui dispositivi Windows nel canale Experimental del Windows Insider Program. Non va presentata come procedura di test supportata per Server 2025 o per client di produzione generici: su quei sistemi si possono solo documentare evidenze parziali (ricezione corretta della policy, impostazioni effettive via /getrecoverysettings, raggiungibilità della rete di recovery da WinRE), segnando l’effettiva remediation come “non testata end-to-end”.

Checklist prima del rollout in produzione

• Fare un inventario per edizione, build, autorità di gestione (GPO vs Intune vs locale) e metodo di rete di recovery disponibile, separando endpoint utente, server e sistemi headless.
• Testare la connettività di rete da WinRE, non solo da una sessione Windows funzionante: driver di rete, assegnazione IP, risoluzione DNS e accesso ai servizi Microsoft necessari possono comportarsi diversamente in ambiente di ripristino. Le reti supportate sono Ethernet e Wi-Fi con autenticazione WPA/WPA2.
• Verificare che esista un percorso autorizzato alle chiavi di ripristino BitLocker, senza copiarle in checklist o ticket.
• Definire in anticipo un runbook di rollback: non esiste una disinstallazione automatica di una remediation già applicata. Serve chiarezza su chi autorizza Startup Repair, supporti di ripristino o reinstallazione, quali dati preservare e chi convalida che il workload sia tornato operativo.
• Eseguire un pilot su hardware rappresentativo e, se possibile, su un server non critico, con backup verificato e accesso alla console prima di qualsiasi test, senza mai simulare guasti di avvio reali su sistemi di produzione.

L’esito della remediation è visibile in Impostazioni > Windows Update > Cronologia aggiornamenti > Aggiornamenti di qualità; è buona norma validare anche il comportamento del carico di lavoro aziendale reale, non solo che la schermata di accesso riappaia.

Conclusione

Quick Machine Recovery è uno strumento interessante per chi gestisce flotte Windows di dimensioni medio-grandi, perché riduce drasticamente il tempo necessario a riportare online dispositivi colpiti da guasti di avvio noti e già risolti da Microsoft. Ma è bene ricordare che si tratta di un meccanismo best-effort, non di una garanzia di riparazione: richiede rete funzionante dall’ambiente di ripristino, ha comportamenti predefiniti diversi per edizione, e la sua modalità di test formale resta per ora limitata al canale Insider Experimental. Prima di abilitarla su larga scala, vale la pena investire tempo in un pilot controllato, in una policy di approvazione chiara (specialmente se si usa Windows Autopatch) e in un runbook di rollback testato, così da sfruttarne i vantaggi senza sorprese.

Fonte: 4sysops.com, con approfondimenti da Microsoft Learn e itecsonline.com.