That makes two of us. So let's me spell this out for you: Do you really think I have any interest in providing software that helps people install Windows versions that they don't have a legal license or product key for? Unless you want to encourage piracy (and get into serious legal trouble as a result -- as a matter of fact, I would expect MDL moderators to understand that the publishing of unofficial license keys on a forum is exceedingly problematic), you can't go around and pre-populate installation keys in your software. Or was that key you're advising people to use officially given to you by Microsoft? Ergo, it should be obvious that software like Rufus, which is not and will never be designed to facilitate OS piracy, has no use for a product key section. Instead, it very much wants to let users of the media that it creates sort out the licensing/activation issues for themselves, which Windows nicely allows you to do post installation, making even the addition of a feature, that would pre-populate a license key according to one that the user may provide, completely useless in Rufus. Ergo, you are still completely missing the context. And I will add that, if your attitude is that everybody should be "entitled" to install any Windows version that they please, without going through the official licensing/activation mechanisms, I really don't want to talk to you any more, because it's clear we have irrevocably opposed approaches to what we want installation media to accomplish. Bypassing restrictions has no impact on licensing (and considering the manner in which is it being enacted, I'm not aware of any legal terms, from the Windows 11 license, that can be construed as forbidding it. Especially, the bypassing of Secure Boot or TPM can not be equated as DRM circumvention, since, if any DRM that is tied to TPM/SB will obviously not launch if it detects that these are missing, and the fact that we are using registry keys that were devised by the software manufacturer in the first place, makes it even less of a concern), so that's fair game. Pre-populating a license key, unless that key has been officially publicised by the software manufacturer, isn't.
Again, considering that Windows 11, like Windows 10, allows the provision of a license keys either during or after installation, there is literally no point for Rufus to pre-populate a license key, be it legally obtained or not, in autounattend.xml. Please try to understand that what applies to one context, in terms of autounattend.xml, may not apply to a different context. That's actually why Microsoft only provides guidelines on what an autounattend.xml may contain, and how one can generate one according to their specific needs, rather than a one-size-fits-all XML that everybody should use...
Isn't that what the default Retail keys (provided by Microsoft in product.ini) or the GVLK (provided by Microsoft for Volume media) can be used for? They are officially provided by Microsoft and are completely legal to use. Default Retail keys allow installation of non-Volume OS. Automatic activation will occur if, and only if the hardware has been associated to with a digital activation (StoreLicense) before. In any other case, OS is in Notification mode and the correct key can be entered later GVLKs allow installation of a Volume OS. Automatic activation would occur only, if the corporation provides a KMS server in the Enterprise LAN that can be auto-discovered. Otherwise, OS is in Notification mode. Both methods are completely legal (actually, Consumer ISOs from MS contain the Default Retail keys and Business ISOs contain the GVLKs), and the keys are generic and publicly available.
Exactly everything you said, but since the installation is solved by the > IXMAS < key, I prefer this for public use
Sigh. I can't believe I have to repeat myself one more time, so let me talk about context once again. The context of the provision of a license key in Rufus for the installation of Windows 11 is exactly the same as the context of providing a license key in Rufus for the installation of Windows 10. There has not been a single justification that the provision of a license key in an autounattend.xml was ever necessary for the installation of Windows 10, or, at least, I have never ever received a request that Rufus should add one or a hint that it might be useful to add one, and I therefore expect the same for Windows 11 especially as, when I tested the official 22483 ISO from Microsoft, I did not see any issue with not providing a key and got to the usual "I don't have a key" screen after which one can select the edition of Windows they wish to install. So, first of all, I'm going to dispute @IXMas's statement that "for Windows 11 22483.xxx it is necessary to enter the key". That is simply not what I have been seeing. And again, my question with regards to autounattend.xml, which is devised for the bypassing of the restriction (and yes, adding registry keys to a mounted wim image is perfectly legal, especially when these keys have been devised to be checked at boot time by the OS manufacturer, but hey, feel free to fling FUD around in the same manner as you wanted to throw FUD about Rufus behaving like a virus) is whether, in the context of bypassing the restriction, the provision of a key section (which used to be empty when first proposed and then somehow was attempted to be justified by populating with something) is necessary. I think it is very obvious that, unless someone has contrary evidence they want to put forward, in that context, the answer is no. You do not need a UserData/ProductKey/Key section if all you want from autounattend.xml is to bypass the installation restrictions. And therefore, since I wasn't providing an autounattend.xml with a UserData/ProductKey/Key section in Rufus, for the installation of Windows 10, I fail to see why, when questioning whether it is necessary, all I am being met with is a "But you should use one" instead of an answer to whether this section can be bypassed altogether if not necessary. That was, and has always been the extent of my questioning the need for this section. But of course, now this whole thing appear to somehow have morphed into an "Is UserData/ProductKey/Key ever useful?", as if I was somehow arguing for the contrary argument (which I am not), so I have to restate that, if it had no use for the installation of Windows 10 in the context of Rufus, is unlikely to have one for the installation of Windows 11, unless one can demonstrate a <RunSynchronous> section will not work unless a <ProductKey> section is also provided. So that is the extent of my concern with the UserData/ProductKey/Key section (that is, as long as I am not seeing keys floating around that I can't find the origin of online), and there's really only so much patience I have for people who are, either willingly or unwillingly, trying to distort a context, that they should easily be able to logically derive for themselves, i.e. If Rufus didn't use an autounattend.xml for Windows 10, then it would make little sense for it to use one with a UserData/ProductKey/Key section for Windows 11, unless this section is required to make the other parts of autounattend.xml work. So you may talk about derivative items if you want, but please don't misconstrue my questioning for the UserData/ProductKey/Key section with something that it was never about and please try to make at least an effort to try to see where it may fall in the context of the continuation of the creation of Windows bootable media, be it Windows 10 or Windows 11, for a media creation application like Rufus. Or, if you really want to extend this thread like there's no tomorrow, you may as well start a discussion about the differences between Rufus and the MCT when it comes to the creation of bootable media, starting with whether MCT has a need for populating a product key...
Except I won't. And I explicitly told you I won't from the get go. But it seems you appear to have taken objection that I didn't rush into using autounattend.xml for the 3.17 release, most of which was due to that release being well under way and pretty much locked already, and the other part of which was ironically due to you deflecting simple questions that might have helped speed up that process...
@Akeo Since most recent Windows ISO has a install.wim with size >4GB, is it possible that you please consider implementing a new feature into Rufus: the ability to automatically split install.wim so that all contents of Windows ISO can be copied to a FAT32 formatted USB stick? This way, Secure boot does not have to be turned off in order to install Windows in UEFI mode.
Nope. We don't bypass the 8 GB min RAM restriction because we agree with Microsoft on that one (if you are running Windows 11 on 6 GB or 4 GB, you are really going to have a bad time). Oh and we don't apply the unproven Disk/CPU bypass, because we still haven't seen any verifiable evidence whatsoever that these do anything.