How To: Fix SysPrep 3.14 error for Windows 8.1 Enterprise

imageNOTE: This error does not manifest itself in 8.1 RTM. It only affects “Preview” and “Preview Apps”. See comment below for a simpler fix.

I’m in the middle of a project where I am tasked to create a standardized Virtual Machine image for developers based on Windows 8.1 Enterprise “Release Preview”. This image will be used by a variety of people in the form of a Client Hyper-V guest VM, a Boot-To-VHD VM, a VDI pilot and possibly a Windows-To-Go bootable stick.

Sounds easy enough, eh?

Create the VM, install the software, install the updates, let the customer try it out and further customize it and then signoff on it’s configuration.  Once that is all done – Package it up and make it available for use in a variety of forms (as mentioned above).

That would be easy – but there is a bug in the Windows 8.1 Enterprise Preview build 9431 which rears it’s ugly head if you:

  • Install ModernUI apps NOT provisioned for all users (like built in apps)
  • Update ModernUI apps there were NOT provisioned for all users (like built in apps)
  • Let the system run for an unspecified period of time while having internet connectivity and it updates something.

Any of these criteria and you’ll get the Sysprep 3.14 error.

image

If you check the logs at c:windowssystem32syspreppanther (the setupact.log) you’ll see something similar to:

    • 2013-08-02 15:02:17, Error SYSPRP Package Microsoft.WindowsReadingList_6.3.9431.175_x64__8wekyb3d8bbwe was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.
    • 2013-08-02 15:02:17, Error, SYSPRP Failed to remove apps for the current user: 0x80073cf2.
    • 2013-08-02 15:02:17, Error, SYSPRP Exit code of RemoveAllApps thread was 0x3cf2.
    • 2013-08-02 15:02:17, Error, [0x0f0082] SYSPRP ActionPlatform::LaunchModule: Failure occurred while executing ‘SysprepGeneralize’ from C:WindowsSystem32AppxSysprep.dll; dwRet = 0x3cf2

Basically you are out of luck – for THIS image and Preview Release.

My solution for this? Here’s my process for getting SysPrep to work on Windows 8.1 Entperise “Preview Release”. In my case – I am not deploying any Modern UI applications with this image.  If I was – I’d make DAMN sure they were provisioned for ALL users – not just local users, as this seems to be the issue causing Sysprep to fail.

To be specific:

  • Create the machine from scratch (if you are trying to troubleshoot this with an existing image – sorry, it’s a rebuild)
  • Disconnect it from the network / internet connectivity for the install process
  • DO NOT associate it with a Microsoft account at this time – Create a local account. This prevents the Store and ModernApps from updating themselves and breaking SysPrep in this Preview Release.
  • Once at the Desktop, open an administrator privileged PowerShell prompt.
  • Run “Get-AppxPackage | Remove-AppxPackage” at the PowerShell prompt. This will list all default installed Appx packages (which are installed per user) AND since it it piped to Remote-AppxPackage, it will remove them all.
    • you will get RED errors – this is expected due to dependencies.
  • From the Start Screen, right click and UNINSTALL the xBox music app. This app has dependencies with prevent all AppxPackages from being uninstalled
  • Run “Get-AppxPackage | Remove-AppxPackage” at the PowerShell prompt again to ensure all have been removed.
    • you will get RED errors – this is expected due to dependencies.
  • Connect back to the network / internet once again.
  • DO NOT associate a Microsoft Account for the entire time you are finishing this software install. Leave that for the SysPrep process.

I installed Visual Studio 2012, Visual Studio 2013, 20 odd components from Web Platform Installer, 3rd party software AND ran Windows Update for all products on the system.  Once I was all done – ran Sysprep with the Generalize switch and all worked FINE this time around!

PHEW!

Now I can use the VHDX file for a VDI pilot, Boot-From-VHD and Windows-To-Go, all as expected with this Preview Release.

About author View all posts

Rick

11 CommentsLeave a comment

  • This error is caused by an bug in the preview that is caused by a cleanup process that is run 60 minutes after first logon.

  • Same problem with RTM. I spent many hours perfecting this image so I do NOT want to start over. I find it hard to believe that there’s no way to correct whatever causes this bug. Are we 100% sure there isn’t a work around without having to start over? Doing the amount of work I just did over again would be a PAIN.

  • Thanks for this, they better have sorted by official release. Our work is going to deply 8.1 when it is released.

  • Rick,

    Great article, and i am about to check my installation to see if your method will indeed solve this sysprep error that i also encountered.

    BTW, about your remark at the end:
    “Now I can use the VHDX file for a VDI pilot, Boot-From-VHD and Windows-To-Go, all as expected with this Preview Release”
    Do mean that a GENERALIZE IMAGE can be restored to a bootle USB (HD) device, and use it as a Windows-To-Go?

    Cheers
    Charles

  • This is NOT fixed in the RTM version. But there is a work-around. Create a new user account, and delete the profile for the user account you were using to set up the image. That made it work for me without starting over.

    HOWEVER, if you use a Metro app as the new user you create, you’ll brick it again. In my case, if I access the settings to configure a lock screen or user profile image, it will brick it and I have to delete the user profile again.

    Moral of the story: DO NOT access a Metro app while creating an image. Not even to set a default lock screen. If you do, create a new user, and delete the profile for the user you were setting up the image with.

    Microsoft’s brilliance is unmatched.

  • Hey man, nice article. I think that it has been fixed in RTM so long as you do not update any Metro apps. As soon as you launch, the default behavior is to try to update the app as it is a per-user instance.

    • Hi Joe,

      Maybe you missed my comment above. This issue is NOT fixed in RTM. I never updated any Metro apps. In fact, I never even used any Metro apps other than the one to change the lock screen and the other to change the user profile picture. That’s it. RTM is just as broken. Microsoft has yet to fix this.

  • Gents, I had this problem as well, but instead of removing all packages I:

    1. Ran sysprep /generalize /oobe /shutdown /unattend: (note: CopyProfile was set to true)
    2. Ran into another error
    3. Read the sysprep logs, fired up Powershell, queried for the problematic package in question (Get-AppxPackage -AllUsers | Where Name -Like “”)
    4. Once found, took it a step further and ran: Get-AppxPackage -AllUsers | Where Name -Like “” | Remove-AppxPackage
    5. Repeated Steps 1-4 until it successfully went through Generalize.

    Now, in my case, I only ran into 2 errors, which both created the dreaded “0x80073cf2” error in the sysprep logs. The names of those packages as I typed them into Powershell (to the right of “-Like”, between the double quotes) were:

    1. Microsoft.WinJS.2.0.Preview
    2. Microsoft.WinJS.Preview

    Both trace back to the v2 and v1, respectively, WinJS preview packages.

    I’m running my Win 8.1 builds in Hyper-V and took snapshots prior to running sysprep, so it really didn’t take me very long to get back to a safe point and attempt Generalize once more.

    I highly prefer this method over the (IMO) elephant gun approach of uninstalling all packages.

    This was done with Win 8.1 Enterprise, RTM.

  • Hey guys,

    I feel I should chime in here as someone who has experienced this exact issue,
    and, guess what, I know exactly how you do not need to start over and the work around. This bug only occurs if, and only if there is more than one account on the system with active apps. The best way to fix it is first create your very own password protected administrator account. Take note: Windows 8.1 only creates apps for an new account login that is password protected, unless that account appears to be the only account on the system. From this admin account, you can do all of your installs of software and sysprep the system as many times as you need, however, when going through the OOBE, create a local user account WITHOUT a password. It will simply load the welcome screen, and, you can login to your administrator account instead and delete the non-password protected account you just created. Now, if you accidentally hide your admin account, or have it hidden under the “Special Accounts” in registry, or create a password and it opens this new temporary account fully, or, you simply accidentally click and log-onto that account from the Welcome screen, do not worry. All hope is not lost. I know for a fact that from here, if you follow RicksterCDNs instructions, and, remove your admin account from “Special Accounts” (if applicable), afterwards, you can sign out of that temp account, login to your admin account, delete the temp account, and be able to sysprep once again. Just remember, only a single account can have active apps in order to be able to sysprep. If there are any other user accounts on the system with active apps, you will get the sysprep generalization error.
    I hope this helps a few of you.
    Starflare5.


Warning: sizeof(): Parameter must be an array or an object that implements Countable in D:\home\site\wwwroot\wp-content\plugins\projectnami-blob-cache\project-nami-blob-cache.php on line 416

Fatal error: Uncaught WindowsAzure\Common\ServiceException: Fail: Code: 400 Value: The account being accessed does not support http. details (if any): <?xml version="1.0" encoding="utf-8"?><Error><Code>AccountRequiresHttps</Code><Message>The account being accessed does not support http. RequestId:7ea097c1-101e-0007-46d0-a03eca000000 Time:2019-11-22T01:05:50.8987868Z</Message><AccountName>ritgcache</AccountName></Error>. in D:\home\site\wwwroot\wp-content\plugins\projectnami-blob-cache\library\WindowsAzure\Common\Internal\Http\HttpClient.php:382 Stack trace: #0 D:\home\site\wwwroot\wp-content\plugins\projectnami-blob-cache\library\WindowsAzure\Common\Internal\Http\HttpClient.php(275): WindowsAzure\Common\Internal\Http\HttpClient::throwIfError(400, 'The account bei...', '\xEF\xBB\xBF<?xml versio...', Array) #1 D:\home\site\wwwroot\wp-content\plugins\projectnami-blob-cache\library\WindowsAzure\Common\Internal\RestProxy.php(141): WindowsAzure\Common\Internal\Http\HttpClient->send(Array, Object(WindowsAzure\Common\Internal\ in D:\home\site\wwwroot\wp-content\plugins\projectnami-blob-cache\library\WindowsAzure\Common\Internal\Http\HttpClient.php on line 382