You’ve found yourself in the same situation as most other sysadmins in the world. Now, you’ve been tasked to clean up Windows 10 for your organization. You’ve searched the internet and found blogs and forum posts with random bits of PowerShell, most of which only run within the current user context. Not to fear, this blog will cover exactly what you need to do in removing Windows 10 apps. Brigg, Jordan and I spent way too many hours digging through the same articles and testing what we discovered. This blog will cover the way we recommend going about this process, and what has worked for us. This blog will cover three main points:
Get familiar with some of the cmdlets we'll be using:
Group policy and removing Windows 10 apps
Group Policy is an awesome tool that is historically underused. A lot of admins don’t always want to take the time to see what controls are available to them, nor do they keep their central store updated. For this blog, we’ll assume that you have updated your central store with the latest ADMX templates. If you haven’t done this, or don’t know how there is a really good write-up you can look at here.
We’re not going to spend a ton of time going over all the specific settings, as these will vary depending on what you are trying to accomplish and the target OS licensing level you have. There are quite a few settings that only apply to Education and Enterprise SKUs. (If only you had an application that could quickly identify what you have)
This is what we ended up using on our webcast, this is very similar to the GPO’s we use internally:
Managing Windows Store apps
Next up on our list is managing those Windows Store apps. A couple things to note before we continue. In WMF versions prior to 5.1 the -allusers parameter did not function correctly. This parameter now correctly behaves. We’ll assume you used your favorite patch management software to Deploy WMF 5.1 to your workstations.
Next up we’ll use our favorite patch management tool and PowerShell to remove appx packages. The basic format for the script is below:
The script above uses wildcards (*) so that we don’t have to know the EXACT name of the appx package we want to remove.
That’s it, we’ve removed those packages and we’re done… or so you thought. What if you accidentally removed some appx packages you need, you know something like the calculator, or more importantly, Candy Crush. Not to worry, we can put them back just as easily as we removed them. The script below will put Candy Crush back so you have something to do while you tell your boss you’re slaving away removing all those apps like they wanted.
Windows 10 is a little sneaky on upgrade. All those apps we just removed, they’ll come back sometimes on cumulative updates, and almost always on build upgrades (1803 > 1809). Not only that, those appx packages, don’t install like “normal applications.”
How Appx packages work
Let’s take a second to talk about how appx packages work. Thus far we’ve been using the term “appx package” this is a bit nebulous. All appx packages are different per-user, they are installed in the user context, and they can vary wildly between two users. Chances are on your workstation you’ve removed a bunch of stuff you don’t want to see. Now, go grab one of your users, have them login to your workstation. Behold Candy Crush and Zune Music in all their glory! They’re back! But we just removed them right?
Short-Answer: Sort of.
Long Answer: There are two “types” of appx packages:
Appx Packages – These are what you see as a user, they are what are installed and available to you.
Provisioned Appx Packages – These (for lack of a better word) are the “package cache.” These are the manifest of what packages to install for each NEW user when they login. This is why every time your OS upgrades, you have to remove those apps again. This is part of what is going on behind the scenes of the fabulous message “hang tight, we’re getting things ready for you” when you login to a new (or freshly upgraded) Windows 10 machines.
How are we going to handle this? Well, let’s just remove packages from the manifest. Let’s go remove some of those provisioned packages:
Wrapping it up
Ok, now we’re done. At this point, we’ve removed the appx packages that already exist, and we’ve also removed them from the provisioned package manifest. Both of these scripts need to run to remove the current and prevent new packages each time you get a new machine, or they upgrade.
Well, we're not entirely done.
This one is a tag team between PowerShell and Group Policy. This will take care of all of the above, it’s a little “messier” but a whole lot easier. Who doesn’t like easy? This part has no dependencies. Any version of WMF will work, and guess what, you don’t even need those fancy ADMX templates if all you are trying to do is remove apps. This script functions in the polar opposite of anything above. Here we’re building a whitelist and removing everything else with holy cleansing fire.
Obligatory word of caution, TEST this. Please. Unless you want to go back through everything above and start re-installing appx packages per user, in which case, go crazy remove it all, even the calculator. (But really, don’t.)
Now to make it “auto-magic” take the above .ps1 and create yourself a GPO. In that GPO at each user login, run this script. That’s it. Easy. No worrying about provisioned vs. installed, we just remove everything not on our whitelist every single login. Good luck with your environment and removing Windows 10 apps.
Ever since becoming the Solutions Manager at PDQ, Josh has other people do work for him, including writing this bio. We're pretty sure he eats food, has ~10+ years of IT experience, and would be quite content to never see another Intel IMS ever again. Josh is proud he maintains his CompTIA A+ certification.