SCCM – Task Sequence Stuck on Removing Built in Apps

We recently encountered an issue where an SCCM task sequence would randomly get stuck on a custom step we had added to a build task sequence. The custom steps job was to remove some Windows 10 Default Apps such as xbox which were not needed on a corporate build. We could have removed them as part of a build and capture sequence but to keep the process lightweight we included this step as part of the build sequence. You could build the same machine several times and maybe 1 in 5 times you would get the issue so was a real annoyance and pain to troubleshoot.

The task sequence step basically ran a PowerShell script containing the command Remove-AppxProvisionedPackage , you may find several of these scripts online but they all run this command to remove the default apps.

After trying several fixes we eventually came across the update notes for a MS update released in August 2019
This contained the following: Addresses an issue that causes Deployment Image Servicing and Management (DISM) to intermittently stop responding while deprovisioning some preinstalled apps using the Microsoft System Center Configuration Manager (SCCM).

As we were using Windows 10 1809 we immediately set to work applying this fix to our image WIM, there are several methods of doing this but we used the built in SCCM Offline Servicing tool. By this time it was September so we included the September cumulative update (as this contains all the previous months fixes). Note we first manually copied the existing wim to a separate folder as a backup as we have had bad experiences in the past with the offline servicing tool, then made sure the updates we needed had been downloaded to a deployment package (otherwise they wont show up in the offline servicing list of updates). It took a while for our image to apply the updates so we left this running overnight, once finished it was a case of distributing the image (or updating the DP) then making sure the right image was selected in our task sequence as we had added it as a fresh image to SCCM.

We then tested the build again and things were looking a lot more promising after several retries.

Hope this helps!

About the author