Completely uninstall provisioned apps: how-to and detailed explanation

Hello again,
I see you guys reply quickly! Not sure I can keep pace.
Anyway, I'll try to reply a bit at a time.

ddelo said:

Great question, I don't yet have an answer. Needs more investigation. But, would it make any difference if we know beforehand?
If for Instance we select the PS script for removal, it will take care of it, without the user getting into the trouble to know!

No difference for the end user, you're absolutely right. Just curious at which point Remove-AppxPackage calls Remove-AppxProvisionedPackage and how come sometimes the call is not made. I like to know how things work - and sometimes don't work.

ddelo said:

Answer: I've come to this conclusion, rather assumption, by firstly deprovisioning from everybody on the machine (i.e. All New users don't ever get it back) and then let the current user (Administrator) to remove from and take care of its own account.

I see what you mean, but I disagree. I'll briefly explain my reasons.
Deprovisioning ensures that the app won't be installed when a new user is created. Or, to be more specific, the installation actually takes place upon the first log in of the new user.
The difference is subtle, but important: a new user who never logs in doesn't get the app installed. I can see that on my machine, where I have a standard user account I use for daily activities and an administrator account with which I never logged in and which I invoke from the standard user account to run elevated tasks. The admin account does not have any app installed.
Deprovisioning is also useful on a machine shared by many people, where it could be undesirable that certain apps are pushed to the end users which will be created over time.
The important thing is that deprovisioning does not affect existing accounts, be standard or administrator accounts. Remove-AppxPackage is the one that works on existing accounts. Existing accounts and future accounts are independent and the cmdlets to handle them are also independent.
This is why the order in which Remove-AppxPackage and Remove-AppxProvisionedPackage are given does not matter. Not saying your script is wrong, just that the final result is the same. To be extra-pedantic, there is one tiny difference. If you run Remove-AppPackage first and the app is of type1 (auto-deprovisioning), the following Remove-AppxProvisionedPackage cmdlet would fail because the app is already deprovisioned.

ddelo said:

I haven't found any problem removing any of the 3 types of apps (Bundle, Non-Bundle1, Non-Bundle2) using the my User account (who is of course Admin).

As a side note, I do it by invoking the admin account from the standard user account and it works as expected.


I have much more to share, but I'm a bit overcommitted atm. I'll be back to you in the next few days. Just on spoiler though... to keep you tuned. YES, as I said in my first post, the given commands WILL uninstall for all users on the machine, standard users, administrators, existing and future users and the removed apps WON'T re-appear even after a feature update. Tested. More on it in my next post - with all the due explanations.


Cheers,
Mark

Hello @Dimitri and @Paul,
a few (three) updates.



FIRST - as I said at the end of my previous post, the apps removed with the proper commands won't re-appear even after a feature update.
I tested this by uninstalling six or seven apps using a PS script I wrote last November. At the time I was running W10.0.19041. In December I upgraded to W10.0.19042 and the apps DID NOT come back. Since then I removed a bunch of other apps using the same script. None of them re-appeared so far. Sure I'll check again and post back after the next feature update.



SECOND - I finally found some time to take a look at Paul's scripts. Now I understand why you had to go through the two-step process and use the built-in administrator, while I had no need to do so.
I will focus on these two lines from the first script:

Code:

1.   Get-AppxPackage -Name $AppName | Remove-AppxPackage
2.   Get-AppXPackage | Where-Object DisplayName -EQ $AppName | Remove-AppxPackage -ErrorAction SilentlyContinue

And these two lines from the second script:

Code:

3.   Get-AppxPackage -Name $ProvisionedAppName -AllUsers | Remove-AppxPackage
4.   Get-AppXProvisionedPackage -Online | Where-Object DisplayName -EQ $ProvisionedAppName | Remove-AppxProvisionedPackage -Online -ErrorAction SilentlyContinue

Line 1 and 2 are meant to perform the same taks, so the second is basically a duplicate of the first.
Actually, line 1 is slightly better than line 2, because it follows the "filter left" rule: the sooner you filter out, the better, because you avoid to shove unnecessary objects down the pipe. Not sure about the performance impact in this specific case, because I don't know how the filtering is implemented inside the Get-AppxPackage cmdlet. It is probably negligible, but I just prefer to filter as soon as possible.
More important, line 2 will ALWAYS fail. This because the object returned by Get-AppxPackage contains fileds called Name and PackageFullName, but NO FIELD called DisplayName.



THIRD - Last and most important, you're not removing for all users; see section two of my first post for the long of it.
Here is the short. Basically, Remove-AppxPackage can be executed in three modes:
https://docs.microsoft.com/en-us/pow...-ps#parameters
MODE A: without specifying any user, as you do. The package is uninstalled ONLY for the user who runs the cmdlet. No elevation required.
MODE B: with the -User parameter. The package is uninstalled ONLY for the specified user. Elevation required if the specified user is not the user running the cmdlet.
MODE C: with the -AllUsers parameter. From the help page:

This parameter removes the app package for all user accounts on the computer. The parameter works off the parent package type. If it is a bundle, use -PackageTypeFilter with "Get-AppxPackage" command and specify the bundle. To use this parameter, you must run the command by using administrator permissions.

I'll try to perform additional tests to verify a couple of new ideas I had. More coming next week.
Cheers,
Mark

ddelo said:

Now why an app, like this one, does not show in the All Apps, is something that only the Redmond geniuses can answer... what we have to do, is to take into account that there are apps like this one!

Even though I am not a Microsoft engineer, I do have the answer to this one. The thing is: what you call All Apps is not All Apps!

First of all, let me recall that an app is something different from an app package. An app is usually made up of several app packages. There are also single-package apps, but even in such cases the logic difference is crucial when it comes to uninstalling. If you restrict to those apps which provide a GUI for uninstallig, you may not care about all this. But since we are looking for a univeral command, it is vital to keep in mind the difference. Why? Because there is no PowerShell cmdlet that works on apps, only cmdlets dealing with app packages.

From the Get-AppxPackage help page:
https://docs.microsoft.com/en-us/pow...-ps#parameters

-PackageTypeFilter
Specifies one or more comma-separated types of packages that the cmdlet gets from the package repository. Valid values are:
* Bundle
* Framework
* Main
* Resource
* None
By default, this cmdlet returns only packages of types Main and Framework.

The first command you use builds a database of app packages of type either Main or Framework. The special app you found has a package of type Bundle, but no package of type Main or Framework!

Out-of-topic extra tip: for the sake of completeness, I'd like to add that the -PackageTypeFilter parameter of Get-AppxPackage accepts an additional value which is not mentioned in the help page: All. Useful instead of a long comma-separated list.

Cheers,
Mark