I initially decided not to remove these apps, as removing them was causing some conflict with Windows Installer. I'll test the online removal after Windows is installed. We'll see how it works. Cheers
I can't say for sure that this was the only cause of the Windows Installer issue. But integrating DirectX through the script and not removing the three problematic apps allowed Windows Installer to work properly again. We'll run more tests and see what we can do to improve the script. Thanks for your help! Cheers
Testing again, this time adding the code to remove Click to Do, Get Started, and Windows Backup. This time everything went smoothly, without errors. Here is the updated slim script (attached) PS. The published package will also be replaced.
@SunLion Re downloaded package & ran script appears created default modern calc is not working & some of the apps pictured still exist. see attached.
Yes, that's right. The Default script doesn't remove these apps. Removing these apps will disable Windows Search and other features. They're only removed by the Slim script. I'll consider having an alternative in Default mode.
Please test this modified script to see if it removes the apps. However, removing these apps will disable Windows Search. See if it works for you.
@SunLion receiving a script shutdown just prior "Remove System UWP Apps from Registry" finishing? See log attached.
You can change "echo off" to "echo on" at the very top and the console window will output everything, this way you'll see exactly where it fails hopefuly Long shot, open script and find and remove this line, save and try again ":: by freddie-o - For Windows 11 --- These lines will prevent the SystemApps (with telemetry) from getting deployed during Windows setup" change this ECHO Delete SystemApps with telemetry from InboxApplications to prevent them getting deployed
The fixed script ran without an error, I'm certainly not thrilled by Win11 yet, but I'm working on it! @ SunLion Thank you for your tireless work on this.
Hello, I am not entirely sure I understand your point regarding: Code: copy /y “%~dp0PersonalTweaks\REG\*.reg” “%~dp0Tweaks” and Code: copy /y “%~dp0PersonalTweaks\REG\*.reg” “%~dp0OEM\$OEM$\$$\Setup\REG” >nul Why apply the same .reg files twice? Directly to the connected image and then again when installing the OS? When .reg files are applied to the connected image and .cmd files are applied when installing the OS, it is clear and correct, in my opinion. But the way you are doing it, the purpose of these operations is not clear at all. Please explain it to me, a simple-minded person...
Got it, thanks, I didn't know that. Although it's not entirely clear how registry entries can fail to work during installation if they are already written to the registry and the installer only copies them to the disk when installing the OS and cannot change them in any way. Oh well, you probably know better...
SunLion's handling is reasonable because there is no restriction on adding any registry content to the image, but in reality, some registry contents may be invalid if handled in this way. The specific ones that will fail require personal accumulation. Joining twice can avoid problems.
I agree that SunLion's approach is very reasonable, which is why I mainly use his script ideas when working with images. Do you think that double attaching .reg files avoids problems? It may be difficult to verify this due to the large number of entries made in the registry. I'll take your word for it and add these files to the $OEM$\$$\Setup\REG folder as well. As they say: you can't spoil porridge with butter.