>Windows cannot parse the provided command line options
I got the same behavior on one that had W10 22H2.
But got a more descriptive error message [/product not a recognized switch].
To fix this, had to replace the setup.exe file that is now provided with the 25H2 ISO. The current setup.exe now appears to be badly lobotomized by a decision-maker who has got to be equally brainless (less-brainful?) compared to how it was before.
Using setup.exe from the 23H2 ISO seems to be a workaround for this next annoying decline in Windows 11 suitability for industrial and sensitive enterprise applications. If I said it was like the "canary in the coal mine" some would say I was exaggerating because it is too late for that and there have been earlier warning signs for years. Not much like the tweety bird who thought he saw a puddy cat, more like the chicken on the dinner table now, or a goose who is more than fully "cooked".
Going further, it's also good to prevent the "surprise" data loss, when you are using a local "account" and not on line at all, which threat only comes from Microsoft itself with their auto-bitlocker encrypting your whole drive more aggressively on new installs like never before, the result can be worse than many types of malware/ransomware. To prevent that you need to interrupt the first boot after the upgrade files are copied, and boot instead to the Recovery Console or alternatively a separate Windows install so you can do an offline Regedit creation of a new DWORD in the target Windows\System32\Config\SYSTEM hive being upgraded; adding \HKLM\system\ControlSetXXX\Control\BitLocker\PreventDeviceEncryption, then setting value=1. This needs to be done carefully and some renaming in Regedit can be involved.
Unfortunately, even if this Registry setting preventing encryption has been previously set=1 before this type upgrade, that PreventDeviceEncryption DWORD is completely removed by this setup process. Which is why I go a little further and check manually, replacing it if necessary.
Then on the second reboot, the DWORD needs replacement again, so repeat the above process :\
Allowing you to re-live the experience as only malware-type persistence can ;)
After that when you reboot back to the target volume being upgraded (rather than the alternate utility bootmedia), the W11 setup process will proceed without encrypting. Otherwise it can be very likely to encrypt everything it has access to and it's not intended to be recoverable without a Microsoft account. Even with a Microsoft account I don't trust this, seems like the opposite of "trustworthy computing" to me :\
Anyway with that in mind the command line does perform as expected and took this PC from W10 pro 22H2 to W11 pro 25H2, preserving my installed programs and files as far as I can tell. And this is on an MBR-booting PC where Windows 10 was installed to an MBR partition, using legacy CSM with UEFI disabled. No GPT, no EFI folder, none of that.
In W10, was only using the first 64GB of a HDD as NTFS, with the remainder unallocated. My Recovery folder (containing winre.wim) was intentionally the one on the same volume as Windows 10. This direct W11 upgrade created a new 750mb type 27 ("hidden" recovery) partition immediately following the 64GB. With the new 750mb containing its new Recovery folder.
If there would not have been enough unallocated space on the drive, I believe the upgrade process would have replaced the W10 winre.wim in my C:\Recovery folder with the W11 version? Not sure at this point, but C:\Recovery\WindowsRE still contains the previous W10 winre.wim, and the new recovery partition contains the W11 winre.wim.
Edit: found a recent article documenting bitlocker problems that might be related, look at the comments:
I got the same behavior on one that had W10 22H2.
But got a more descriptive error message [/product not a recognized switch].
To fix this, had to replace the setup.exe file that is now provided with the 25H2 ISO. The current setup.exe now appears to be badly lobotomized by a decision-maker who has got to be equally brainless (less-brainful?) compared to how it was before.
Using setup.exe from the 23H2 ISO seems to be a workaround for this next annoying decline in Windows 11 suitability for industrial and sensitive enterprise applications. If I said it was like the "canary in the coal mine" some would say I was exaggerating because it is too late for that and there have been earlier warning signs for years. Not much like the tweety bird who thought he saw a puddy cat, more like the chicken on the dinner table now, or a goose who is more than fully "cooked".
Going further, it's also good to prevent the "surprise" data loss, when you are using a local "account" and not on line at all, which threat only comes from Microsoft itself with their auto-bitlocker encrypting your whole drive more aggressively on new installs like never before, the result can be worse than many types of malware/ransomware. To prevent that you need to interrupt the first boot after the upgrade files are copied, and boot instead to the Recovery Console or alternatively a separate Windows install so you can do an offline Regedit creation of a new DWORD in the target Windows\System32\Config\SYSTEM hive being upgraded; adding \HKLM\system\ControlSetXXX\Control\BitLocker\PreventDeviceEncryption, then setting value=1. This needs to be done carefully and some renaming in Regedit can be involved.
Unfortunately, even if this Registry setting preventing encryption has been previously set=1 before this type upgrade, that PreventDeviceEncryption DWORD is completely removed by this setup process. Which is why I go a little further and check manually, replacing it if necessary.
Then on the second reboot, the DWORD needs replacement again, so repeat the above process :\
Allowing you to re-live the experience as only malware-type persistence can ;)
After that when you reboot back to the target volume being upgraded (rather than the alternate utility bootmedia), the W11 setup process will proceed without encrypting. Otherwise it can be very likely to encrypt everything it has access to and it's not intended to be recoverable without a Microsoft account. Even with a Microsoft account I don't trust this, seems like the opposite of "trustworthy computing" to me :\
Anyway with that in mind the command line does perform as expected and took this PC from W10 pro 22H2 to W11 pro 25H2, preserving my installed programs and files as far as I can tell. And this is on an MBR-booting PC where Windows 10 was installed to an MBR partition, using legacy CSM with UEFI disabled. No GPT, no EFI folder, none of that.
In W10, was only using the first 64GB of a HDD as NTFS, with the remainder unallocated. My Recovery folder (containing winre.wim) was intentionally the one on the same volume as Windows 10. This direct W11 upgrade created a new 750mb type 27 ("hidden" recovery) partition immediately following the 64GB. With the new 750mb containing its new Recovery folder.
If there would not have been enough unallocated space on the drive, I believe the upgrade process would have replaced the W10 winre.wim in my C:\Recovery folder with the W11 version? Not sure at this point, but C:\Recovery\WindowsRE still contains the previous W10 winre.wim, and the new recovery partition contains the W11 winre.wim.
Edit: found a recent article documenting bitlocker problems that might be related, look at the comments:
https://www.guru3d.com/story/windows-11-25h2-update-causes-u...