Microsoft’s next major Windows 11 update—version 26H2—makes settings backup a managed recovery baseline and introduces Cloud rebuild for reinstalling Windows from the internet. But unless administrators explicitly exclude pooled virtual desktops, shared PCs, and kiosks, they could create more problems than they solve.
What’s Actually Changing
With 26H2, Windows settings backup evolves from a consumer convenience to a centrally managed capability integrated with Microsoft Intune and Autopilot. The feature, part of Microsoft’s broader Windows Resiliency Initiative, now lets IT pros control which devices participate, ensuring a consistent recovery experience for persistent, user-assigned endpoints.
Concurrently, Cloud rebuild enters public preview. Unlike Reset this PC, Cloud rebuild pulls a fresh Windows image and drivers from Windows Update, bypassing local recovery partitions and media. Once complete, the device goes through OOBE, and managed endpoints automatically reprovision via Autopilot, Intune, and Backup for Organizations. However, Microsoft stresses this is “for evaluation on non-production devices only.”
The backup itself is deliberately narrow in scope. According to Microsoft’s support documentation, it preserves only:
- Supported Windows settings (personalization, language, accessibility preferences)
- The Microsoft Store app list (not the apps themselves)
It does not back up user files, traditional Win32 applications, or application state. Those remain the domain of OneDrive, Intune app deployment, and third-party profile tools.
Why Endpoint Classification Matters Now
For IT teams, the first question isn’t “how to enable backup” but “which devices should never receive it.” A pooled virtual desktop that resets at logoff has no durable relationship with a single user; restoring settings onto such a machine is pointless and could confuse the user experience. Similarly, kiosks, labs, and shared Cloud PCs must return to a known managed state, not inherit a previous user’s preferences.
Here’s a straightforward breakdown:
| Endpoint Type | Backup & Restore Decision | Rationale |
|---|---|---|
| Persistently assigned laptop/desktop | Pilot and enable | Ongoing one-user relationship; replacement or rebuild scenarios benefit. |
| Persistent virtual desktop (assigned) | Pilot cautiously | Adds value only if it doesn’t conflict with existing profile management. |
| Pooled / non-persistent VDI | Explicitly exclude | Desktop is discarded; settings won’t persist. Use VDI personalization tools. |
| Shared Cloud PC or shared desktop | Explicitly exclude | Not a single-user target; consistency between sessions is the goal. |
| Kiosk, lab, training device | Explicitly exclude | Must return to a clean, predefined configuration. |
| Device slated for replacement/rebuild | Evaluate within pilot | Can be one piece of a migration, but not a full solution. |
Applying backup policy to the wrong endpoint class won’t cause data loss—user files are untouched—but it creates false expectations and wastes administrative effort when restored settings immediately disappear at next logoff.
How We Got Here
Microsoft’s push to make Windows recovery more cloud-aware began in earnest with the Windows Resiliency Initiative, announced in late 2024. The company pointed to increased cyberattacks and a desire for “self-healing” PCs. Features like Automatic Super Resolution and improved BitLocker recovery were part of the same wave.
Windows backup itself has been present since Windows 8, but it remained a consumer-oriented feature hidden in Settings. With 26H2, it gains enterprise policy hooks and links directly to the OOBE recovery flow—making it a meaningful piece of the Autopilot provisioning story. The Cloud rebuild feature, first shown to Insiders in early 2025, signals the endpoint: a world where a broken PC can be restored from the cloud without IT ever touching the device.
Yet this evolution creates the endpoint classification problem. In a rush to improve resilience, organizations might blanket-enable backup without considering whether a device even has a persistent identity. Microsoft’s own documentation and early adopter reports (as detailed in the Windows IT Pro Blog community discussions) emphasize that these tools supplement, not replace, existing data-protection and app-deployment systems.
What to Do Right Now
If you’re preparing for 26H2 or already testing Insider builds, take these concrete steps:
1. Inventory and Classify Every Managed Endpoint
Pull a full device list from Intune, Active Directory, and your VDI platform. Tag each device as persistent, non-persistent, shared, or special-purpose. Record the management owner and the business unit responsible. This classification is the control point—if you can’t explain why a device should retain user settings, exclude it.
2. Build Explicit Inclusion and Exclusion Groups
In Intune, create a pilot group containing only persistently assigned laptops and desktops. Build separate exclusion groups for pooled VDI, non-persistent desktops, shared Cloud PCs, kiosks, and labs. Groups should reflect lifecycle, not just hardware type—a virtual machine can be persistent or pooled.
3. Deploy Configuration Profiles Based on Device Class
- For Intune: Create a device-configuration profile that enables Windows settings backup only for the pilot group. Create a second profile that explicitly disables backup and restore for all exclusion groups. Assign policies to device groups, not user groups.
- For Group Policy: Designate security groups or OUs for persistent pilot devices and exclusion scopes. Configure the appropriate administrative template settings (“Turn off Windows backup and restore” or its equivalent) for excluded endpoints. Security-filter and link policies so no device receives conflicting configurations.
4. Validate and Pilot
Before broad rollout, confirm on sample devices that:
- Pilot devices show the intended backup behavior.
- Excluded devices receive the “disable” policy and do not offer backup or restore options.
- Users understand the limited recovery scope: settings and Store app list only; files from OneDrive; business apps from Intune.
5. Approach Cloud Rebuild With Caution
Cloud rebuild is a separate evaluation feature. If you test it:
- Use only non-production, persistently assigned devices.
- Verify the device has a compatible network driver in WinRE and can reach the internet (Ethernet or WPA2-Personal Wi-Fi).
- Confirm user files are protected by OneDrive (or another service) and that required Win32 apps can be redeployed post-recovery.
- At OOBE, validate that Autopilot and Intune components re-provision correctly.
Document gaps rigorously: missing files indicate a OneDrive shortfall, not a Cloud rebuild bug. Missing Win32 software is an app-deployment issue. Treat each layer of recovery as a separate tool.
Looking Ahead
Cloud rebuild is still in preview, but Microsoft plans to add remote initiation from Intune in a future release. That will transform it from a manual troubleshooting step into a remote-management weapon. Combined with settings backup, it sketches a future where a user’s personalization follows them to any assigned PC—provided the device is persistent.
For now, the rule is simple: if a desktop isn’t tied to a single user over time, keep backup off. As 26H2 approaches general availability, expect Microsoft to offer more polished policy templates and clearer guidance. But the fundamental decision—classify before you configure—remains in IT’s hands.