I'm looking for advice after a fleet-wide Windows upgrade went wrong. A senior administrator was tasked with moving our systems from Windows 10 to Windows 11, downloaded an ISO labeled as the latest release, and used it across the environment without first validating it on a test machine or pilot group. The systems installed successfully, but our internal WSUS server is now looking for updates that do not appear to exist.
We eventually discovered that the deployment used Windows 11 version 26H1, which is based on a different Windows core and has a separate servicing path from 24H2, 25H2, and the upcoming 26H2 release. The x64 build can install on Intel and AMD systems, despite the release being associated with ARM-focused devices, so the machines are running—but the upgrade path is unclear.
The proposed fix is to modify cversion.ini and force an in-place upgrade to 26H2. I'm skeptical that this will work because 26H2 is based on a different codebase and may actually have a lower build number. Has anyone dealt with this situation? Is rollback possible, or should we plan to reimage the affected systems?
4 Answers
The WSUS behavior may not mean the systems are unusable. The x64 26H1 build does exist and can boot on ordinary Intel and AMD hardware; it is not simply an ARM-only image that must fail during installation. However, its servicing and upgrade path differs from the normal desktop releases. Some applicable updates may be classified under an Insider or pre-release product category, so WSUS may not be synchronizing what those clients need. Verify the exact build and edition with winver or DISM, then check the WSUS product and classification settings before concluding that every update is missing.
I would not count on a 26H2 enablement package fixing this. Enablement packages normally work within the intended servicing base; they are not general-purpose downgrades or cross-core migrations. If the systems are outside the uninstall window, reimage them with the supported release rather than relying on an unsupported hack and hoping a later update repairs the installation.
Don’t spend the weekend trying to force this with cversion.ini. That file can bypass some media compatibility checks, but it cannot make Setup migrate between different Windows cores or servicing branches. If these were in-place upgrades and Windows.old is still available, check the uninstall window with DISM /Online /Get-OSUninstallWindow and roll them back immediately. You can extend the window on untouched systems with DISM /Online /Set-OSUninstallWindow /Value:60. Once the rollback window has expired, the supported answer is generally to reimage to the normal 25H2 release and restore the user data and applications.
If the machines were clean-installed or the rollback files have already been removed, assume reimaging is required. I’d stop experimenting on production devices and preserve one affected machine for testing and documentation.
The bigger failure was the deployment process, not just the ISO. Any OS image should be checked for source, architecture, build, licensing channel, and support status before it reaches production. A safer recovery plan is to stop the rollout, identify whether each machine can still roll back, test the rollback or reimage process on a representative sample, and then use a task sequence or automated provisioning to handle the rest. Make sure user profiles, encryption keys, application settings, and recovery data are covered before wiping anything.
Even if security updates are available, that doesn’t solve the feature-upgrade problem. Microsoft’s stated guidance is that 26H1 will not move directly to the next annual release and will instead receive a future upgrade path, so I wouldn’t leave a large production fleet on it indefinitely.