Well every time I think I'm close, Toolkit throws me a curve ball. I've attached my DISM_RemovePkgsList.txt file and MY_TKhelper_RemovePkgsList_W11_10.0.22000.txt file. Using MSMG, either v13.3 or v13.4, both lists complete without errors when invoked separately or one after the other. Yet when I boot Windows 11 Image Version 10.0.22000.318.0, the following supposedly removed Windows components are still present: 1. MS Edge, desktop shortcut and program directory present and program listed in the uninstallable list in Control Panel Programs and Features 2. Ditto, One Drive 3. Ditto, Paint 4. Media Player is present 5. Windows Firewall is still present and works. Using MSMG, v12.7 on Window 10 , image version 10.0.19041, I was at least able to remove some of these components. Anybody know what gives?
Supported SPbuild are: In recent Toolkit 13.4 is only 22000.1 and 22000.1936 Until today, if I understand correctly support is not extended for every SPBuild released. You have to work on one of 2 options. I once commented with MSMG to add support for SPbuilds recently released by MS as a direct download. But he said "ToolkitHelper" would get much bigger and could result in performance loss.
OK. This compatibility issue is very confusing. In the v13.1 release notes MSMG says Windows 11 v21H2/v22H2 (All Editions) Is among the supported operating systems. And I'm pretty sure I have completed a couple of MSMG v13.3 builds in the past that did remove one or more of the components I'm trying to remove now. In any event, thanks for the head's up.
My dear friend, where can I find this "Tweak to Disable Downloads Folder Auto Group By Date Layout" ?
Windows 11 v21H2/v22H2 (All Editions) is only for other features of Toolkit and not for manual component removal.
Hi @MSMG, I suppose this is the reason why I was facing issues with version 22621.525 then. The supported image version is quite confusing unfortunately, and as I see, even experienced users are facing issues because of it. Could you perhaps add a build check right before the image index is selected via Select Source from <DVD> folder? Toolkit.cmd should have variables with hardcoded explicit values for supported version information. It should be not too much of an effort, given that you read the details straight away already: ####Source Image Information################################################### ------------------------------------------------------------------------------- Image : Install.wim Image Index No : 1,2 Image Architecture : x64 Image Version : 10.0.19044 Image Service Pack Build : 1288 Image Service Pack Level : 0 Image Build : 19044 Image Default Language : en-US Then the user can be notified immediately when the image is not supported and ask whether to continue (maybe by switching to DISM). As an alternative, I do wonder whether a (better) delta versioning information you could build up for the builds between the x.1 and the latest cumulative update, adding only key changes for the components (and even making it backwards compatible when adding support for them). While there are about 10 quality of life related changes a year (usually December-January does not have them), which you support when adding the latest security update, I don't think they are making major changes to the components all the time that you would need to track - most of the changes should be internal (coming from the files within or perhaps a new value under an already existing key in the Registry), and only rarely you should need to add version specific enhancements, but even so, they would be carried forward for future patches. That should leave you with minimal information to work with, even if you support both monthly patch versions, since the first one (security) has the changes from the previous month, and the latter will be (should be) on same change level then the next month's security patch. Even if you need to work with a lot of version-based Registry values or files, their version-based information should be handled dynamically anyway (you can get them from .mum / .manifest files, I suppose), as hardcoding values is hardly ever the best approach, and only store key lookup values that differ from the state of the last patch. As the source is not open, I am limited to such assumptions. Would this not be something that could work out for every official (no insider) release?
hey all, general question. and a question for @MSMG if shell experience host is removed, how would you access network connections to connect to your wireless? another question. using the auto unattend gennerator that is baked in to the toolkit, removeing all the new components I assume it bypasses the oobe issues? since all data requested via OOBE are answered? if i'm wrong please doo let me know my folly. a query for @MSMG. may as well get all my questions out now, I soon won't have enough time on my machine soon. when running the string on the latest toolkithelper.exe the string being c:\t\bin\ToolKitHelper.exe c:\t\mount\install\3\ /? >>packages.txt to get all the components that can be removed should I be seeing the folowing components displayed on a release version of toolkit helper/toolkit? UIXaml24 - Microsoft UI.Xaml Package 2.4 UIXaml27 - Microsoft UI.Xaml Package 2.7 VCLibs140 - Microsoft Visual C++ 2015 UWP Runtime Package VCLibs140UWPDesktop - Microsoft Visual C++ 2015 UWP Desktop Runtime Package and NETNativeFramework22 - Microsoft .Net Native Framework Package 2.2 NETNativeRuntime22 - Microsoft .Net Native Runtime Package 2.2 if not, should they not be labled like this to distingwish that these components are in testing? NETNativeFramework22 - Microsoft .Net Native Framework Package 2.2 this component is in testing! NETNativeRuntime22 - Microsoft .Net Native Runtime Package 2.2 this component is in testing! currently i'm not sure if the components i've listed are in testing or are safe to use. time to get testing. thanks to @interaction sorry forgot your full username sir and @hariss for the auto unattend functionality. pardon my spelling mistakes, I use assistive tech due to being fully blind. Majid
not sure if windows 7 is supported, guide me.? you me how to use tool.? in the first post there are 2 video links on how to use it.
Hey, really appreciate the response, Now to answer your questions, I am using the default powershell version 5.1 and have also tried PowerShell 7.xx, and have been trying this out since toolkit version 12.xx on Windows 10 22H2 as well as Windows 11 22H2 and have been encountering the similar issue , I haven't used the "Force .NET programs to use newest .NET Framework" tweak neither have I integrated .NETv3.5 or .NET v5+ and no , both of the registry entries that you mentioned are missing in the OS
Hey, appreciate the reply, Sadly as I mentioned , the github projects that I use are pre-compiled and do not actually open a powershell window, they are integrated executables and do not have an option to change the parser by me and honestly, I don't have the knowledge necessary for it. And as I mentioned before , I keep the networking components sections untouched and also leave IE11 and edge legacy just to prevent the parsing issues but it still doesn't fix the issue apparently for me ..
So you are using closed source programs that you are having issues with? Can you not debug it with the maintainer? It would make more sense, since they know what they are doing there. Are these projects available for the public? I (or we) could give it a try, since the systems in use should be similar to yours. Also, are you sure you don't have anything for .NET v4 Framework in the Registry? By default it should look like this: gci "HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" Hive: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full Name Property ---- -------- 1033 CBS : 1 Install : 1 Release : 528372 Servicing : 0 TargetVersion : 4.0.0 Version : 4.8.04084 This is from 19044.1288 deployment where I removed pretty much everything that the Toolkit allowed me to. As you may know, PowerShell is heavily based on the .NET "ecosystem", and this is where the error that you showed was originating from as well, which by default is not an issue. If you do not have .NET available, this could be a problem, however, the Toolkit should not remove it.
Feel free to share the ISO you have created. Based on what you described, WinToolkit could have been the issue, but if you are not even using it, then most be something else. I am working with VirtualBox, so testing will not be a problem in any way. Just so you know, even though the Toolkit will let you work with any .iso pretty much, only certain build numbers are supported to create a stable system apparently. I thought I was using a supported version myself, but it turned out to be a disaster after the component removal - I would not be surprised if this would be the case for you as well. Seems to be a hot topic in recent days.