On the "MSMG ToolKit - Customize Menu" does the selection "Import Custom Default Inbox Apps Association from XML File" allow the user to Import File Associations for all Windows programs or just "inbox apps"? In other words, is it the same as the DISM Import File Associations command: Code: dism /online /Import-DefaultAppAssociations:"C:\FileAssociations.xml
Regarding LTSC: This one doesn't come with the 8 "Windows Apps" menu components. There are also some components that when removed, I believe the ToolkitHelper removes the components that need that component. This only the MSMG can confirm. You can see that several components in the log I posted had already been removed. But it could also be a detail in the code that marks dependents that are present in Menu 8 "Windows Apps" even though the components are not present in the LTSC. What I can tell you as an example is that if the ToolkitHelper does not detect the presence of the component, it will post the message that the component has already been removed. When you Disable WindowsDefender through the Features list, the ToolkitHelper no longer detects the Component for removal through the Menus or through the ToolkitHelper List. About preference: That's up to each one. You will have to use and decide. But about "Pro", goes from 19045 22H2. I don't recommend the 22000, but much prefer it due to some options that still resemble W10 to Ribbon, for example. I'm using the 22621 and the performance for me is better than the 1904x. I believe it is better memory management. But there are some annoying bugs, since I had tested it a few times 22000, mainly in scripting. Now I see why everything worked on w10 and w11 so many people were having problems. But I've already worked on it, in my scripts, these last few days, to leave some workarrounds that avoid these problems. Out of curiosity, the main problem, at the moment, is not being able to use windows environment variables in scripts that are executed as TrustedInstaller. This I had never seen in W10. Maybe it happens too. But when Run as admin this does not happen, until nSudo or PowerRun is executed. Username comes with the ComputerName value UserName : DESKTOP-B8VKTHK$ And UserProfile comes with SystemProfile value UserProfile : C:\Windows\system32\config\systemprofile
It is exactly this command. But from the OffLine mounted image. Code: DISM.exe /Image:"Image_Mount_Path" /Import-DefaultAppAssociations:"C:\FileAssociations.xml"
You can simply install LTSC 2021, original to see this. In pt-BR image you will get the ghost SFC error. For other languages, I don't know. But according to this information from the MSMG, this should also occur in others. Maybe all. And after running SFC /SCANNOW command the error is fixed. That simple. If you run the command again you will no longer get the error.
Thanks for making it more clear. As long as I understand, no matter which Windows revision we use (LTSC or Pro) - every single piece of bloatware and components we choose to remove will be removed the same way no matter which revision, with no traces, right?
The error does not come from this (multiple editions) from what I understand. When I tested autounattend.xml with something forged from the web (as at that point I have not resolved the syntax errors yet), I was not getting the ProductKey error, which are - of course - present for me as well. Though I did try to fix it already, but since you said earlier that many entries have to be removed with regards to components, so I was waiting for a clean version prior sorting out the ProductKey error, as at this point it does not make too much sense, given how much will potentially change for the desired target. Nevertheless, I have already looked up possible solutions and I can do fast testing (about 3 mins per test) if the issue is still present at your end, which means you already work with the clean version and you sorted out the 2 syntax issues. In this case just attach a version that you think should work - the personalized settings don't matter.
My thought is that he is testing on an ISO with only one Edition. My tests with multiple editions didn't have this problem. Regarding the autounattend he sent, it's the same as the one I tested here. Here, in LTSC 2021 on en-US x64, it worked as per my last fix post. Replacing "Never" with "OnError" it should display the prompt for you to enter or perhaps ignore the key. You're waiting, but I've already launched on day 19 i removed what you quoted together with hyphens in sequence, on day 22 i fixed missing data when getting language data from image. It's a few posts above.
For a quick test I used Enluaphelis' autounattend.xml (which is still bloated, but smaller than mine) where I made sure <WillShowUI>OnError</WillShowUI> will be there for the <ProductKey> tags, but it does not work. I am using an image with 2 editions, and I also tried removing the tags completely earlier, which also did not work. I will check your modified Toolkit.cmd-s to see whether it makes a difference, but I still think the solution might need to come from elsewhere, unless your latest modifications introduced have notable differences. Will report back shortly.
I tested now with your Toolkit.cmd (not Toolkit_TESTING.cmd) for the 22nd, the autounattend.xml file is much cleaner. With the normal output (<WillShowUI>Never</WillShowUI>) it did not work, then I changed it to OnError, also did not work. I'll see if I can fix this.
Thanks a lot for testing. Also try removing the Product or Product Key block. You can add a empty tag in PorductKey <Key></Key>
Well done! Having an empty <Key></Key> did solve the issue, the setup did not report any autounattend.xml errors (I only went till the disk selection part for a quick test). This does work for both <WillShowUI>Never</WillShowUI> and <WillShowUI>OnError</WillShowUI>. Edit: I think for an empty <Key></Key> it would be the best to use <WillShowUI>Always</WillShowUI> as a default. Not specifying it explicitly will not show the prompt for key.
Using "Allways" in this case, is not welcome. OnErros should open UI. "Allways" should or will force the UI to be displayed there is not the purpose of autounattend.
There is no prompt for key with OnError, does not matter if it is put in front of or behind <Key></Key>.
Yes, before or after, within the same tag, it makes no difference in some cases. "Allways" should or will force the UI to be displayed, even if it doesn't work. I prefer to leave the Configuration with "OnError". I'm going to add the empty Key to solve this problem. I'm wondering why it didn't go wrong here. Neither in pt-BR nor in en-US. I made the ISOs using Toolkit.cmd. Not tru TESTING one. But the codes are the same. Only the elevating rights process is different on how to call the nSudo to start the script.
Well, this was the only way to make the prompt appear based on all the different tests I made. Also, I find that there still a lot of data in the .xml file for various components, e.g. multiple reference of "Microsoft-Windows-Deployment", "Microsoft-Windows-WinRE-RecoveryAgent" etc., and there is another, empty, commented <!-- <ProductKey></ProductKey> --> reference, which seems weird, among many other stuff. Personally I think there are too many options forced into autounattend.xml, which I don't remember seeing manageable in the tweaking menus for instance. If anyone really needs all this, it should be at least selectable. I think it's just not for me in this form, but I'm glad we sorted out the issues at least - I did let the setup complete and there were no errors (username had to be pre-entered for the removed CloudHostExperience of course).
Yes, there are things that may be useful for some people. Before, it was full of settings, but with the removal of components, it caused problems. About putting more options, I don't think it's convenient to complicate things now. About what you said that the prompt appears, but it was necessary to appear, in which case it appeared? Or did you just want to test what would work? That's what I'm talking about, about autounattend being a response file ideally there are no unnecessary prompts. About the lines that have <!-- --> This is the line comment, it is not read when executing the xml. These lines are examples for those who want to put their key. Just uncomment. But it is not possible to put multiple keys, they are just examples. About "forcing": we are talking about 2 different things. I was talking about displaying the prompt at all times, even when it's not necessary. You are saying that having too many settings is forced. But if you look, the settings are the same throughout the xml, they just change where they will be used. And that's good. If the user uses it, it will already be there. Glad putting the empty tag solve the problem, too. I'll check to see if there's anything else to remove. I think it's just a Control Panel tweak.