Windows 10 – AppX Packages Can Break Sysprep

      10 Comments on Windows 10 – AppX Packages Can Break Sysprep

win10appx2

Metro Apps, Modern Apps, Windows Store Apps, AppX, Universal Apps.  Whatever you want to call them they have become a substantial part of Windows.  If you’re having trouble understanding how they work and why, you are not alone.  If you’re interested check out this quick read that may help clear things up a bit here.  Some AppX Apps are the Tiles you see on the Start Menu or in the list that come preinstalled or even automatically installed by the Windows Store.

As the title suggests, if not handled properly these Apps can cause Sysprep to fail.  Sysprep in Windows 8 and 10 has a validation mechanism that checks each of these installed Apps and determines if they’re provisioned for All Users or if they’re just installed for a single user.  If for some reason you remove provisioning on an app that was installed for a user (VMware OS Optimization Tool comes to mind, but more on this later) it can cause the validation to fail and Sysprep won’t succeed.

Building the Windows 10 Enterprise base image

Building a Windows 10 Enterprise image for Horizon View persistent desktops I ran into this issue.  Of course for non-persistent desktops this isn’t as big of a problem in most cases because you would probably be using Quickprep instead.  There are certainly a number of cases where you would also want to run Sysprep on a non-persistent image though.  So the following scripts could still be valid depending on your needs.

To give you the rundown I built a new VM and installed Windows 10 Enterprise.  Performed some basic optimizations on the VM and the OS.  I installed Windows 10 using the latest ISO available (Windows 10 – Version 1607) and got it updated through Windows Update.  I ran the VMware OS Optimization Tool (OSOT) and had it remove all the Windows Apps on the Administrator profile (This is where I seemed to have caused the problem).

Note: Using the VMware OS Optimization Tool fling is highly recommended and in fact VMware’s own Horizon View Optimization Guide is solely based on it.  ITuDA.com also has a pretty comprehensive article on the recommended steps for further optimizing a Windows 10 base image here.

I built a Guest Customization Spec for Windows 10 in vCenter.  I took a number of snapshots in between changes to the base image in case it went wrong I had something to fall back on.  I cloned to template and then deployed a VM from that template using the guest spec.  The VM booted, got an IP address and then never joined the domain.  I went to investigate and found the script ran from Task Scheduler but didn’t appear to complete.  After digging around for a while I checked the Sysprep logs and found the problem which looked something like this.

This basically says that Sysprep failed because one of the packages was provisioned for one user, but not for all users and apparently Sysprep doesn’t like that.  The problem as far as I could see comes from running the VMware OSOT and telling it to remove the Windows Apps I didn’t need.  What also threw a wrench into the mix was the Windows Store now apparently automatically updates installed Apps and installs a number of additional Sponsored Apps like Duolingo, Flipboard, Eclipse, Wunderlist, Candy Crush and the list can go on.  These apps aren’t removed from provisioning using the VMware OSOT.

Why am I getting these Apps on Windows 10 ENTERPRISE?

Microsoft is allowing Sponsored Apps to be installed through Windows 10 Store Auto-Update even for Enterprise editions of Windows 10.  You have the option to disable them through GPO, registry or AppLocker as detailed here.  You can also opt to use the Windows 10 LTSB (Long Term Servicing Branch) edition, since it doesn’t include Edge, Windows Apps (AppX Apps) or the Windows Store at all.  The Windows 10 LTSB doesn’t get feature updates like the Current Branch though, which could potentially cause a whole other set of issues depending on your environment and required frequency of updates.  To top all that off, Microsoft recommends to use the LTSB only for specialized systems like Kiosks, ATMs, POS systems and the like.

It just seems like these extra steps could have been avoided by Microsoft especially on a business centric edition of their OS, but I digress.  If you don’t use one of those methods and you manually remove the Apps via the Start menu be ready to do it again when the Windows 10 Store Auto-Updates and the next round of Sponsored Apps gets installed.  You can of course disable the Windows 10 Store Auto-Updates through GPO or through registry edits.  Unfortunately this doesn’t fix the Microsoft default AppX Apps that are installed natively and we will have to use PowerShell to clean that up.

How do I fix this mess?

Fumbling around for a while I found the specific Windows App that Sysprep was complaining about.  I tried manually removing that App using Powershell, which I will detail below.  I ran Sysprep again and surprise, it now complained about another of the Windows Apps being non-compliant with Syspreps validation features and it failed.  Time for another approach.

Microsoft has published KB2769827 that has some detail on why this happens and how to remediate it.  In my case I didn’t want to completely remove provisioning of these Windows Apps for new users.  I just wanted to make Sysprep work properly so I adjusted a bit of their resolution to fit my needs.

Option 1: Choose what you want to remove for Persistent desktop images

First we have to get a list of what Windows Apps are installed.  Login to the Windows 10 base image as local Administrator, open an elevated Powershell instance and run the below command.

This commands output will return PackageFullName and the local user accounts that the Apps are installed on and will look something like the below image.  I deviated from Microsoft’s resolution at this point because they detail looking for a specific PublisherId and I found that several of the Windows Store installed Windows Apps that were causing havoc with Sysprep don’t fall under that specific PublisherId.  Taking out the PublisherId qualifier forces the command to return ALL installed or provisioned Windows Apps and not just the ones with that PublisherId.  Results may vary a bit as I saw many articles of people talking about Candy Crush Saga and many other “Apps” that were installed via Windows 10 Store Auto-Update that I somehow didn’t have installed at all.

ps1output

Previously I mentioned manually removing the individual App that was initially causing Sysprep to fail using “Remove-AppxPackage -Package <packagefullname>”, however as soon as I did that another App caused Sysprep to continue to fail.  From here I decided to just remove all of the questionable apps but leave provisioning alone for now.  I put together a quick Powershell script including the PackageFullName of all of the installed Apps from the above list.  I left out the somewhat obvious System related packages, the Store, anything that was in Staged status and things like VCLib or .Net related Apps.  There were a few I was unsure of which I also left out and those didn’t seem to break Sysprep luckily.

You will need to set the Execution Policy in Powershell to allow you to run the script first.

And after you run the script you should set it back.

Here’s the script.  Copy the below to a text file and save it as RemoveAppXPackages.ps1 or something like it.  CD to the directory you save the script to and run it using “.\RemoveAppXPackages.ps1”.

You may have to adjust this according to what’s in the list you generate from the first Get-AppxPackage command of course.  Of note, this may change due to whatever Sponsored Apps Microsoft decides to deploy through Windows Store Auto-Update in the future as well.  The Sponsored Apps section is just there to show you how it’s done.  You will have to adjust it to whatever is installed at the time.

You will also notice I didn’t include the complete PackageFullName as returned from the first Get-AppxPackage command like the below example.

The reason for this is the returned AppX Package versions can change.  So if I were to build a script using a PackageFullName like “Microsoft.Messaging_3.19.1001.0_x86__8wekyb3d8bbwe” and tried to use it later it may fail because these AppX apps can and probably will be updated frequently.  By using “Get-AppxPackage *Microsoft.Messaging*” we’re asking PowerShell to return the AppX package with wildcards and the rest of the command ” | Remove-AppxPackage” finishes the process by removing that AppX package regardless of the version number or PublisherID behind the AppX Package name.

If you choose you can completely remove provisioning for some of the AppX Apps using the following command as well.

This will make it so these Apps don’t install at all under new user profiles that get created.

After running the Powershell script I tested Sysprep and it worked without issue.  At this point I took a few steps back since as I mentioned I was building persistent desktops and didn’t want to do all of this manually every time.  I added the script to the base image, ran it and took a snapshot.  I cloned the base image to a template and then deployed new Windows 10 persistent desktops from the template using the Guest Customization Spec.  They deployed flawlessly and joined the domain as expected.

Option 2: Remove unnecessary AppX packages from Non-Persistent Images

After working through this with Persistent desktops I found I also wanted to remove some of these AppX apps from Non-Persistent desktops as well.  So I created a script for that as well.  This one will also remove Provisioning of the AppX packages so they don’t reinstall themselves.

You will need to set the Execution Policy in Powershell to allow you to run the script first.

And after you run the script you should set it back.

Here’s the script.  Copy the below to a text file and save it as RemoveAppXPackagesProvisioning.ps1 or something like it.  CD to the directory you save the script to and run it using “.\RemoveAppXPackagesProvisioning.ps1”.

You may have to adjust this according to what you want to remove.  Above you’ll notice the second section runs some different commands.  These will remove Provisioning for the AppX packages listed so they won’t reinstall.  If you decide not to remove a particular AppX Package you will need to remove the AppX Package from both sections or you may break things.

Removing Sponsored Apps

You’ll also notice I didn’t include any Sponsored Apps in this script.  On my Non-Persistent desktops I’ve enabled the GPO that will disable Windows 10 Store from installing or updating Sponsored Apps.  The Sponsored Apps don’t appear to have Provisioning Packages like the built-in Microsoft AppX Apps do.  I found the best way to remove the Sponsored Apps you don’t want is to just Uninstall them from the Start Menu manually on your base image.  Just Click the Start Menu, Right-Click the Sponsored Apps you don’t want and Click Uninstall.  Doing that along with implementing the GPO should stop them from coming back.

I need an “It’s Complicated” status for my feelings about Windows 10

Windows 10 is great!  It’s boots up fast.  It performs well on all kinds hardware.  It’s really fast on VDI.  It’s pretty rock solid when configured properly on stable hardware.  It has great multi-monitor support.  And the list goes on…

Windows 10 is terrible!  It sends data all over the place to MSFT.  It is difficult to truly disable all the telemetry and monitoring.  It won’t let me control how I update my machine.  It at some point just automatically installs updates and reboots itself.  It won’t let you turn some things off.  And it’s really tough to use for VDI without a LOT of work.

The Start Menu, Quick Launch, Windows Apps and MANY other settings are now being stored in Jet Blue databases and not in the registry or the file system.  The AppX Apps are now critical to the usability of the OS in some cases.  It’s like Microsoft is actively making it harder for admins  to manage and customize their desktop OS.  I’ll be writing an article soon on how to overcome many of these problems when using Windows 10 for Horizon View.  For now I hope this article at least helps you get Sysprep working.  Great Success!

10 thoughts on “Windows 10 – AppX Packages Can Break Sysprep

  1. James King

    Hiya,

    I really appreciate your post, But i am having an on-going saga.

    When I do the Applist, i still have a bunch on there if i try and manually say remove Windows.ContactSupport as a provisioned package i get an error:
    The System cannot find the file specified.

    Any ideas?

    Reply
    1. Shawn Post author

      So first I would normally have you do a “Get-AppxProvisionedPackage -Online | fl DisplayName” and that will show you what Provisioned AppX Packages are available. Unfortunately in this case “Windows.ContactSupport” is a System App and cannot be removed. You can see which are System Apps by going to “C:\Windows\SystemApps”. You have to be careful removing AppX Packages because in some cases it could negatively affect your OS, which is why I avoided anything that wasn’t obvious or that didn’t have a corresponding Provisioned Package in my script. Thanks for visiting and I hope the article was helpful!

      Reply
  2. dragonspeed

    I have a similar problem – it tells me that some variant of EclipseManager is blocking my sysprep but there is no listed appx that has “*eclipse*” in it’s name 🙁

    Reply
    1. Shawn Post author

      I just downloaded Eclipse Manager from the Store to test. It does have an AppX Package but not a Provisioning Package. It’s a Windows Store Sponsored App. You should be able to just uninstall it from the Start Menu or run “Get-AppxPackage | fl Name,PackageFullName” to see the list and then Remove-AppxPackage the Eclipse instance you find per the instructions in my post. Good luck and let me know if that helps.

      Reply
      1. dragonspeed

        The error when trying to sysprep is:

        [code]
        2017-01-17 14:30:28, Error SYSPRP Package 46928bounde.EclipseManager_2.1.0.21_neutral__a5h4egax66k6y was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.

        2017-01-17 14:30:28, Error SYSPRP Failed to remove apps for the current user: 0x80073cf2.

        2017-01-17 14:30:28, Error SYSPRP Exit code of RemoveAllApps thread was 0x3cf2.
        [/code]

        But

        [code]
        Get-AppxPackage |? PackageFullName -like “*eclipse*”
        [/code]

        returns nothing, leaving me in a bit of a bind….

        Reply
        1. Shawn Post author

          Try the following

          Import-Module Dism
          Import-Module Appx
          Get-AppxPackage | ? PackageFullName -like *eclipse*

          Without the quotes should do it. Again please check the Start Menu and see if it’s listed there. If it is you can just Right-Click and Uninstall from there. If not you can also check if you happen to have logged in under another user account and the AppX package is installed there.

          Reply
          1. dragonspeed

            This thing hates me… I’m going to start over. All we did was install a new W10v1607 on a VM. We then installed basic applications like Office 2013 and a few other normal Win32 applications. At no point did we install ANYTHING from the cursed Windows App store. We’ll try again. Thanks, at least for pointing us in the direction that we needed to look.

          2. Shawn Post author

            As I mentioned in my post, the Windows Store will automatically install Sponsored Apps, without consent. You can stop it from doing so through GPO if you want or through a manual regedit.

          3. dragonspeed

            Thanks – when I started from scratch and was really careful about doing as little possible, it all worked. Glad though, that you had this post – made me think about what I was doing.

  3. Jonathan Reid

    Had the same error with Sysprep while working in MDT. I found a work-around solution for this from Johan Arwidmark over at Deployment Research. There’s a script he offers that disables Windows store updates. You can then re-enable them once you are finished with whatever you are doing. Have a look. The answer is way down at the bottom of his post. hope this helps someone here.

    http://deploymentresearch.com/Research/Post/615/Fixing-why-Sysprep-fails-in-Windows-10-due-to-Windows-Store-updates

    Reply

Leave a Reply