@tempdrive1 @inTerActionVRI I made everything just as you said and it is the same error again and again... I tried different variations multiple times and had to reapply every tweaks on ISO 4 times. Is there any way to just swap the autounattend.xml file and not re-do the ISO over and over again?
Use AnyBurn to edit the .iso, that's how I was doing the quick testing. I have not checked the re-ordering the tags, but the Key tags are within the ProductKey tag as hints for the current generated autounattend. Given that you got the error message again, I believe it must stay there, you cannot move it outside and make it work then. I thought I was not getting the ProductKey prompt because of the stored key in bios (I was running a Win11 base virtual machine setup, which uses UEFI bios emulation or access), but it is not the case.
I'll check AnyBurn, thanks! In my screenshot the <Key> tag is withing the <ProductKey> , right? My Windows key is stored in bios as well, but when installing a stock iso it still gives a product key prompt which I just skip. Then why it does not work? It's really weird.
I guess having the empty <Key> tags there means overriding the stored values from the bios, otherwise it looks fine. Strangely, the prompt just did not appear for me at all, regardless of which non-enforcing option I chose. I'm going to do some more testing, because things might be done a little better (as in in a more consistent way) perhaps. What I wanted to say is that you only need autounattend.xml if you removed CloudHostExperience. If you did not, I recommend not using autounattend.xml and just do a normal installation. You will have to click on things anyway, a couple of more clicks will not make a difference, and I assume you are not doing dozens of deployments (especially with your account name hard-wired) either.
My point is that I want to remove as much UWP crap (even though it's not using resources and appears only one time) as possible. Hence I remove literally everything in the "Remove" section and leave nothing. And also I'm sick of seeing that crappy setup stage with telemetry prompts. I just want to enter my password and go straight to the desktop. I'm doing a deployment for myself only so I need this cleanest ISO which I will use on my PCs.
I believe it does not replace. I think It will just bypass the prompt. If you install the original machine Edition, it should activate automatically. Note: The automatic activation depends on the user not having disabled some features. Or inserted tweaks that prevent this.
It looks like it is getting too complicated to a point where it becomes counterproductive. Based on what you said, if you store settings in the .xml for which the required components have been removed, it adds a lot of confusion and will take quite some time to debug why they don't work, which is hardly suited for beginners. You would need to make it more dynamic: do not include options that will not work (based on the removed components). This would be more effort for you. Alternatively the minimalistic option is still there and you could let "experts" add their required settings, since I imagine they would be adding additional custom entries that would never be there by default, in which case they will have to edit it anyway. I have been fooling around a bit with the data included, and it can be quite unstable depending on what is present, but the errors were showing the ProductKey references regardless. It is still an optional feature, so don't take it as a complaint, since I am not required to use it. All I am saying is that it should be less trouble to use it, doesn't matter who the target audience is.
There is nothing wrong with this. My only point was that a more generic approach brings less trouble along the way.
But I removed all settings for components that can be removed. I didn't understand. What else could be removed? As for the sessions you specified to remove, don't get in the way. For this version I'm just going to add the empty Key tag and remove all the firstlogon configuration sessions. These were tweaks for the w10 control panel. The initial proposal was not just to make a generic autounttend, but a generic autounttend (that works for everyone) and comprehensive (that contemplates the largest possible number of configurations). However, as problems surfaced, it really got bad for users who still don't know how to make the modifications themselves. In W10, in the past, when I removed a component that had some configuration in the autounattend, it went to the log, but it didn't prevent the installation. This was ignored and continued with the installation. Today, anything, stops the intallation progress.
What would the ideal functioning that you are looking for look like? Putting: Code: <ProductKey> <Key></Key> <WillShowUI>OnError</WillShowUI> </ProductKey> Did not work? Attached is your AutoUnattend: I put in the suggested changes and removed the FirstLogon settings as I said.
Spoiler Thnks to @tempdrive1 for Validate XML code, repport bugs and testing. Thnks to @Enluaphelis for repport bugs and testing. Download in attachment.
Things are getting better each day! Well done! Please feel free to adjust the display text/color after the Write-Host commands for the xml syntax verification - I just put there something as per my standards. What would be interesting to see as an additional automation in my opinion, is that since the removal of CloudHostExperience breaks OOBE, as soon as people select it for removal, the Toolkit would prompt (with a one-liner explanation) for a username (mandatory) and a password (optional) as a bare minimum. At this point they will be stored in variables. Then, when the component removal actually takes place and CloudHostExperience will be really removed (they have not unselected it), as soon as the component removal is done, you could already deploy the autounattend.xml into the DVD folder with the username (and password) filled in if this file is not present at this point (i.e. the user did not generate it or copy it manually). Alternatively the prompt for user account information could be done right before the component removal takes place, it makes no difference in the end. This would serve as a preventive method for broken installation attempts for users who are not aware or do not care about managing autounattend.xml in general.
Something like: if there is no autounattend, it does not display or make the CloudHostExperience option available to the user. If it exists, the option will be available. But it's better to do as in IMCK, I made a note appear in the Main Menu to alert the user to write autounattend. About these changes, and aesthetics is better for MSMG to decide. I put a lot of notes, in the menus and such, but a lot of people think it gets too polluted. I think more information is better. But there's a "less is more" vibe that I'm not really in favor of. There are cases and cases. Each must be well thought out. There are people who would like nothing to be displayed on the screen, just a progress bar would be fine. I like to know what's going on underneath.
The issue with your proposal for CloudHostExperience would cause some inconvenience, as people most likely would add autounattend.xml after the components were removed - meaning they would not return to see CloudHostExperience to show up, let alone run the component removal again. Display text is always nice to have, but don't expect people reading and following instructions. If the earlier versions of the Toolkit required almost no attention to manage, nobody would like put in more effort to have nearly the same outcome than before. There are people who would like nothing to be displayed on the screen, just a progress bar would be fine. I like to know what's going on underneath. This is the easiest thing you could solve in everyone's favor: set a variable for DEBUG, if it is TRUE or 1 or something, you display all details, if it is off, then you display the bare minimum. Fast and easy-to-use tool with stable results is what everyone is looking for even if new features will be added. Both of these suggestions (automatic autounattend.xml creation for CloudHostExperience removal and Debug information display) are low-effort implementations with your skills. And, of course, I look forward to have the removed component detection added as well!
Yeah I thought about it. But the detail is that people new to the tool are attracted to removing everything that is available. I myself was like that today my removal comes down to a removal preset that I call "Personal Work" and it is a preset that removes between 40 and 50 components out of 174 components. That's why I commented about preventing the option from being displayed. But the option to put a note in option 5 of the main menu is better. So the user is carefree and when returning to the Main Menu, he will see the note. Regarding this, let's wait for @MSMG to take a position on this. The person will see the comments here and eventually, with the various updates that occur during the month, he ends up gaining experience and learning how the tool works before giving up because he finds some stones in his path, right from the beginning. This debug thing is good for the future, yes, but something like a log generator for parts of the script. I was thinking of doing something like activating a help by command line, but in batch it seems a bit complicated with a code of this size. Let's see if everything goes well this time. I hope so. But if you encounter problems, let us know.
Now it finally worked! Thank you guys! Also, why did option to remove UndockedDevKit disappeared? @inTerActionVRI @tempdrive1
UndockedDevKit it was never available in the menus, only via list. You can check this out in the Toolkit 13.4 release post.