NOPE dude you are essential in this thread since when MSMG start with Toolkit we need your knowledge trust me
The fact that you made your already horrible way of removing components even worse by adding the actual deletion of service keys from ControlSet001 is mind-boggling. Put Windows Server on a VM, and audit update/servicing logs from another VM running a build made with your ToolKit and be amazed at the corruption flags it returns.
I've posted about this numerous amounts of times in this thread. Many component packages also have an XML file associated with them, that is also a hidden and protected file. Within that XML the permanency value of the component package is defined. Those with a permanency value of "Removable" you are able to remove via DISM, the control panel, etc. Those with a permanency value of "Permanent," are unable to be removed unless you "force" remove them. When you remove a component package that has a permanency value of "Permanent," your component store issues a "STATUS_SXS_COMPONENT_STORE_CORRUPT" flag, which is considered a critical error. The end-user is not made aware of such a flag; however, it's this reason why after some component package removals the end-user is no longer able to update their OS nor service it with SFC /ScanNow, RestoreHealth, etc. The only recourse is a reinstall, as you cannot just reinstall component packages. The best way to remove them is to prevent them from installing to begin with. They are all provisioning packages, just like the Provisioning Application Packages one can remove. You aren't actually deleting App Packages - you're removing their provisioning for installation. You can do the same with component packages, as when Windows is installing, it looks in the HKLM\SOFTWARE hive under the InboxApplications subkey. Within that subkey are child-keys each representing component packages to be staged for installation. By removing those keys - which mind you are not protected keys (i.e. require no system-level elevation to remove them) - Windows does not provision those and they are not installed onto the system; however, their directories remain on the system itself and by keeping the symbolic links these packages have across the running system, no component store corruption is ever flagged since there were no component packages actually removed because they were never installed in the first place. The 2nd way to remove them is by setting their permanency value to "Removable" from "Permanent," and then removing the packages with DISM, but even so I cannot say for certain whether that will not cause potential issues at a later date And to then actually delete the service keys associated with these components from ControlSet001 - which acts as a pointer for the CurrentControlSet - is an extremely callous way to try to prevent these services from running despite the component being removed. To disable those you can simply created an OOBE.cmd script that DISABLES them from the proper CurrentControlSet during the OOBE setup pass.
These would be the reg keys: Code: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\InboxApplications Code: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Staged In that case, it applies only to "modern" apps. There is no such key or procedure for OneDrive or Defender, they in fact will cause SXS store corruption. In other words, even if following the correct procedure as outlined by the "assigning a lower sense of responsibility" guy above, there will still be issues as not all are AppX. Cheers.
How do I integrate .reg file in this toolkit? There no instructions on how to do it and no one mentioned about it on here
DAMN! You're right, something was wrong with the ISO. I download it again using MediaCreationTool, and now it works perfect!! THank you to point me to the solution!
If the component is no longer present whats the problem of removing the service associated with it? Dism does this for most packages but for some like Xbox and Biometric Services it does not but I had no problem removing them. But I agree with your other posts where removal should be done in ControlSet001 when in offline service in place of CurrentControlSet. I do not know if in the new versions MSMG corrected this.
hi, i know there is a problem integrating update 192 msmg does not show the right version after integration. but does it matter? yes, i read the post from back there about a dism problem, but still did not understand it was integrated fine or not?
Hi MSMG, Firstly, thank you so much by great job with MSMG Toolkit..!! Well, how I change Windows 10 Enterprise LTSB 2016 Eval to Windows 10 Enterprise LTSB 2016 Full..?? Thank you so much..!!