Starting with Windows 10 version 1703, you can now remove provisioned in-box apps like Xbox using the MDM platform capabilities built into Windows. (If you think you need to use this to remove Candy Crush, Pandora, etc., stop and read this blog before continuing.) See https://docs.microsoft.com/en-us/windows/client-management/mdm/enterprisemodernappmanagement-csp for the description of the “RemovePackage” method. While ideally this would be available via Intune, it isn’t at this point (and no, you can’t use an OMA-URI for it either because it uses an Exec method, which isn’t presently support by OMA-URI custom policies). But fortunately, it is supported by the Set Up School PCs app (which has a hard-coded list of apps that get removed when you create a provisioning package with this tool) and by Windows Configuration Designer (at least in the version from the ADK for Windows 10 1803).
So let’s set up a sample provisioning package using Windows Configuration Designer. To do this, create a new provisioning package in “advanced” mode, then navigate to “UniversalAppUninstall –> RemoveProvisionedApp.” Once there, you can specify the apps you want to remove using the “package family name.” I specified two that I wanted to remove: the Xbox app and the “Get Office” app‘
So how do you come up with those PackageFamilyName values? That’s where PowerShell comes in handy. For some strange reason, the obvious mechanism of using “Get-AppxProvisionedPackage –online” doesn’t return the PackageFamilyName, but the “Get-AppxPackage” cmdlet does. So use that to get a list. Here’s an example for the Xbox app:
Copy and paste that value into Windows Configuration Designer, click Add, and then you can generate your provisioning package. To install it, you can included it in your image (DISM can be used from Windows PE to stage the package for Windows to process automatically on first boot) or you can install it directly using “Install-ProvisioningPackage C:\Project_1.ppkg”. But if you try it, you’ll find that it does absolutely nothing – because your package doesn’t have any details in it.
Alright, why not? Simple: there is a bug in Windows Configuration Designer, it doesn’t save the values that were entered in the UI for that setting. So on to plan B: Let’s see what the Set Up School PCs app does. Install it from the Microsoft Store, launch it, and specify all the defaults. Eventually, you’ll be asked to insert a USB key; it will create a provisioning package on that USB key. Take that provisioning package (the name of which will start with SetUpSchoolPCs) and copy it to your computer. Rename it from “.ppkg” to “.wim” Then mount it using DISM. From the mounted folder, open the “Multivariant\0\customizations.xml” file with Notepad or your favorited editor. You should see a section called UniversalAppUninstall that is populated with a list of apps to remove (even though the Set Up School PCs app never asked – it always removes these):
Cool, so now how do we get that into our provisioning package without the rest of the Set Up School PCs stuff? Copy and paste of course. But first, make a copy of that customizations.xml file, because it’s easier to remove stuff you don’t want. First, edit it to look something like this:
We could just overwrite our own customizations.xml file with this one, but then it would have the same GUID and other details, so instead just copy the “Settings” section into the WCD customizations.xml file (at whatever location you saved it, typically inside the documents folder), overwriting the existing Settings section. You should then have something that looks the same as the edited SUSPCs file:
(Notice that I shortened the list of apps to be removed, back to my original two sample apps. The SUSPCs list was longer, removing everything that schools want to keep away from students.) Save the changed file, then open it back up in Windows Configuration Designer:
So at least it *reads* the values in, even if it won’t write them. So *now* you can create a provisioning package that will actually do something, then install it using PowerShell:
And presto, the provisioned apps are removed. But they aren’t removed from any existing user, so while the above PowerShell command works fine, it won’t completely eliminate the apps. So it’s better to use the “add to the image with DISM” approach. While you can inject it into your image, it’s better to add it just in time. Assuming you are using MDT or ConfigMgr, you can add a step to the task sequence that runs in Windows PE after the OS has been applied/installed, that runs a command similar to this:
DISM /Image=C:\ /Add-ProvisioningPackage /PackagePath:Project_1.ppkg
Of course you should be more dynamic about it, specifying the path to the OS (which might not be C:\) and to the provisioning package (which could come from a ConfigMgr package and be in the working directory, e.g. “.\Project_1.ppkg”, or could be on an MDT deployment share and referenced via “%ScriptRoot%\Project_1.ppkg”). There are other blogs out there that talk about those approaches, so take your pick.