Windows settings backup and restore with Microsoft Intune
- Introduzione
- Come funziona Windows settings backup and restore
- Requisiti per il backup e il restore
- Configurare Windows Backup con Microsoft Intune
- Abilitare Windows Restore durante OOBE
- Abilitare il restore al primo accesso
- Verificare backup e restore
- Esperienza utente durante Windows Restore
- Troubleshooting
- Considerazioni per gli ambienti aziendali
- Conclusioni
Introduzione
Quando sostituiamo un dispositivo aziendale, reinstallare Windows e completare l’enrollment in Microsoft Intune è soltanto una parte del lavoro. L’utente deve ritrovare le proprie impostazioni e poter tornare a lavorare senza riconfigurare tutto manualmente.
Windows settings backup and restore, precedentemente chiamato Windows Backup for Organizations, permette di salvare nel cloud alcune impostazioni Windows e l’elenco delle app Microsoft Store supportate, per poi recuperarli quando l’utente configura un nuovo dispositivo. Possiamo gestire la funzionalità con Intune e affiancarla a Windows Autopilot, OneDrive e alla normale distribuzione applicativa.
Il nome è cambiato nel luglio 2026, ma non è l’unica novità: ora possiamo proporre il restore anche al primo accesso dopo l’enrollment e Windows 11 26H2 introduce il backup predefinito sui nuovi dispositivi idonei. Aggiorniamo quindi i prerequisiti, configuriamo le policy Intune e vediamo come verificarle sul client, riprendendo anche i controlli già eseguiti nel laboratorio originale.
Il servizio non crea un’immagine del dispositivo e non salva i documenti dell’utente. Per Desktop, Documenti e Immagini possiamo utilizzare OneDrive e Known Folder Move; le applicazioni Win32, invece, continuano a richiedere i normali meccanismi di distribuzione. Anche l’elenco delle app Microsoft Store non equivale a un backup dei dati e delle configurazioni interne di ciascuna applicazione.
Come funziona Windows settings backup and restore
Sul dispositivo sorgente Windows crea un backup associato all’utente che ha effettuato l’accesso con il proprio account Microsoft Entra. Quando lo stesso utente configura un altro dispositivo, può scegliere un profilo di backup disponibile e recuperare le impostazioni supportate: ad esempio, alcune preferenze di Accessibilità, Personalizzazione, notifiche ed Esplora file. Per verificare cosa viene effettivamente salvato, facciamo riferimento al catalogo ufficiale Windows Backup, che riporta le singole voci e le relative limitazioni.
La procedura automatica viene eseguita ogni otto giorni, mentre dall’app Windows Backup possiamo avviare un salvataggio manuale, utile soprattutto poco prima della sostituzione del dispositivo. I backup sono legati al tenant dell’utente: non possiamo usarli come strumento per migrare direttamente le impostazioni da un tenant Microsoft Entra a un altro.
Per le app Microsoft Store viene conservato l’elenco delle applicazioni supportate, che Windows utilizza nell’esperienza di ripristino; non vengono invece salvati i relativi dati applicativi. Anche le preferenze di Microsoft Edge seguono un percorso differente e, per favoriti e impostazioni del browser, dobbiamo utilizzare Microsoft Edge Enterprise Sync.
Enterprise State Roaming e Windows Backup
Se utilizzate già Enterprise State Roaming (ESR), tenete presente che ESR sincronizza alcune impostazioni associate all’utente tra dispositivi, mentre Windows Backup conserva un profilo delle preferenze da recuperare durante il restore. I cataloghi delle impostazioni supportate sono diversi, quindi una preferenza sincronizzata con ESR potrebbe non essere disponibile nel backup.
Da luglio 2026 la gestione amministrativa di ESR è confluita nell’esperienza Windows settings backup and restore. Questo non elimina la distinzione funzionale tra roaming e backup: prima di cambiare le policy già in uso, controlliamo quali impostazioni sono abilitate e quale comportamento ci aspettiamo sui dispositivi.
| Caratteristica | Enterprise State Roaming | Windows settings backup and restore |
|---|---|---|
| Impostazioni | Preferenze comprese nel catalogo ESR | Preferenze comprese nel catalogo Windows Backup |
| Logica | Sincronizzazione opportunistica tra dispositivi dell’utente | Backup associato al dispositivo di origine, selezionabile durante il restore |
| Frequenza | Sincronizzazione opportunistica delle modifiche | Backup ogni otto giorni o manuale |
| Utilizzo tipico | Mantenere allineate le preferenze tra più dispositivi | Recuperare preferenze dopo refresh, reset o reinstallazione |
Requisiti per il backup e il restore
Il dispositivo dal quale salviamo le impostazioni e quello sul quale vogliamo recuperarle possono avere requisiti differenti. Anche restore durante OOBE e restore al primo accesso vanno valutati separatamente: le build indicate di seguito sono le soglie minime pubblicate nella panoramica Microsoft e non vanno confuse con le versioni Windows ancora supportate.
Requisiti per il backup
Per il backup serve un dispositivo Microsoft Entra joined o Microsoft Entra hybrid joined, sul quale l’utente accede con un account Microsoft Entra. Le build minime pubblicate sono:
| Sistema operativo | Build minima per il backup |
|---|---|
| Windows 10 22H2 | 19045.6216 |
| Windows 11 22H2 | 22621.5768 |
| Windows 11 23H2 | 22631.5768 |
| Windows 11 24H2 | 26100.4946 |
Queste soglie spiegano il requisito tecnico della funzionalità, ma alcune versioni Windows della tabella hanno già raggiunto la fine del supporto ordinario. Per nuove distribuzioni partirei da una versione Windows 11 supportata e aggiornata, verificando anche eventuali vincoli dell’edizione installata.
Con Windows 11 26H2, dal 29 settembre 2026 il backup è abilitato per impostazione predefinita sui dispositivi idonei, a condizione che la relativa policy sia su Not Configured, il cloud sia supportato e il dispositivo non si trovi in una regione esclusa per motivi di privacy. Nei paesi soggetti al Digital Markets Act (DMA), Italia compresa, il backup resta disattivato per impostazione predefinita: se vogliamo utilizzarlo, dobbiamo abilitarlo esplicitamente tramite Intune. Le policy già impostate su Enabled o Disabled continuano ad avere la precedenza, mentre il restore deve comunque essere configurato separatamente.
Requisiti per Windows Restore
La schermata di recupero può essere proposta durante la Out-of-Box Experience (OOBE) oppure al primo accesso successivo all’enrollment. Sono due flussi separati anche dal punto di vista amministrativo e non possiamo presumere che una policy prevista per l’uno valga automaticamente per l’altro.
| Requisito | Restore durante OOBE | First-sign-in restore |
|---|---|---|
| Build minime | Windows 11 22H2 22621.3958; 23H2 22631.3958; 24H2 26100.4770 | Windows 11 24H2 26100.7922; 25H2 26200.7922 |
| Tipo di join | Microsoft Entra joined | Microsoft Entra joined; Microsoft Entra hybrid joined negli scenari compatibili |
| Momento | Durante la configurazione iniziale | Primo accesso dopo il completamento dell’enrollment |
| Windows Autopilot | Deployment user-driven supportato, non self-deploying | Verificare il metodo di provisioning effettivo |
| Backup dell’utente | Almeno un profilo già disponibile | Almeno un profilo già disponibile |
La documentazione richiede inoltre di controllare Install Windows quality updates nell’Enrollment Status Page se la build è troppo vecchia per mostrare correttamente l’esperienza: il riferimento temporale è luglio 2025 per OOBE e marzo 2026 per il first-sign-in restore. Questa impostazione non sostituisce gli altri prerequisiti, quindi conviene verificare la build effettiva sul dispositivo di destinazione.
Il restore durante OOBE richiede un dispositivo Microsoft Entra joined e, se utilizziamo Windows Autopilot, un deployment user-driven supportato. Il first-sign-in restore è previsto anche per dispositivi Microsoft Entra hybrid joined negli scenari compatibili, come indica la panoramica Windows. La guida Intune continua però a elencare Hybrid Join e altri metodi di provisioning tra quelli non supportati, mentre la FAQ contiene ancora indicazioni precedenti al first-sign-in restore. Evitiamo quindi di estendere automaticamente le limitazioni di un flusso all’altro e, soprattutto con Hybrid Join, Group Policy enrollment o co-management, proviamo il ripristino sul metodo di registrazione effettivamente utilizzato prima del rollout.
Sono inoltre esclusi i cloud governativi/sovrani e China indicati nella documentazione, così come i dispositivi condivisi o privi di utente. Per modificare l’impostazione tenant-wide che mostra la pagina di restore durante OOBE servono i privilegi Intune Service Administrator oppure Global Administrator; per creare le altre policy servono i normali permessi di gestione delle configurazioni Intune. Non è descritta una licenza aggiuntiva dedicata al solo backup, ma rimangono necessari i diritti d’uso dei servizi Intune ed Entra impiegati nella distribuzione.
Configurare Windows Backup con Microsoft Intune
Iniziamo dal dispositivo sorgente. Accediamo al Microsoft Intune admin center e apriamo Devices > Manage devices > Configuration > Create > New policy; selezioniamo Windows 10 and later come piattaforma e Settings catalog come profilo. La voce di navigazione può comparire in modo leggermente diverso in base all’interfaccia del portale, ma il profilo da utilizzare resta il Settings Catalog.
Nella scheda Basics assegniamo un nome riconoscibile, ad esempio ENJ - Windows Settings Backup - Pilot, e in Configuration settings facciamo clic su Add settings. Nel Settings picker troviamo Administrative Templates > Windows Components > Sync your settings > Enable Windows Backup: selezioniamo l’impostazione e portiamola su Enabled.
Passiamo quindi a Scope tags, dove possiamo mantenere il valore Default oppure applicare quelli previsti dal nostro modello di amministrazione, e assegniamo il profilo al gruppo pilota nella pagina Assignments. Ho mantenuto un gruppo di dispositivi limitato per il test, così è più semplice controllare sia la ricezione della policy sia il comportamento del backup sui client selezionati.
Dopo Review + create completiamo la creazione con Create. Intune distribuirà la configurazione al normale check-in MDM; quando il profilo risulta Succeeded, sappiamo che la policy è stata applicata, ma questo stato non certifica che esista già un backup completo. Per una verifica immediata possiamo avviare il salvataggio manuale dall’app Windows Backup, evitando di attendere il ciclo automatico di otto giorni.
Altre impostazioni da controllare
Se la policy è stata applicata ma il backup non parte, la prima cosa che controllerei sono i criteri già presenti sul dispositivo. Alcune impostazioni che riguardano le attività utente e le esperienze connesse possono bloccare il servizio quando sono esplicitamente impostate su Disabled.
| Policy | Verifica |
|---|---|
EnableActivityFeed | Non impostare su Disabled |
PublishUserActivities | Non impostare su Disabled |
UploadUserActivities | Non impostare su Disabled |
EnableCDP | Non impostare su Disabled |
AllowConnectedDevices | Non impostare su Disabled |
Non è necessario forzare tutte queste opzioni su Enabled: il controllo serve soprattutto a individuare conflitti con baseline di sicurezza, Group Policy o altri profili MDM. È disponibile anche il Policy CSP ./Device/Vendor/MSFT/Policy/Config/SettingsSync/EnableWindowsBackup, che accetta il valore stringa <enabled/>. In questa guida utilizziamo il Settings Catalog, quindi evitiamo di distribuire una seconda configurazione OMA-URI equivalente allo stesso gruppo di dispositivi.
Negli ambienti Hybrid Join controllate anche le Group Policy che riguardano Windows Backup ed ESR. Evitiamo di gestire la stessa funzionalità contemporaneamente con GPO e CSP: Microsoft segnala che la combinazione può produrre comportamenti inattesi.
Abilitare Windows Restore durante OOBE
Per mostrare il restore durante la configurazione iniziale di Windows dobbiamo intervenire nelle opzioni di enrollment del tenant, non nel profilo appena creato per il backup. Dal Microsoft Intune admin center apriamo Devices > Enrollment > Windows Backup and Restore nella scheda Windows e, sotto Enrollment options, impostiamo Show restore page su On, quindi salviamo.
Questa impostazione è tenant-wide: viene valutata durante i nuovi enrollment compatibili e non può essere assegnata a un singolo gruppo tramite il normale Settings Catalog. Prima di abilitarla in produzione controlliamo quindi gli utenti e i dispositivi che potrebbero incontrare la schermata; una modifica successiva, invece, non farà ripartire la OOBE sui dispositivi già configurati.
Con Windows Autopilot user-driven, dopo l’accesso con l’account aziendale Windows può proporre all’utente i profili salvati in precedenza, purché esista almeno un backup valido. L’utente sceglie il dispositivo da cui recuperare le preferenze oppure prosegue con una configurazione nuova. La semplice presenza dell’opzione Show restore page, senza un backup disponibile, non crea contenuti da ripristinare.
Se una schermata di restore non compare, controlliamo innanzitutto la build e il metodo Autopilot utilizzato. Soprattutto con immagini più datate, l’installazione degli aggiornamenti qualitativi durante la configurazione può fare la differenza, ma resta necessario rispettare il tipo di join previsto per il percorso OOBE.
Abilitare il restore al primo accesso
Dal 24 febbraio 2026 è disponibile in General Availability anche il first-sign-in restore, che può proporre il recupero delle impostazioni al primo accesso dell’utente dopo il completamento dell’enrollment. È utile quando la OOBE è già stata gestita dal provisioning, purché ci troviamo in uno degli scenari e nelle build supportate.
Per configurarlo torniamo in Devices > Manage devices > Configuration, creiamo un profilo Windows 10 and later / Settings catalog e lo chiamiamo, ad esempio, ENJ - Windows Settings Restore - First Sign-in. In Configuration settings cerchiamo Windows Backup and Restore > Enable Windows Restore, selezioniamo Enabled e assegniamo la policy ai dispositivi destinati a questo flusso.
Qui il momento di applicazione è decisivo: la policy deve arrivare in tempo per il primo accesso dopo l’enrollment. Se la distribuiamo a un dispositivo già utilizzato, non possiamo aspettarci che la schermata compaia retroattivamente; inoltre, quando l’utente sceglie espressamente di configurare il dispositivo come nuovo durante OOBE, Windows rispetta quella scelta e non ripropone automaticamente il restore al primo accesso.
Nel laboratorio utilizzo un profilo per il backup e uno per il first-sign-in restore, così posso distribuirli e monitorarli separatamente. Questa scelta facilita il troubleshooting, anche se le impostazioni potrebbero essere organizzate in un unico profilo quando l’assegnazione e il ciclo di vita sono gli stessi.
Verificare backup e restore
Lo stato Succeeded della policy Intune non basta per confermare che il backup funzioni. Prima di passare alla produzione controllerei che la configurazione sia arrivata al dispositivo, che il backup sia stato creato e che il restore recuperi effettivamente le impostazioni su un nuovo dispositivo compatibile.
Controlli dal portale Intune
Apriamo Devices > Manage devices > Configuration e selezioniamo il profilo di backup. Nel monitoraggio possiamo controllare dispositivi e utenti assegnati, ultimo check-in, impostazioni applicate ed eventuali errori o conflitti. Se abbiamo configurato il first-sign-in restore, ripetiamo la stessa verifica sulla relativa policy.
Per l’esperienza durante OOBE esiste un controllo aggiuntivo: apriamo il dispositivo Windows nel portale Intune e selezioniamo Enrollment, quindi cerchiamo il profilo Windows Backup and Restore. Il report può mostrare Succeeded, Failed, Not Applicable, No policy assigned, No Backup Profiles oppure Setup as New PC Selected.
Questi stati aiutano a distinguere un errore di restore dall’assenza di backup o dalla decisione dell’utente di configurare Windows come nuovo. Lo stato Succeeded di un normale profilo Settings Catalog, invece, conferma soltanto l’applicazione delle impostazioni MDM.
Controlli sul dispositivo Windows
Sul dispositivo sorgente apriamo Settings > Accounts > Windows backup e controlliamo che le categorie Remember my preferences e Remember my apps siano disponibili secondo le policy aziendali. Se l’amministratore non ha abilitato le relative funzionalità, i controlli possono essere disattivati o non modificabili. Quando necessario possiamo gestire in modo più granulare le categorie tramite le policy Windows Backup.
Apriamo quindi l’app Windows Backup, controlliamo le sezioni disponibili e avviamo un backup manuale. La procedura permette di osservare subito il risultato invece di attendere la pianificazione automatica.
Quando l’app segnala il completamento, annotiamo il momento dell’operazione; per chiudere davvero il test sarà comunque necessario verificare che quel profilo possa essere selezionato in un successivo restore.
Se qualcosa non torna, il report diagnostico MDM è un buon punto di partenza. Apriamo Settings > Accounts > Access work or school e utilizziamo, quando disponibile, Export your management log files; i risultati vengono normalmente salvati in C:\Users\Public\Documents\MDMDiagnostics. Nel laboratorio originale veniva generato MDMDiagReport.zip, che possiamo estrarre per aprire MDMDiagHTMLReport.html.
Nel report cerchiamo EnableWindowsBackup e le impostazioni collegate alla categoria SettingsSync, prestando attenzione ai valori effettivamente ricevuti dal client. Il report ci aiuta a individuare policy mancanti o in conflitto, ma non è una prova sufficiente dell’avvenuto salvataggio nel cloud.
Task Scheduler, registro ed Event Viewer
Durante i test originali ho verificato anche alcune evidenze lato Windows che possono tornare utili quando il portale Intune non spiega il problema. In Task Scheduler Library > Microsoft > Windows > CloudRestore erano presenti le attività Backup e Restore; il loro stato permetteva di osservare il comportamento del client durante i diversi passaggi.
Nello stesso laboratorio, dopo l’esecuzione del backup, ho rilevato il valore LastFullBackupCompletedTime in HKCU\Software\Microsoft\Windows\CurrentVersion\CloudStore\SystemMetaData, mentre CloudConfig era presente sotto HKCU\Software\Microsoft\Windows\CurrentVersion\CloudStore\Config. Sono dettagli utili per correlare il salvataggio alle attività dell’utente, soprattutto quando vogliamo confrontare il comportamento di due build diverse.
Non considererei però queste chiavi o i task come prerequisiti ufficiali: descrivono quanto osservato nei test e Microsoft non garantisce che nomi, percorsi e valori rimangano identici in ogni versione Windows. Non usateli quindi come unico criterio per decidere se il backup funziona.
Per completare il controllo possiamo aprire Event Viewer e cercare il canale Microsoft-Windows-CloudRestoreLauncher/Operational nei registri applicazioni e servizi. Nel laboratorio sono presenti eventi relativi ai processi di backup e restore, utili soprattutto per confrontare i timestamp con quelli del check-in MDM e dell’accesso dell’utente.
Se il restore si interrompe, confronterei l’orario del problema con gli eventi e con i report Intune, per capire in quale fase si è fermato il processo.
Esperienza utente durante Windows Restore
Quando il restore è disponibile, dopo l’autenticazione Windows mostra i profili di backup associati all’account aziendale. L’utente seleziona il dispositivo di origine e prosegue con Continue; se preferisce partire da una configurazione pulita può invece scegliere di configurare il dispositivo come nuovo, senza recuperare le impostazioni precedenti.
L’esperienza restituisce le preferenze previste dal catalogo Windows Backup e le informazioni sulle applicazioni Microsoft Store supportate. Documenti, applicazioni Win32, preferenze dei browser e configurazioni aziendali dipendono invece dalle altre soluzioni predisposte dall’organizzazione. Nel caso di un refresh gestito con Windows Autopilot, consiglio quindi di verificare l’intera sequenza fino alla disponibilità delle applicazioni necessarie, non soltanto la fine della schermata di restore.
Dopo il recupero può comparire un prompt UAC in alcune configurazioni del controllo account utente, ad esempio quando viene ripristinata l’impostazione Set time zone automatically. La FAQ Microsoft riporta questo comportamento: prima di considerarlo un’anomalia, controlliamo la policy UAC applicata e la modifica per la quale viene richiesta conferma.
Troubleshooting
Il backup non viene creato anche se la policy è Succeeded. Controlliamo la build Windows, il tipo di join, l’account utilizzato e le policy che possono impedire l’esecuzione del servizio; se possibile, proviamo un backup manuale dall’app, così distinguiamo un problema della pianificazione automatica da un errore del processo di salvataggio.
La pagina di restore non compare durante OOBE. Verifichiamo Show restore page a livello tenant, la presenza di un profilo di backup per l’utente, le build richieste e il percorso Windows Autopilot. In particolare, la modalità self-deploying non rientra nel restore OOBE documentato.
Il first-sign-in restore non viene proposto. Controlliamo la policy Enable Windows Restore e il momento in cui è arrivata al dispositivo. Se il primo accesso è già avvenuto o l’utente ha scelto di configurare Windows come nuovo durante OOBE, modificare l’assegnazione non farà necessariamente ricomparire la schermata. Negli scenari Hybrid Join teniamo conto delle differenze tra le pagine Microsoft e validiamo il percorso esatto di enrollment.
Il processo si ferma all’autenticazione. Alcune policy Conditional Access possono impedire di ottenere il token necessario per il servizio di restore. Se il problema compare soltanto in una VM Hyper-V con requisiti di phishing-resistant MFA, controlliamo anche la possibilità di usare una modalità di autenticazione compatibile durante il test, ad esempio un Temporary Access Pass quando consentito dalle regole aziendali. Non proporrei esclusioni Conditional Access generiche senza aver identificato l’applicazione e la policy coinvolte.
Il backup viene recuperato soltanto in parte. Controlliamo il catalogo delle impostazioni supportate, le categorie abilitate e le eventuali policy che sovrascrivono le preferenze al termine dell’enrollment. Per Edge servono i relativi meccanismi di sync; per i documenti verifichiamo la sincronizzazione OneDrive, che segue un flusso separato.
Considerazioni per gli ambienti aziendali
Prima di estendere Windows settings backup and restore, valutiamo anche il tipo di postazioni gestite. Su Azure Virtual Desktop non persistenti, ad esempio, il profilo dell’utente viene spesso conservato tramite FSLogix o un’altra soluzione di roaming e il restore delle impostazioni Windows aggiunge poco valore; senza persistenza, le preferenze recuperate rischiano invece di sparire alla chiusura della sessione. Microsoft consiglia di escludere da backup e restore anche i Windows 365 Flex shared Cloud PC, mentre il restore al primo accesso è previsto sui Cloud PC persistenti idonei.
Per la gestione amministrativa dei backup sono disponibili anche le API Microsoft Graph relative agli oggetti windowsSetting, ma gli endpoint consultati sono ancora in beta e non sono supportati per applicazioni di produzione. Le chiamate documentate utilizzano autorizzazioni delegate, tra cui UserWindowsSettings.Read.All per leggere le impostazioni di altri utenti e UserWindowsSettings.ReadWrite.All per eliminarle; il chiamante deve avere anche il ruolo Microsoft 365 Backup Administrator. State particolarmente attenti alla DELETE: l’operazione descritta elimina tutti gli oggetti windowsSetting dell’utente, non un profilo scelto singolarmente.
Se volete approfondire l’amministrazione dei profili, potete consultare il repository Microsoft Windows Backup Admin Scripts, verificando sempre la compatibilità degli script con le API attuali prima di eseguirli in un tenant di produzione.
Conclusioni
Windows settings backup and restore può rendere molto più semplice il passaggio a un nuovo dispositivo, a patto di preparare correttamente sia il backup sia il percorso di recupero. Personalmente partirei da un gruppo pilota, salverei le impostazioni su un dispositivo sorgente e farei un test completo su un nuovo Windows 11, verificando cosa viene effettivamente ripristinato dopo OOBE o al primo accesso.
La configurazione delle policy Intune richiede pochi passaggi; la parte più delicata rimane la compatibilità con il metodo di provisioning e con le impostazioni gestite dall’organizzazione. Per questo, durante il collaudo, confronterei lo stato del profilo Intune, la disponibilità del backup e il risultato ottenuto dall’utente, senza fermarmi al primo Succeeded nel portale.
Per documenti e applicazioni continueremo ad affiancare rispettivamente OneDrive Known Folder Move e la distribuzione software tramite Microsoft Intune, ottenendo così un processo di sostituzione più prevedibile anche nei refresh hardware su larga scala.
