Resolving Sysprep problems with App-X packages (Part 1)
Deploying applications can be a complex subject given the variety of ways this can be achieved in Microsoft Windows environments. Things sometimes go wrong and can be hard to fix and it's helpful to hear how seasoned IT experts have struggled to resolve similar problems. In this short series of articles Mark Van Noy we lead us through a real-world difficulty he faced with Sysprep and how he resolved it. Mark is a Technical Lead/Architect at the University of Colorado Boulder in the Greater Denver Area, and as an Information Technology generalist he thrives on architecting new tools and services in ways that allow his customers to realize gains in efficiency, productivity, and cost savings while ensuring that IT remains a division that provides a competitive advantage. For more information on Mark visit his LinkedIn page. Let's now hear from Mark as he outlines the challenges he was facing and provides some detailed steps about he got things working properly. In this Part 1 article Mark will provide some background info and describe the nature of the problem he was facing. Then in Part 2 he'll explain how he solved his problem using some Windows PowerShell scripting.
App-X packages, introduced with Windows 8, can cause images to fail to Sysprep if any of the packages that install by default in Windows have been removed. This includes Candy Crush Saga. There are innumerable reasons a business may want to remove specific apps that ship with Microsoft Windows. As long as no updates are applied after the apps are removed then the computer can be Sysprepped for capture just fine. If any of the apps get updates from Windows Updates before Sysprep then there is a high probability that the Sysprep will fail with an error that an app is still provisioned for one or more user profiles, but not all profiles.
With the introduction of Windows 8, Microsoft began promoting their new app publishing technology that has been called Metro Apps, Windows Native Apps, and App-X Apps at various times by Microsoft. For the remainder of this article these apps will be referred to as App-X packages because the PowerShell cmdlets that are used to manipulate what is installed call them App-X packages.
App-X apps seem to have received a bit of a lukewarm reception due to the perception that App-X apps were geared toward a tablet interface and that they were tied solely to Microsoft's new App Store. Since the release of App-X applications, Microsoft has announced that companies can develop their own App-X packages that may be deployed through their own onsite store if they choose. App-X apps are also better suited for modern display technology than conventional desktop applications. For instance, App-X apps are designed to handle the scaling necessary to make an app highly useable on high PPI displays without having UI elements such as icons become too tiny to use. In fact, a simple Powershell query, (Get-AppXProvisionedPackage -online).DisplayName, shows that OneNote, Skype, Photos, Calculator, and SoundRecorder are now App-X apps.
What makes App-X apps problematic is that they are different. They are managed either through the Windows Store, which is itself an App-X app, or through PowerShell cmdlets. The management of these apps has to be performed at both the system and the user level. User provisioning cannot be managed as an administrator; the commands must be executed within each individual user's profile. Perhaps the most important difference is that provisioning of apps is managed in a SQLite database. For most IT departments these differences are likely going to be perceived as pain points despite the Windows Store model opening the opportunity for end user self-service.
Most IT departments are going to want to remove specific App-X apps from their master gold image so that non-business related apps are not being imaged out to the entire enterprise. A perfect example is the aforementioned Candy Crush Saga, which Windows 10 has provisioned to every Start Menu. Most businesses are likely going to want to remove the games from Windows 10 like Candy Crush or the Solitaire App-X apps.
When App-X applications are removed from a user's profile with the Powershell Remove-AppXPackage cmdlet the app is also removed from the SQLite database. If Windows Update then updates the app the database may also get updated to indicate that the app is now assigned to a user account even if no such assignment has been made. If the database gets out of sync through Windows Update then apps may be published to user profiles that do not exist. To complicate matters, the SQLite database schema does not utilize user GUID's, though there are fields in some tables for UserSid which is always an empty BLOB, and instead uses an internal numbering system starting with one. It appears that the database assigns values to user accounts based on the order they are created on the computer. In some cases it is possible to assign a rogue app to an account that does exist in order to issue the Powershell command to remove it.
The first figure here shows an example of the state of the SQLite database for App-X packages from a computer that fails to Sysprep:
The StateRepository-Machine.srd database file's PackageUser table shows that application 14 is published to users two, three, and four. Form a bit of experimentation, user one looks to be the local Administrator account, user two is the local interactive account on the computer, user three does not actually exist, and user four is a non-interactive account that may be SYSTEM. Counting the Administrator account, there are only two interactive user accounts on this computer and it is not joined to a domain.
When Sysprep is called it will attempt to verify that no existing profile has an app published to it that is not published to all the profiles. In order words, all the accounts on a system have to be completely in sync with one another in regards to their App-X apps. If any account has an app published to it in the database that is not published to all the other accounts then Sysprep will fail with an error in the %WINDIR%\System32\Sysprep\Panther\setupact.log stating that whatever app it was checking exists in some accounts, but not all accounts.
An example of this process failing is seen in the next figure:
These examples are taken from the same computer as the database from figure 1. Figure 2 shows the ambiguous error message that Sysprep generates when any number of applications are published to a user account, but not all user accounts. This error can be legitimate if any combination of apps and profiles are not in sync in regards to what apps are published to what profiles. However, in this case the error is coming up because the database sees some apps published to a user account that does not exist. Based on the expressed behavior, the database does not make any attempt to verify that the accounts it thinks exist on a computer match what the Registry database is tracking.
As can be seen from the next figure, the setupact.log will describe what app is blocking the Sysprep from continuing:
In this case the blocking app is the WindowsSoundRecorder. If the app was not published to a non-existing account then the log would simply be letting the system administrator know that they need to either unpublish the WindowsSoundRecorder app from all accounts or make sure it is published to all accounts. Note that the log does not tell system administrators which user account or accounts the app is not provisioned for. Also, Sysprep stops checking to see if apps are out of sync as soon as it finds any app that is out of sync, so correcting the app that is currently reporting a problem does not mean that the next attempt at running Sysprep will not fail on another app. Referencing back to Figure 1, both apps 14 and 15 are provisioned to user three. In this case, there were twenty-two apps published to this non-existent user account.
To Be Continued
In Part 2 of this article Mark will explain how he solved his problem using some Windows PowerShell scripting.