You are here:   Research
  |  Login

Welcome to my blog, quickest way to find articles is usually to search for them.

Search in All Title Contents

Fixing why Sysprep fails in Windows 10 due to Windows Store updates

Apr 13 2017

When creating reference images for Windows 10, Sysprep is going to fail if the machine have Internet access, and have enough time to start updating it’s built-in applications. This post is about preventing that from happening, and is a companion to uber-guide on building Windows 10 reference images in the real world:

Building a Windows 10 v1607 reference image using MDT

The issue is explained in a KB from Microsoft, but it’s workaround are not very good for automation purposes.

Sysprep fails after you remove or update Windows Store apps that include built-in Windows images

Note #1: This is a quite long post, and if you just want the fix, scroll to the end, to the Fixing the problem section. But if you want to pick some background info, and possibly learn something new in the process, continue as you were :)

Note #2: I have seen a few other workarounds, including temporarily disable/enable Internet access etc. but this post takes care of the problem once and for all :)



If modern apps in Windows 10 are being updated during the build and capture of a reference image, Sysprep may fail because it cannot remove the update. Note that this doesn’t happen all the time, it’s a timing issue, but it sure happen often enough to be an issue.

If that happens you will get the following error in the BDD.LOG and LTISysprep.log log files:

Expected image state is IMAGE_STATE_GENERALIZE_RESEAL_TO_OOBE, actual image state is IMAGE_STATE_COMPLETE, sysprep did not succeed.
FAILURE ( 6192 ): ERROR - Sysprep did not complete successfully, check C:\windows\system32\sysprep\panther\setupact.log for details


Then, in the C:\Windows\System32\Sysprep\Panther\setuperr.log you see the following (or similar):

Error                 SYSPRP Package Microsoft.DesktopAppInstaller_1.0.1471.0_x64__8wekyb3d8bbwe was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.
Error                 SYSPRP Failed to remove apps for the current user: 0x80073cf2.
Error                 SYSPRP Exit code of RemoveAllApps thread was 0x3cf2.
Error      [0x0f0082] SYSPRP ActionPlatform::LaunchModule: Failure occurred while executing 'SysprepGeneralizeValidate' from C:\Windows\System32\AppxSysprep.dll; dwRet = 0x3cf2
Error                 SYSPRP SysprepSession::Validate: Error in validating actions from C:\Windows\System32\Sysprep\ActionFiles\Generalize.xml; dwRet = 0x3cf2
Error                 SYSPRP RunPlatformActions:Failed while validating SysprepSession actions; dwRet = 0x3cf2
Error      [0x0f0070] SYSPRP RunExternalDlls:An error occurred while running registry sysprep DLLs, halting sysprep execution. dwRet = 0x3cf2
Error      [0x0f00d8] SYSPRP WinMain:Hit failure while pre-validate sysprep generalize internal providers; hr = 0x80073cf2

 Error from MDT when sysprep fails
This is what it looks like during the MDT build and capture process.


More Details of the modern apps

Now, the above log is quite obvious, an app named Microsoft.DesktopAppInstaller_1.0.1471.0 was being installed or updated, and Sysprep could not remove it.

To see which modern applications that you have in your system, for the Administrator user account in this case. You can just run Get-AppxPackage in a PowerShell prompt, or (Get-AppxPackage).count to see the number of apps. For a Windows 10 v1607 CB machine, that did not update any built-in updates, I had 54 apps installed. Whereas as system which had been allowed to update them had 58 apps.

A Windows 10 v1607 CB machine with no updates allowed, showing 54 apps.

A Windows 10 v1607 CB machine with updates allowed, showing 58 apps.


But what about apps being actually updated? Well, you can get additional info via the Event Viewer. You go to Microsoft / Windows / AppXDeployment-Server / Microsoft-Windows-AppXDeploymentServer / Operational and filter on Event ID 478 to see successful updates.

The Event Viewer with a filter on ID 478 showing installations of modern apps.


More PowerShell

You can also view this using PowerShell, but you have to use the Get-WinEvent cmdlet, because Get-EventLog can handle only classic event logs (System/Setup/Application etc.).  So here is the command to list installations/updates for Windows 10 applications.

Get-WinEvent -LogName "Microsoft-Windows-AppXDeploymentServer/Operational" | Where-Object {$_.ID -eq 478} | Select TimeCreated,Message | Format-Table -AutoSize –Wrap

PowerShell listing of app preventing Sysprep
Using PowerShell to list event log entries of installed/updated applications in Windows 10.

If you compare the count of apps, from the event log, from a system having the apps being updated or not (by simply putting the command in parentheses, and add a .count), you find that a system allowed to have the apps updated will have over hundred of apps, whereas as system with no Internet access, or updates being disabled will have less than hundred.

Below is the out from a system without updates to the modern apps in Windows 10 v1607 CB, a total of 82 entries for the apps. Another machine that I deployed, and allowed it to update, it ended up with 136 entries for the apps.

Count of apps
A Windows 10 v1607 CB machine with no updates, showing 82 entries for apps in the event log.

Count of apps from system with updates
A Windows 10 v1607 CB machine with updates, showing 136 entries for apps in the event log.


Fixing the problem

The obvious fix for the problem is the following:

1. Install a local WSUS server, approve the needed updates, and configure MDT to use it (WSUSServer variable)

2. Then, when creating the Windows 10 reference image, make sure the virtual machine doesn’t have Internet access.

No Internet access means no updates breaking Sysprep :)


But what if the preceding fix is not an option?

What if you need Internet access for other reasons?

Or can’t install a local WSUS server for some reason?

Well, then you can configure Windows 10 not to update the native apps by adding a script that sets the following registry value during the WinPE phase (offline). So that Windows Store updates are disabled even before Windows 10 starts the first time.

Note: I have seen solutions setting this value in running Windows, but I think it’s better to set it offline, in WinPE, before Windows boots the first time.

The registry key set by the script is HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsStore, the value added is AutoDownload (REG_DWORD), set to 2. A value of 2 means always off, and a value of 4 means always on.

Here is the script:

Just copy the script to your deployment share / scripts folder, and configure your build and capture task sequence to run it in the Postinstall phase (WinPE phase).

Command line: cscript.exe "%SCRIPTROOT%\Config-DisableWindowsStoreUpdates.wsf"

Task Sequence configured to disable updates of Windows Store applications during the WinPE phase.



To allow the system to update apps again, you can add this command line just after Sysprep has run, but before rebooting into WinPE for the capture.

reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsStore /v AutoDownload /f


Enabling updates for Windows Store apps again just before the image is captured.

Written by Johan Arwidmark

Happy deployment, and thanks for reading!
/ The Deployment Research team

Ami Casto

Johan Arwidmark

Blog Archive