Skip to content
This repository has been archived by the owner on May 28, 2021. It is now read-only.

add UninstallMsftBloatAllUsers #165

Closed
wants to merge 3 commits into from
Closed

add UninstallMsftBloatAllUsers #165

wants to merge 3 commits into from

Conversation

SebastianK90
Copy link
Contributor

this will work only online but will remove all MsftBloat from all users

@Disassembler0
Copy link
Owner

Please provide also revert tweak which reinstates the default settings.

I wasn't able to find a reliable way to do it apart from DISM, which is neither safe nor user-friendly.

# In case you have removed them for good, you can try to restore the files using installation medium as follows
# New-Item C:\Mnt -Type Directory | Out-Null
# dism /Mount-Image /ImageFile:D:\sources\install.wim /index:1 /ReadOnly /MountDir:C:\Mnt
# robocopy /S /SEC /R:0 "C:\Mnt\Program Files\WindowsApps" "C:\Program Files\WindowsApps"
# dism /Unmount-Image /Discard /MountDir:C:\Mnt
# Remove-Item -Path C:\Mnt -Recurse

@SebastianK90
Copy link
Contributor Author

yeah there is no counterpart I know, the only way is to install from store.
Maybe we should mention that in the comment on top. (just like in UnpinTaskbarIcons or UnpinStartMenuTiles)

@ghost
Copy link

ghost commented Jan 13, 2019

I would love to see the UninstallMsftBloat tweak to have the AllUsers and exception list as optional arguments, so I could easily define what I want in a preset file for specific scenarios.

Real life example of ideal setting for one small school in my town:
UninstallMsftBloat -AllUsers -Exclude "Microsoft.SkypeApp","microsoft.windowscommunicationsapps"
There's no AD, so AllUsers setting would be handy. Regarding a possibility to install apps back - nobody in the organization uses "tile apps", nobody knows them, nobody cares. Mail app would be kept and user would just click the icon at the taskbar.

I could make such PR, but I can already see it would unfortunately violate the project's rule of simplicity and copy-pasting code parts.

. . .Which leads me to an idea to make another optional extra tweak, that wouldn't harm current tweaks. What about something like UninstallAllBloat, that would introduce the opposite approach - list all apps and remove everything except defined Exclude list? That would automatically cover all new apps and all 3rdparty bloat apps. Some important exceptions might be included automatically. Some of "important" apps are protected by os and can't be removed by command anyway, so it should be safe enough. And this "special" tweak would allow the usage of arguments (and for even better safety - require the usage of arguments).

@Disassembler0
Copy link
Owner

A short explanation about subtle differences in cmdlets first.

@sippi90's PR uses Remove-AppxProvisionedPackage - This is a PowerShell cmdlet for dism.exe /remove-provisionedappxpackage which removes the files from the Windows image. This is different from Remove-AppxPackage -AllUsers as that one does extra steps. Remove-AppxProvisionedPackage only removes the package from provisioning and keeps it for the users who already got it, whereas Remove-AppxPackage -AllUsers uninstalls the package from all users and then deprovisions it. Only Microsoft packages are provisioned, so deprovisioning only works for them. The 3rd party packages are installed using other means.

What about something like UninstallAllBloat, that would introduce the opposite approach - list all apps and remove everything except defined Exclude list?

You would probably like to see Remove-AppxPackage -AllUsers in Get-AppxPackage -AllUsers loop, which, as you point out, lists also the protected packages and packages from different sources. Funny enough, Remove-AppxPackage -ErrorAction SilentlyContinue doesn't silently continue on failures, so a foreach with try-catch statement needs to be used here.

The apps which can be uninstalled but currently aren't by the script are

  • Microsoft.Advertising.Xaml
  • Microsoft.HEIFImageExtension
  • Microsoft.NET.Native.Framework.1.6
  • Microsoft.NET.Native.Framework.1.7
  • Microsoft.NET.Native.Framework.2.1
  • Microsoft.NET.Native.Framework.2.2
  • Microsoft.NET.Native.Runtime.1.6
  • Microsoft.NET.Native.Runtime.1.7
  • Microsoft.NET.Native.Runtime.2.1
  • Microsoft.NET.Native.Runtime.2.2
  • Microsoft.Services.Store.Engagement
  • Microsoft.StorePurchaseApp
  • Microsoft.UI.Xaml.2.0
  • Microsoft.VCLibs.140.00
  • Microsoft.VCLibs.140.00.UWPDesktop
  • Microsoft.VP9VideoExtensions
  • Microsoft.WebpImageExtension

Plus intentionally excluded

  • Microsoft.ScreenSketch
  • Microsoft.WindowsCalculator

Some of them are arguably worth looking into and possibly adding to already existing tweaks. E.g. StorePurchaseApp and Services.Store.Engagement can probably go along with UninstallWindowsStore. Advertising.Xaml doesn't sound like something terribly necessary either. I'll follow up on these.

So these would be your whitelist. Shorter than the other way around, but still long enough to be inconvenient, if you ask me. The reason why I prefer explicit behavior and blacklists to implicit and whitelists is that I'd much rather see an issue like "New bloatware added in build 123" than "Nothing works after updating to 123" because the new build introduced a new system app which can be uninstalled but shouldn't be. This is similar to what happened in #164 where the culprit was the only tweak which does use whitelists.

The main point why I'm against irreversible tweaks in general is that some people are perfectly capable of deliberately running a tweak, realizing they didn't want to run it, asking me how to revert it, despite the fact that the tweak explicitly mentions that it's irreversible, then lashing out on me for breaking their devices and slander me and my work wherever they can. This already happened several times even though vast majority of the tweaks are currently reversible. I'm well aware there will always be people like this and that I can't please everyone, but for that reason, I'd like to keep the script as harmless as possible. So this time, it's not only about the project's rule of simplicity and copy-pasting code parts but also idiot-proofness.


So your and possibly also @sippi90's complete tweak, including the need for mandatory parameter as a failsafe, would look like this

Function UninstallAllBloat {
    param([Parameter(Mandatory=$true)][string[]]$appsToKeep)
    Write-Output "Uninstalling all bloatware for all users..."
    # Default whitelist
    $appsToKeep += @(
        "Microsoft.HEIFImageExtension",
        "Microsoft.NET.Native.Framework.1.6",
        "Microsoft.NET.Native.Framework.1.7",
        "Microsoft.NET.Native.Framework.2.1",
        "Microsoft.NET.Native.Framework.2.2",
        "Microsoft.NET.Native.Runtime.1.6",
        "Microsoft.NET.Native.Runtime.1.7",
        "Microsoft.NET.Native.Runtime.2.1",
        "Microsoft.NET.Native.Runtime.2.2",
        "Microsoft.UI.Xaml.2.0",
        "Microsoft.VCLibs.140.00",
        "Microsoft.VCLibs.140.00.UWPDesktop",
        "Microsoft.VP9VideoExtensions", 
        "Microsoft.WebpImageExtension"
    )
    Get-AppxPackage -AllUsers | Where-Object { $appsToKeep -notcontains $_.Name } | Foreach-Object { try { Remove-AppxPackage -AllUsers -Package $_.PackageFullName | Out-Null } catch { } }
}

And would be called from a preset as follows (To my incredible surprise, Win10.ps1 main loop understands this and executes without problems)

UninstallAllBloat -appsToKeep @("Microsoft.ScreenSketch", "Microsoft.WindowsCalculator")

The question is if this is worth adding as a generally available tweak or if the interested parties will make their own in their own tweak libraries. The parameterization would introduce a completely new paradigm and increase requirements of users' PowerShell knowledge. It would also likely be unusable from command line. I can imagine that some other tweaks could benefit from it too, but IMO it's simply too big change with too small gain to be justified at the moment. So for that reason and reasons given above I'm not adding it to the main tweak library and I'm not accepting this PR either.

@eabase
Copy link

eabase commented Sep 30, 2020

Yeah, this seem very sketchy...
I'd rather have the bloat in a separate include file, for easy updates and maintenance.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants