Closed gadgetboyj closed 2 years ago
I have experimented with the autounattended.xml - based tpm bypass,
but it has it's drawbacks and needs another workaround to alleviate this unwanted behavior
mean time, you have auto.cmd
there to run auto upgrades
next script update is gonna introduce yet another way to tpm bypass - the proper way coming tommorow
@AveYo I downloaded MCT today to upgrade to Win 11, and it wiped out all my files, installed apps, settings, etc. like I had just done a clean OS install. Is this the intended behavior?
I'm trying to restore my last backup to go back to Win10 right now, but it would be good to know, in the future is there a way to use this to upgrade to Win11 WITHOUT losing everything?
Update: Successfully restored my backup, thankfully, since I use this pc for work. Reading through some comments on the old MCT gist, I understand that files and apps should not be affected.
Could you please give some clear instruction on how to do this? Do we use auto.cmd? Should we use a previous, more stable version of MCT?
(Also, is it possible to use the system Windows Update with the TPM bypass? I've added the AllowUpgradesWithUnsupportedTPMOrCPU
Registry key, and I've downloaded and run "no_11_setup_checks_on_dynamic_update.cmd". Still, my Windows Update says, "This PC currently doesn't meet all the requirements for Windows 11". Am I missing something?)
Es mejor que sea instalación limpia para evitar errores.
you could have used auto.cmd
to run the windows setup, not the wrong winpe boot one
I have moved autounattended.xml
from the root of the created media because it was causing this unwanted effect
I'm also not content with 11 and any of the existing TPM bypasses - each have a shortcoming That's the reason I haven't updated in a long while. Will soon make yet another attempt
you could have used
auto.cmd
to run the windows setup, not the wrong winpe boot one
How are users supposed to know the winpe one is "wrong"? So auto.cmd will preserve files and installed apps?
each have a shortcoming
That's interesting. Are you able to summarize what they are, and what method MCT currently uses?
Well, now that's not an issue anymore. Tho the winpe one is the same as the setup you get when booting from media (just like running sources\setup in windows). No upgrade support, and you can only do clean installs, it takes you to partitioning so that's implicitly a red herring.
As for bypasses, MCT currently uses:
winsetup.dll patch inside boot.wim to remove all setup checks
launching setup.exe directly, will not bypass checks
must instead run setup via auto.cmd to bypass checks via /product launch option
So out of curiosity, what's the shortcoming of the current method?
So out of curiosity, what's the shortcoming of the current method?
For clean installs from boot, my original method to patch winsetup.dll
does not have any drawbacks
(other than enabling install on unqualified hardware which is the whole point)
For upgrades under windows, Setup searches "DU for sources" update with the wrong product type (server instead of client) so it will not found any. The whole point of "DU for sources" updates is to address compatibility issues (often by simply blocking the upgrade). So I guess it's a small price to pay when the machine does not have TPM or Secure-Boot so it's already hard-blocked. Tho for machines that are not hard-blocked, this potentially misses out on some soft-block fixes (like a workaround for a driver or software that otherwise would make the upgrade fail) Plus the cosmetic Installing Windows Server..
If upgrade to 11 fails regardless of bypass method used, you might want to first setup 10 (aka in-place upgrade / repair), preferably 21H2, to overcome any software compatibility. Afterwards retry 11 upgrade (should be faster from a 10 21H2 build and with higher chances of success)
As of the latest commit, it seems that the MCT is creating a slightly different ISO. The setup.exe from this ISO launches full screen, and doesn't provide any options to upgrade to Windows 11, it asks you to select an edition, and then a drive/partition to install to, similar to when you boot from the installer. No option is given to keep files/apps.
I confirmed that the previous commit from 10/20 does not have this issue, I was able to run it and the MCT created an ISO that worked without issue for an upgrade.