Posted in

Backup On, Restore Off: The 26H2 Default Your Fleet Just Inherited

by ailona•

A quiet default flipped in Windows 11 26H2: Windows settings backup is now enabled by default on eligible devices. Treat it as an operational change, not a feature rollout question, because it decides which devices are already sending user settings off-box, and what you must configure to make a refresh or reprovisioning actually restore those settings.

What’s changing

The technical change is simple and asymmetric: starting with Windows 11, version 26H2, Windows settings backup is enabled by default on eligible devices while restore remains disabled unless an admin explicitly enables it. The details, broken up:

  • Default asymmetry: backup turns on by default for eligible devices, and any existing administrator-configured policy (enabled or disabled) continues to be honored. Restore policy behavior is unchanged and still needs explicit configuration.
  • Eligibility: Microsoft Entra joined or Entra hybrid joined devices on the documented build floors; not available for GCCH/Sovereign clouds or China.
  • Policy surfaces: Intune Settings catalog (Administrative Templates\Windows Components\Sync your settings > Enable Windows Backup), Policy CSP ./Device/Vendor/MSFT/Policy/Config/SettingsSync/EnableWindowsbackup, and the matching GPO. Learn warns against mixing GPO and CSP for the same setting.
  • Data plane: the backup scheduled task runs every eight days, capturing user settings, preferences, and the Microsoft Store app list. Microsoft Graph beta windowsSetting APIs and the WindowsBackupAdmin PowerShell module expose backup data.
  • Timeline: the default-on behavior appeared in the 26H2 Insider Experimental channel in July 2026, and Microsoft updated the blog on September 29, 2026 to say the feature is now generally available on eligible devices.
  • ESR moved: starting July 2026, Enterprise State Roaming is managed through the Windows settings backup and restore surface instead of the Entra portal.

Why operators should care

This is an operational problem, not a feature debate. First, unconfigured fleets inherit backup=on — so devices you never touched may already be uploading settings on the eight-day schedule. Second, restore being off means neither the OOBE restore page nor the first sign-in after a refresh or reprovisioning repopulates those settings unless you enable restore policy explicitly; users and help desks will notice the mismatch and call you. Third, eligibility and cloud exclusions matter: only Entra-joined or hybrid-joined devices on the documented build floors are affected, so your audit must be scoped to join type and build number. Fourth, management moved: ESR admins who relied on the Entra portal need to update runbooks to the new Windows Backup for Organizations/Windows settings backup and restore surface. Finally, there’s a governance and data-egress vector. Backups include the list of Microsoft Store apps and user preferences and can be accessed via Microsoft Graph beta windowsSetting APIs or the WindowsBackupAdmin PowerShell module; you need to decide retention, access control, and deletion procedures before backups accumulate as part of refresh workflows. Note: explicitly configured policies (enabled or disabled) are honored, so audited exceptions remain effective.

“Starting with Windows 11, version 26H2, Windows settings backup will be enabled by default for eligible devices. Any existing administrator-configured policy (enabled or disabled) will continue to be honored.”

The missed signal

Most commentary treats this as a convenience shift; the harder-to-see signal is the asymmetry and its timing relative to refresh waves. Backup-on-by-default creates a standing data export from devices you may not have intended to back up, while restore-off-by-default leaves users without the expected payoff during provisioning. That asymmetry raises immediate operational decisions: decide whether you want settings flowing off-box before you have restore policies, update privacy/change-management communications, and adjust your refresh runbooks to either enable restore or suppress backups for specific OUs or device cohorts. The management surface move compounds this — admins may be looking in the wrong portal when the first support tickets arrive.

Restore is two policies, not one

Learn splits restore into two configuration surfaces, and fleets that pick the wrong one end up wondering why the restore page never shows.

  • OOBE restore (tenant enrollment policy): Intune admin center > Devices > Enrollment > Windows Backup and Restore > Show restore page, or the ./Device/Vendor/MSFT/WindowsBackupAndRestore/EnableWindowsRestore CSP in your onboarding provisioning XML. It is tenant-wide and applies only at enrollment, so changes never reach already-enrolled devices; it requires Entra joined, and where Autopilot is used the profile must be user-driven, not self-deploying. This policy isn’t available in GPO.
  • Post-enrollment restore (device configuration): Settings catalog (Windows Backup And Restore > Enable Windows Restore), the same WindowsBackupAndRestore CSP, or the Enable Windows Restore GPO under Sync your settings. First sign-in after enrollment requires 24H2/25H2 devices on the February 2026 build floors (26100.7922 / 26200.7922 or later) and works on Entra joined or hybrid joined devices.

Two silent-failure checks before you call policy “on”: backup does not run at all if EnableActivityFeed, PublishUserActivities, or UploadUserActivities (Computer Configuration > Administrative Templates > System > OS Policies), EnableCDP, or AllowConnectedDevices are set to Disabled. And Conditional Access can block the restore flow with a “You don’t have access to this” error; the fix is a custom policy that allows the Microsoft service with app id d32c68ad-72d2-4acb-a0c7-46bb2cf93873.

What to do next

Operational recommendations:

  • Audit current policy state for EnableWindowsbackup across GPO and Intune (use the Intune Settings catalog and check the Policy CSP SettingsSync/EnableWindowsbackup). Unconfigured targets inherit the new default.
  • Inventory affected devices by join type and build floor (Entra joined/Entra hybrid joined and the documented build numbers); exclude GCCH/Sovereign/China per the documentation.
  • Decide and apply an explicit restore stance on the right surface: the tenant enrollment policy (Show restore page / WindowsBackupAndRestore CSP) for OOBE on Entra-joined, user-driven Autopilot devices, or the post-enrollment Enable Windows Restore policy (Settings catalog, CSP, or GPO) for first sign-in after a refresh. Leaving restore off is a valid stance; configuring the wrong surface is why the restore page never appears.
  • Review backup contents and lifecycle: use Microsoft Graph beta windowsSetting APIs or the WindowsBackupAdmin PowerShell module to enumerate, export, and delete backups as needed to meet privacy and retention rules.
  • Update runbooks and admin portals: move ESR management knowledge from the Entra portal to the Windows Backup for Organizations / Windows settings backup and restore surface and train support staff on the eight-day backup cadence to set user expectations.

For each step above, map the work back to the documented controls: Intune Settings catalog / Policy CSP, the GPO path, Graph windowsSetting APIs, and the WindowsBackupAdmin module. Implementing these now prevents a wave of avoidable tickets and governance gaps when 26H2 refreshes reach your fleet. For how 26H2 itself lands on 24H2 and 25H2 machines as an enablement package, see our 26H2 breakdown; this post is about the settings-backup default it inherits.

Sources

As an Amazon Associate I earn from qualifying purchases. Links on this site may be affiliate links.