All that being said, I recently reinstalled Windows 10 using a USB drive created using Windows Media Creation Tool, and I STILL had to disable secure boot before I could install from it. So as far as I am concerned, MCT is no better than Rufus.
Probably NTFS Alternate Streams (mostly Zone.Identifier:$DATA for files downloaded from the Internet) getting lost if moving the file to FAT/FAT32/exFAT filesystems.
A very intelligent fast, easy, transparent https://forums.mydigitallife.net/th...2-0-and-secure-boot.84052/page-8#post-1699127
That's a nice way to do it indeed and I'm considering applying that to a future version of Rufus, since, even outside of speed considerations, I'm always striving to leave as much of the original content as unmodified as I can, since you never know when/if an OS vendor may start to add security validation on their content (which Microsoft could very well decide to do to prevent boot if they detect that boot.wim has been altered, though I don't really see them ever doing that on account of corporate customers). My only small problem with that is that I'll need to detect the arch of the ISO to create an unattend.xml with the proper processorArchitecture="###", otherwise it won't work (and yes, even if Microsoft does not currently provide ARM64 ISO downloads, it's anticipated that they might do so in the future, plus, since UUP allows the creation of ARM64 ISOs anyway, and users are bound to want to use those to install Windows 11 on ARM64 systems, I need to continue to ensure that I support ARM64 in Rufus). It's not a major problem, but it means that I can't apply the unattend.xml suggestion as is. Also, do you really need the empty UserData/ProductKey/Key section in your unattend.xml? It does seem superfluous... Finally, I have yet to see hard evidence that BypassCPUCheck does anything. From what I can see, it's only been suggested on forums such as MDL that such a key should exist, and as a result of this unsubstantiated suggestion, folks have started applying it in their utilities. But, unlike the other keys, noone seems to have hard evidence to confirm that they have been able to install Windows 11 on a system with this key, whereas it didn't work without. At any rate, since I kind of agree with Microsoft's RAM, CPU and Storage requirements for Windows 11 (incidentally, I had misread the minimum RAM requirement for Windows 11 to be 8 GB whereas it's actually 4 GB, which is indeed the bare minimum I'd suggest to have a semi decent experience with Windows), and I'd rather people avoid installing Windows 11 on systems where actual hardware constraints are likely to create issues in the long run, I'm only planning to apply TPM/SB bypass in future versions of Rufus, and leave people who need additional bypass, such as Storage or RAM, sort that out themselves...
Does it mean that you have tested with and without UserData/ProductKey/Key then? If you are carrying out tests, I still don't get why you can't provide a clear answer on that one, because it should be very simple to find out (which, again, I will do when I get to adding your solution to Rufus). That's actually why I asked you about it as I would expect you to be able to provide additional data about it, and whether that section is really needed or not (because it makes no sense to have it if it's not, and I also would expect that you'd be eager to adjust your proposal if it isn't). I'm quite puzzled as to why you don't seem to want to test your proposal to see if it can be improved further, and instead, seem to be stuck only on trying to put forward that whatever state your current proposal is is "the best". If UserData/ProductKey/Key can be removed then I don't see how the current proposal can be considered as the best, since it can clearly be improved on. And if UserData/ProductKey/Key cannot be removed then I would expect you to be able to indicate that you did test that this section is needed for your proposal to work. And that's actually part of what I'm complaining about with testing not being carried out by people who put proposals forward. Same here. And I don't expect you'll find many people who do... My problem is that I've not seen calls for "Can someone please try to validate whether ByPassCPUCheck is valid?" from people who have proposed it or people who seem to be eager to have this registry key added to the list. Instead what I've seen, precisely when asking if someone might be able to provide evidence as to whether this key work, is, and I quote: "it is up to you to test". Well, from the above, it appears that you are well aware that testing this does require having access to an extensive array of PCs (and therefore also having a lot of time on your hands) so, perhaps you may start to understand how one may seen that statement in context as quite disrespectful to make, or at least very dismissive of someone who is simply trying to challenge its validity. Sure, whatever floats your boat. I've only been saying that your solution is great for the very start, but that, as with any solution that is proposed in a specific context, and that has to be applied in a different one, there are some elements that may need fine tuning. Unfortunately, in stating so, I appear to have struck a nerve, so I guess I'll abstain for further comments on this proposal, especially if you're not interested in taking ownership of it by checking for yourself if UserData/ProductKey/Key is actually necessary.
That's because you're wrongly assuming a few things, that I have actually covered before: In my very first reply to you I stated that the only thing I was interested for Rufus were TPM/SB, as I agree with Microsoft's limitations for the rest (i.e Storage/RAM and CPU if CPU there is) and want to keep those in. Even outside of this, we had an extensive discussion about BypassCPUCheck needing further validation before I could consider it as a valid key (which I would still not apply in Rufus, even if valid). The screenshots you copy/pasted from Rufus very explicitly show that only TPM/SB are bypassed. This is not for lack of space. As a matter of fact, if you tested both versions, you might also notice that the RAM bypass, which explicitly appeared in 3.16 was removed from 3.17. This should tell you that the only items bypassed by Rufus in 3.16 were TPM/SB/RAM and that the only items bypassed in 3.17 are TPM/SB, and that the non-bypassed items are intentional Even outside of the screenshots, I also explicitly stated that I was planning to remove the RAM bypass for the next release, which is precisely what I did in 3.17. On top of this, you are also assuming that I'm using a VM for testing, which I don't in this specific case. Again, I have to remind you to be careful to assume that a solution that is being proposed for a specific context is going to apply to a different context. I have a specific design goal with Rufus, which I actually try to make quite explicit in the UI, and I am obviously testing in that context. So yeah, if you misread the context, you're going to find "issues" where none exist.
It exists depending on how far you see. First, you've added (otherwise great software) a new feature which in itself is not bad. But you chose one very wrong way of implementation, extract boot.wim, patch fail? a little primitive way. It reminds me of the timing of injecting a trojan into a *.dll file. Already when you entered those waters you could have chosen a more transparent way. It won't take long for you to appear on multiple virus lists as a dangerous tool, i don't believe that's what you aspired to. Second, you choose to patch only two limitations instead of all five, lightweight options. I’m not going to get into discussions about why at all, because the reasons are completely irrelevant. I know that most users need more if not all of them. There are no, or very few on this forum who can afford a new computer configuration with each new Windows update, however they would like to keep up to date with slightly older hardware configurations. So I find that all limits should be covered.