Windows Server 2025 QMR: Enable Automatic Boot Recovery with KB5126646

Installing the update gives you the feature. It does not switch it on. QMR stays off on Server until you configure it.

What shipped, and where​

Microsoft's release notes for the October 13, 2026 update, KB5126646 (OS Build 26100.33650), apply to Windows Server 2025, all editions. They mark the feature as new and say that Quick machine recovery is now supported on Windows Server 2025. According to Microsoft, during outages, Quick machine recovery helps recover devices from critical boot failures by using Windows Recovery Environment (WinRE) to find and apply targeted remediations from Windows Update.

Three details from those notes matter most:

• It's off by default. The feature is disabled by default on Windows Server 2025 editions.
• You turn it on with Group Policy. Administrators can enable the feature through Group Policy to support streamlined recovery during widespread outages and reduce the need for manual intervention.
• It can only apply fixes that exist. Recovery depends on an applicable remediation being available.

Neowin, which reported the arrival, says QMR was announced almost two years ago. It also reports that Microsoft started testing it in Windows Server back in July 2026, ahead of this release. The French site IT-Connect describes the feature as a recovery feature, already available on Windows 11, is now arriving on Windows Server 2025.

Microsoft's Group Policy guide for the feature sets a firm version boundary. You need Windows Server 2025 with the October 2026 security update or later. The guide doesn't apply to Windows clients or to other Windows Server versions. Server 2022 and earlier don't get QMR.

Summary: KB5126646 or a later cumulative update brings QMR to Server 2025. Nothing changes on your servers until you enable it.

How QMR works​

QMR builds on Startup Repair, the tool that has tried to fix unbootable Windows systems for years. Microsoft's QMR overview describes the sequence:

1. Device crash. The machine fails to boot several times and Windows detects the problem.
2. Boot to recovery. The system starts in WinRE.
3. Network connection. WinRE gets online and checks Windows Update for a remediation.
4. Remediation. If a fix exists, WinRE downloads and applies it. If not, the system either hands off to the usual recovery options or retries on a schedule you set.
5. Restart. If the fix works, Windows boots. If not, the machine goes back to WinRE and the cycle starts again.

The overview describes two main controls:

• Cloud remediation lets WinRE fetch fixes from Windows Update. When it's disabled, Windows falls back to Startup Repair.
• Auto remediation controls whether that check happens automatically. Without it, someone has to step in and start the search by hand.

Microsoft's overview also lists Windows Server 2025 edition devices among the systems where cloud remediation is off by default. Windows Enterprise and Education devices, and Pro devices joined to a domain, are on the same list. Unmanaged Home and Pro PCs are the reverse: the feature is on out of the box.

Enabling QMR on a single server​

Microsoft's Windows Server guide gives this procedure for a standalone machine:

1. Sign in to the Windows Server 2025 machine as an administrator.
2. Run gpedit.msc to open Local Group Policy Editor.
3. Go to Computer Configuration > Administrative Templates > System > Quick Machine Recovery.
4. Open Enable Cloud Remediation, select Enabled, then Apply and OK.
5. Open Enable Auto Remediation, select Enabled, then Apply and OK. Microsoft says these two settings together are the configuration used in its Server validation procedure.
6. Set Set Recovery Retry Interval and Set Total Recovery Wait Time to suit your environment (details below).
7. Close the editor, refresh policy and check the result.

These are computer settings, not user settings, so you don't need loopback processing.

Retry timing for servers with no console​

The two timing settings decide whether a server gets one attempt or several:

Microsoft specifically mentions headless servers. Set the retry interval above zero and the server can try again during the total wait window. Leave it at zero and you get one attempt per wait period, which can mean waiting longer for a fix. If a fix appears an hour after a single failed check, a server with retries turned off won't pick it up. This is my own reading, not Microsoft's guidance, but racked machines that nobody watches should probably have retries enabled.

Rolling it out across a domain​

For domain-joined servers, Microsoft recommends a dedicated GPO. Its suggested name is "Windows Server 2025 - Quick Machine Recovery". The steps:

1. In Group Policy Management, create the GPO under Group Policy Objects.
2. Edit it and go to the same Quick Machine Recovery node.
3. Set Enable Cloud Remediation and Enable Auto Remediation to Enabled.
4. Link the GPO to the OU that holds the target Server 2025 computer accounts. If that OU also holds other operating systems, narrow the GPO's scope first.
5. Refresh policy on a pilot server and confirm both the applied GPO and the effective settings.
6. Check the pilot results before you widen the rollout, and resolve any conflicting policies through your normal process.

Checking that it worked​

Run these from an elevated command prompt:

• gpresult /scope computer /r shows whether the policy applied.
• reagentc /getrecoverysettings shows the recovery configuration that's actually in effect.
• gpupdate /force processes policy immediately instead of waiting for the next refresh.

Turning it off properly​

Microsoft's guide warns that Not Configured doesn't turn the feature off. It hands control back to local recovery settings or the edition default. To block cloud remediation, set Enable Cloud Remediation to Disabled. To also stop local remediation packages from applying automatically, set Enable Auto Remediation to Disabled. If your change-control process needs a guaranteed "off", use Disabled.

Summary: Use a dedicated GPO, start with a pilot group, verify with reagentc, and use Disabled rather than Not Configured to switch it off.

Limits to know before you rely on it​

Microsoft's own documentation lists several caveats that matter for planning:

• It's best-effort. Microsoft may not have released a fix for a particular failure, or the fix may not apply to your server.
• WSUS doesn't supply fixes. Microsoft's troubleshooting table says not to assume WSUS or an offline update source provides QMR remediations, because the Server design relies only on Windows Update. Shops that keep their servers away from the internet and use internal update infrastructure need to check that WinRE can reach the required services. Otherwise QMR will boot into recovery with nothing to download.
• Networking is limited. The QMR overview says only wired networks and WPA/WPA2 password-based Wi-Fi are currently supported. That's fine for most servers, but check how recovery-time traffic gets out of your network.
• WinRE has to work. No working recovery environment means no QMR. Check reagentc status on your fleet before you trust the feature.
• Servers can't use test mode yet. The overview says QMR's simulated-crash test mode is currently limited to Windows client devices in the Windows Insider Program's Experimental channel. Server admins can't rehearse a recovery that way yet.

If you open a support case, Microsoft asks for the server edition and build, installed update details, policy states, gpresult output, reagentc /getrecoverysettings output, and recovery logs and timing from any controlled test. Check those files for credentials before you send them.

Neowin's coverage says enabling QMR should cut outage recovery time and reduce dependence on IT staff. Microsoft's wording is more cautious: these are aims, not guarantees. QMR is a useful extra layer for the kind of mass boot failure that has hit the industry before. It doesn't replace backups, out-of-band management or a tested disaster-recovery plan.

Other changes in the same update​

KB5126646 includes more than QMR. Microsoft's notes list auditing and optional policy controls for ReFS volumes on externally attached storage, with auditing on by default. They also list cURL included with Windows to version 8.21.0, ML-KEM post-quantum key exchange for TLS 1.3, better reliability for Intel TDX confidential VMs in Hyper-V, a Storage Spaces Direct fix for virtual disks that stayed offline, a security update to the emoji search libraries, and a stricter NTLMv1 default for SSO. Separately, IT-Connect reports that member servers can now set up Netlogon secure channels with domain controllers deployed before Windows Server 2025.

The update also has a known problem with on-premises Exchange. As WindowsForum's earlier coverage explained, Microsoft says affected Exchange servers on Windows Server 2016–2025 can be temporarily stabilized by setting EpmapSavedContextCap to 65536 and rebooting; keep October updates installed. If you run Exchange, apply that workaround before you start piloting QMR.

Bottom line​

QMR on Windows Server 2025 is a real, if limited, addition to recovery planning. If KB5126646 or later is installed, here's what to do:

1. Confirm WinRE works on your servers.
2. Check that the recovery environment can reach Windows Update (WSUS won't supply fixes).
3. Enable both remediation settings through a dedicated, tightly scoped GPO on a pilot group.
4. Set a retry interval above zero for headless machines.
5. Use Disabled, not Not Configured, wherever policy requires the feature to be off.

QMR can only apply a fix that Microsoft has actually published. If you've rolled it out, or run into trouble with the Exchange workaround, share your experience in the Windows Server and Group Policy discussions on the forum.