Yet another way to clean up in-box apps

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.

Comments

• Anonymous
  June 12, 2018
  The comment has been removed
  • Anonymous
    June 12, 2018
    There's never been much of a need to reboot back and forth between PE and the full OS. Why do you want to do it for a provisioning package, when you can install that package directly from PowerShell?
    • Anonymous
      June 12, 2018
      HI Michael - we are using standalone MDT to rebuild Win 7 machines as Win 10 machines and as part of that process, we are converting the BIOS from Legacy to UEFI. Because MDT can't boot back into WinPE, we are forced to lay down the Win 10 OS, install all the apps, then we use the MBR2GPT tool to convert the partition layout to UEFI, then run our HP BIOS conversion steps, and BIOS update steps then restart the machine, and we continue the task sequence in the OS (as MDT does). If we were using SCCM, we could could do the BIOS conversion up front, boot back into WinPE prepare the disk for the conversion to UEFI, then restart back into WinPE, and lay down the OS etc. Thus, we avoid having to use the MBR2GPT tool. As I said, this is not related to provisioning packages per say, but I still wonder why MDT won't support a restart back into WinPE. Thanks, Brendon