We recently completed a long-planned migration from Windows 10 to Windows 11. The administrator downloaded what was labeled as the latest ISO and used it across the fleet, only to discover afterward that it was Windows 11 version 26H1. The deployment itself succeeded, but our internal update service is now looking for updates that do not appear to exist for these systems.
The confusing part is that 26H1 is associated with a different Windows core and was primarily intended for specific hardware, although an x64 build apparently installs and runs on Intel and AMD systems. The proposed fix is to edit cversion.ini and force an in-place upgrade to 26H2, but that seems unlikely to work across different servicing branches. Has anyone dealt with this situation? Is rollback possible, or should we plan to reimage the affected machines?
3 Answers
The bigger failure was the deployment process: no test machine, no pilot group, and no validation of the ISO before pushing it everywhere. First contain the rollout, stop further changes, inventory which systems were upgraded versus clean-installed, and preserve user data. Then use the rollback window where available and schedule reimaging for the rest. A staged deployment ring and a requirement to verify the image source and build would prevent one mislabeled ISO from reaching the entire fleet.
The installation succeeding does not necessarily mean the deployment is supported. There is an x64 26H1 build, so it can boot and install on Intel and AMD hardware even though the release is associated with a different hardware direction. The immediate WSUS problem may be a product or classification issue rather than proof that the clients are completely unable to receive updates. Some x64 updates may be listed under an Insider or pre-release product category, so check whether that category is synchronized before assuming there are no updates at all. Even so, I would treat this as a temporary state and plan a move back to the normal supported branch rather than relying on it long term.
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 the machines were upgraded in place and are still within the uninstall window, check the rollback status with DISM and roll them back to the previous installation. Extend the uninstall window on systems that have not been touched yet if necessary. Machines outside that window, or machines that were clean-installed, will most likely need to be reimaged with the supported Windows 11 release. There does not appear to be a supported downgrade path from 26H1 to 26H2.
The important distinction is that 26H2 is not simply a newer build that can be applied over 26H1. They are based on different code branches, so an enablement package intended for the normal release branch is not expected to apply to a 26H1 installation.
The vendor’s guidance indicates that 26H1 cannot take the next regular annual feature update because of the different core. It may have a future upgrade route, but waiting for that is a poor fleet strategy if these machines are outside the supported configuration.