How to remove UWP apps on Windows 10 1803

Windows 10’s Universal Windows Platform apps may possibly be Microsoft’s most unpopular decision – ever. What’s the current thinking on how we can deal with them in our environments?

Note:- this article refers to the removal process for Microsoft UWP (Universal Windows Platform) apps on Windows 10 version 1803, fully patched as of 05/07/2018. Further servicing updates (Windows patches) or feature updates (OS upgrades) will possibly invalidate this, although I will strive to keep this article as up-to-date as humanly possible.

It would be safe to say that UWP apps aren’t the most popular move that Microsoft have ever made, whether this be with end-users, administrators, or application developers. Not even a little bit popular, in my experience. So unpopular, in fact, that I hear Microsoft are actually pouring a lot of effort into (again) reinventing their apps platform, next time with something called MSIX (which may, to all intents and purposes, just be App-V 6.0 rebadged). But that’s something for future articles to discuss – right now, if you’re deploying Windows 10 or using it on Citrix XenApp or VMware Horizon, how do you shoehorn these annoying and quite-frankly-useless Windows 10 UWP apps out of your base image?

Let’s remind ourselves how Windows 10 UWP apps are deployed. They certainly aren’t like standard Windows applications, which we must now quaintly refer to as “legacy”.

A traditional “legacy” app is deployed to the device. The app is delivered to the device (in any one of a number of different ways), and the installation of this app places its associated filesystem and Registry entries locally to that device. When a user logs on, they access the device-specific data, and any user-specific customizations are saved off into areas of the user profile. Pretty straightforward, and the way we’ve done it for – well, since forever, really. Here’s a quick screenshot from a presentation I did about legacy versus UWP apps, showing the legacy app behaviour.

The UWP app is a different beastie. The apps themselves still sit on the device, but they are deployed in the context of the user’s first logon. When a user accesses the device for the first time, the available UWP apps from the device are “provisioned” into the user session. The data and settings for these apps are dropped into the local user’s profile rather than stored on the device. Again, here’s a quick grab from the same presentation, this time showing how the UWP app behaves in comparison.

What this does, as many of you may know, is make first logon times very long (which is a nightmare for those with non-persistent VDI or RDSH environments), but also bloats the user profile with what, to be perfectly honest, is a bunch of applications that users rarely, if ever, find any use for. Whilst there may be a lot of plus points to UWP apps around security and portability, most administrators and consultants are just trying to achieve their Windows 10 deployments with a minimum of fuss, rather than reinvent the wheel while they are at it. In my experience, this is where most people are at, and the users – they just want to get on with their work.

So how can we remove the UWP apps from our image? UWP apps are divided into two categories – user (provisioned) apps, which are provisioned to the user from %PROGRAMFILES%\WindowsApps, and system apps, which live in %SYSTEMROOT%\SystemApps.

The first option is to remove the UWP apps from a device (either during the build in Audit Mode, or when the image is already running). Also, as I will mention later, you can remove the apps in supported or unsupported ways.

The second option is to remove the UWP apps from your actual ISO image that you are using for Windows 10 builds and then deploy from there.

Preliminary – decide what you need to keep!

There are some UWP apps that you may need to keep in the image. Microsoft Edge is the first one people think of, but the main one that you probably actually may need is the Windows Calculator, which Microsoft saw fit to make into a UWP app.

So you need to identify the apps (like Calculator) which users may well need and which are now UWP apps. However, many are still optional, like Remote Desktop Connection, which is available in both legacy and UWP versions. We will show you how to remove the apps from a GUI list so it’s a bit easier.

Unfortunately in 1803 quite a lot of UWP apps are “System” apps and can’t be removed. We will attack this in two ways – firstly I will show you how to remove as many as possible without breaking anything, and then I will show you a couple of ways in which you can hack the rest out (but be warned, this is totally unsupported and may well give you issues when applying updates).

Removing the apps on a running (or building) Windows 10 image

I perform these actions before joining the domain, or preferably in Audit Mode, but honestly when this is done doesn’t really make that much difference. The idea is though that whichever machine you perform this on would then become your base (reference) image for deployment.

Now, here is some nifty PowerShell that will allow you to pick which apps you want to remove from a list, by using the little-known (to me anyway) out-gridview cmdlet. Super-cool! Run this command from an elevated PowerShell prompt

Get-AppxProvisionedPackage -online | Out-GridView -PassThru | Remove-AppxProvisionedPackage -online

Hint: you can reduce typing time by using the alias of ogv -p instead of Out-GridView -PassThru

This will give you this output

Now what you need to do is simply highlight the apps you want to remove – remember, we are working on the provisioned apps from the online (current) image, so removing apps here will stop them being deployed to new users. I normally get quite gung-ho here – I tend to leave the Store and Calculator behind as a rule. Not all of the apps you select will be successfully removed, some may be OS-dependent so will fail.

Once you’ve selected what you want to remove, just click OK and it will feed the selected lines back to your PowerShell session.

Occasionally you may get a COM exception error and the process will stop. If this happens, run the command again and remove the packages individually until you find the errant one. In this instance it was the Skype app which was throwing the error, for some reason. In some cases, trying after all the other apps have been removed may get rid of the one throwing the error.

Next I will run the same style of PowerShell for the packages installed for the current user. Not entirely sure this step is required, but I like to be thorough. You will see there are many more app options here!

Get-AppxPackage -AllUsers | Out-GridView -PassThru | Remove-AppxPackage

Again, select what you want to remove and have at it 🙂 Be careful though – look at the app Install Location column to get an idea of what you’re removing – removing File Explorer or the .NET framework, for instance, usually isn’t a good idea. I’m going to try and actively leave Edge, Calculator, Cortana, the Lock Screen – as I said previously, know what you’re aiming to achieve!

It’s normal to see errors here – especially if you’re trying to remove stuff like the Mixed Reality Portal (called HolographicFirstRun) which is, for reasons known only to itself and which I alluded to earlier, is tied into the OS directly.

You should see the apps here disappear from your Start Menu and Start Tiles as they are removed.

Realistically, without digging into unsupported areas, this is as much as you can remove. Connect, Cortana, and Mixed Reality Portal are bound to the OS – Calculator and Edge we have elected to leave there.

Now, unless you want the Start Tiles to look all screwy for every user, it’s important to deploy a customized set of Start Tiles that doesn’t include all the stuff we’ve just removed 🙂 Firstly, set the tiles up the way you want them to look for new users….

…and then export this basic layout with the following line of PowerShell, which you will need to run elevated. This is assuming you’re not already using a customized Start Layout file in your default profile or GPOs providing the “partial” Start Layouts.

Export-StartLayout -Path c:\users\default\appdata\local\Microsoft\Windows\Shell\LayoutModification.xml

You can also dig even further into the guts of your Windows 10 image by using the PowerShell cmdlet below

Get-WindowsCapability -online | more

and looking at the Capabilities that are showing as Installed. If you want to remove any (you can do this through the GUI as well) you can run the following PowerShell once you have copied the name from the Get-WindowsCapability output

Remove-WindowsCapability -online -name Name-of-application-from-previouscmdlet

Interestingly, you can remove Internet Explorer this way, which is pretty cool if you’re trying to get away from users running this browser.

Now I’m going to log off and log on as a new user, who doesn’t have a profile on the device.

You may have noticed something here – that, namely, we have a few more UWP apps than we were expecting! Mail, Calendar and Skype appear to have resurrected themselves!

What gives?

This is to demonstrate how easy it is, with the odd names of UWP apps, to miss things out. What I have done is failed to successfully get rid of everything I was aiming for. Windows Mail and Calendar both sit under the confusing name of microsoft.windowscommunicationsapps which I did not remove (because it sounded important), so we need at this point to actually revisit our PowerShell and remove a couple more provisioned apps. You will remember Skype gave us the COM exception error when trying to remove it earlier, but when I do it this time, it removes successfully. Not sure why this happened – possibly just an anomalous error. But the lesson is – go back and check before we finish up – you may need to remove more apps here!

Now everything looks pretty much how I want it, so I’m now going to join this machine to the domain which will deploy apps to it (assuming it wasn’t domain-joined already – you don’t need to have it off-domain to do this). And I’m also going to update it at this point with all the latest patches. Additionally, make sure you have defined the Store policies so that the apps don’t try and update themselves (because some of them tend to come back this way!) The policies you are after sit in Computer Config | Administrative Templates | Windows Components | Store

Now we’ve got our machine fully patched, applications deployed, policies active (including a policy that deploys a customized Start Tiles layout and which has a rather glaring mistake in it which you may notice), and all we have on the Start Menu and Start Tiles, UWP-wise, is this.

This is as far as you can go without getting into dodgy territory. Obviously Edge and Calculator can also be removed, but we’ve elected to leave them. Connect and Mixed Reality Portal, though, are tied to the OS and not able to be removed.

What if you really wanted to remove them? There are a couple of, and I need to stress this, probably completely unsupported ways of doing this…

Getting down and dirty and unsupported

The first method that I’ve heard mooted is to disable the App Readiness service via GPO. This service controls the provisioning of the UWP apps to new users. So if you disable it, none of them will be deployed. Sounds good, right?

Here’s what your screen looks like after a new user logs on and the App Readiness service is disabled.

No UWP apps at all – but no Calculator, and more importantly, no Settings app. Oops. Looks like we’ve taken it a bit too far, eh? Is there any way we could load them back in? Could we use PowerShell to just load the apps we want as the user logs in?

Hat tip to Jack Smith over at LiquidWare for pointing me to his script which is hosted here. When a user logs on with App Readiness disabled, we could maybe load the apps we want back in by using this bit of PowerShell? (careful, lines may wrap)

$appxs=”Microsoft.MicrosoftEdge,Microsoft.Windows.ShellExperienceHost,Microsoft.Windows.Cortana,
windows.immersivecontrolpanel,Microsoft.WindowsCalculator”
$appxs=$appxs.Split(“,”)
foreach ($appx in $appxs) {
Get-AppXPackage -AllUsers -name *$appx* | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register “$($_.InstallLocation)\AppXManifest.xml”}
}

However, adding apps needs admin privileges, which frankly I find a bit bizarre. Could we manage this with a Scheduled Task?

Unfortunately no – as we can only run a Scheduled Task as an administrative user, then it loads the apps for the admin user rather than the user we are targeting, which isn’t much use really. What we need is a way to make our logged-on interactive user an elevated admin temporarily, in order for this to work.

If you have them, UEM tools like Ivanti UWM and LiquidWare Labs ProfileUnity allow you to elevate processes such as scripts whilst still keeping the context of the launching user. As I am most familiar with Ivanti products, I’ve used theirs to do this. Now note, I am not using Ivanti’s UWM Environment Manager to run the script as SYSTEM (which is an option), because the LocalSystem account cannot deploy UWP apps. We need to use Ivanti Application Control (formerly Application Manager) to apply a Builtin Elevate to the interactive non-admin account.

To achieve this, first create the script above and save it on the local device as a .ps1 file

Next use Ivanti Application Control to allow the user (in this case we applied it for Everyone) to get the Builtin Elevate on running this script file, which means it runs as an administrator.

Once you’ve got the script ready to run elevated, you just need to trigger it as the user logs on. You could do this through your UEM tool or through standard GPO logon scripts or even a Scheduled Task. This works quite nice and swimmingly , getting rid of all the guff except that which we want 🙂

The obvious problem is, of course, that you need a third-party tool like Ivanti or LiquidWare to handle this, which costs money – I did think about using CPAU to achieve it, maybe that’s a challenge for the future. But that’s not the only problem, sadly. Before you do any Windows 10 Cumulative Updates, the App Readiness service needs to be running or it will fail the update. So before updates are deployed, the GPO will need to be temporarily reversed – bit of a pain, although you could probably do something clever with a shutdown script, which turns the service back on as the machine goes down for maintenance and then it gets disabled again at startup, maybe (again, I might revisit this bit later).

So the App Readiness service method is doable, but needs a third-party tool to reinstall the apps and is a pain when it comes to updates 🙁 Is there any way to get rid of these unmovable UWP apps out-of-the-box, if you really really wanted to? Well, yes, actually it can be done…but it’s a bit of a hacky mess, to be fair.

First, download psexec from the PSTools suite into your image. Log on as an administrator and fire up an admin command prompt, then run these commands

ren c:\windows\systemapps\Microsoft.Windows.HolographicFirstRun_cw5n1h2txyewy Microsoft.Windows.HolographicFirstRun_cw5n1h2txyewy_BLOCKED

This renames a folder in the SYSTEMAPPS folder, the one that controls Mixed Reality Portal

copy NUL c:\windows\systemapps\Microsoft.Windows.HolographicFirstRun_cw5n1h2txyewy

This will create an empty file with the same name as the folder we have renamed so it can’t come back.

psexec /accepteula -i -s cmd.exe

What this does is launch a command window with SYSTEM privileges. Now run these commands

cd c:\programdata\microsoft\windows\apprepository\packages

ren Microsoft.Windows.HolographicFirstRun_10.0.17134.1_neutral_neutral_cw5n1h2txyewy Microsoft.Windows.HolographicFirstRun_10.0.17134.1_neutral_neutral_cw5n1h2txyewy_XXX

This will rename a set of source folders that seem to be the genesis of the shortcuts in the Start Menu. If you neglect to do this second folder rename (i.e. if you just rename the folder in SYSTEMAPPS and not the one in PROGRAMDATA), you will get a blank icon at the bottom of the Start Menu trying to reference the app.

Now if we log on as another user…that damned MRP is gone 🙂

You can repeat this process for the Connect app by identifying it and repeating the same process we have outlined above. The Connect app is titled Microsoft.PPIProjection_cw5n1h2txyewy, so these are the commands you need:-

ren c:\windows\systemapps\Microsoft.PPIProjection_cw5n1h2txyewy Microsoft.PPIProjection_cw5n1h2txyewy_BLOCKED

copy NUL c:\windows\systemapps\Microsoft.PPIProjection_cw5n1h2txyewy

psexec /accepteula -i -s cmd.exe

cd c:\programdata\microsoft\windows\apprepository\packages

ren Microsoft.PPIProjection_10.0.17134.1_neutral_neutral_cw5n1h2txyewy Microsoft.PPIProjection_10.0.17134.1_neutral_neutral_cw5n1h2txyewy_XXX

So with this in hand, we are now down to the maximum possible strimming of UWP apps that can be done (well, unless you want to take out Edge and Calculator too, but we might need those)

Would I use this second method personally, renaming the folders and setting up dummy ones? Well, actually, no I wouldn’t. Much as though I am loth to see useless stuff like the Mixed Reality Portal cluttering up the Start Menu and wasting valuable logon time as it is dumped on there, fiddling with the Windows 10 app folders does give you problems with updates. The latest cumulative update wouldn’t install if I renamed the SYSTEMAPPS folders prior to doing it – I had to rename them back to their original titles and then make the changes again post-update. Hopefully Microsoft might actually deprecate the Mixed Reality Portal and stop shoveling it in our faces.

So for a summary – use the PowerShell I showed to remove as many UWP apps as possible, tidy up the Start Tiles, but don’t get excited and go with the renaming of folders unless you ABSOLUTELY have some reason for getting rid of the extra shortcuts. If you’re using Ivanti or LiquidWare, you can use the documented method for disabling App Readiness and reinstalling apps on the fly – but you need to find a way to deal with the service because it needs to run when you’re doing updates. If you’re erring on the side of caution, currently the best advice is – get rid of as many as possible, but don’t get trigger-happy, unless you want to have lots of fun updating.

Removing UWP apps from the base Windows 10 ISO

This is also something you can do, if you don’t want to go through the rigmarole we’ve just written up. This method removes the UWP apps from the WIM of the ISO file that you’re using to install Windows 10.

I’d love to take credit for this, but I’ve used the script from Andre Picker (which you can download here) to achieve this.

First, make sure you’re going to run it on a machine running the latest version of DISM in order to service the image. For posterity, I did it from a Windows 10 1803 machine as I expect that would have the latest version of DISM 🙂

Get your ISO file, and extract it out somewhere so you can work on the WIM files (7-Zip is ideal for this). The script you have downloaded from the link above, make sure this sits in the same folder as the install.wim file. In my case, this is \sources.

Within the script there is a whitelist section which will list the apps that are going to be retained. The default version retains Calculator and the Store. This is the whitelist section from the script:-

$WhiteListedApps = @(
“Microsoft.StorePurchaseApp”
“Microsoft.WindowsCalculator”,
“Microsoft.WindowsStore”
)

If you wanted to add another (e.g. Microsoft.WindowsHelp) you would add it as so

$WhiteListedApps = @(
“Microsoft.StorePurchaseApp”
“Microsoft.WindowsCalculator”,
“Microsoft.WindowsStore”
“Microsoft.WindowsHelp”
)

Next, you need to run the downloaded PowerShell script from an elevated session, which as I said previously needs to sit in the same folder as your install.wim file. The syntax is as below

RemoveApps.ps1 -pathtowim c:\folder\sources\install.wim

This will then run through the apps in the install files and remove the ones you specified, leaving those in the whitelist

Once completed, you simply need to save the modified install files back into an ISO file. I normally do this by using ImgBurn, although if you have other software that can create a bootable ISO that will work fine as well. ImgBurn is quite easy to use, just remember to set the options as shown in the two images below

Once this is done, you can use your new modified ISO image to create a Windows 10 device in the usual fashion, but without the UWP apps you have removed.

As noted previously, though, you need to create a custom Start Tiles layout or your screen will look messy as in the above image.

Summary

The above methods allow you to get rid of as many of the UWP apps as you want. The PowerShell methods will get rid of them as much as possible in a supported fashion, whether this be during optimization during a reference image build or actually within the ISO files you’re using for deployment. The PSTools hacking will allow you to chisel out the ones that are tied inextricably to the OS (at least in this version), but I’d really only use this method in non-persistent VDI environments where machines are regularly refreshed and the update process is done on a single golden image. Otherwise, you may give yourself a large overhead of maintenance.

Combining these processes with my article on creating a custom default user profile in Windows 10, and my set of Windows 10 logon optimizations, should allow you to get your Windows 10 image as streamlined as humanly possible.