none
Sysprep and Capture fails on Sysprep step, Windows 10 1709 RRS feed

  • Question

  • Hi,

    I'm trying to sysprep a VM of 1709 with a sysprep and capture sequence from MDT 2013 (latest version). It fails every time. The error log from sysprep states:

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

    I did run a PowerShell script which removed the garbage Store apps before capture. Removed for both the current user and removed for provision. Yet, sysprep seems to fail on a garbage app that doesn't seem to be there. I cannot see what it is failing on from the Start menu. It doesn't matter which account I try to sysprep from, it fails. I guess the lesson here is to not remove the garbage apps before sysprep. I've put a great deal of work into this VM. Even going back to the last snapshot will require a significant amount of work to get back to where I am. Is this situation salvageable?

    Thanks


    Jason

    Friday, April 13, 2018 2:41 PM

All replies

  • When you build a reference image there should only be one account, the Administrator account.

    Did you disable Store updates as well to make sure apps didn't get updated after you removed them?

    <job id="Config-DisableWindowsStoreUpdates">
    	<script language="VBScript" src="ZTIUtility.vbs"/>
    	<script language="VBScript">
    
    	oLogging.CreateEntry "Getting crrent OS drive letter", LogTypeInfo
    	sSystemDrive = oEnvironment.Item("OSDISK")
    	oLogging.CreateEntry "Current OS drive letter is " & sSystemDrive, LogTypeInfo
    	
    	oLogging.CreateEntry "About to configure Windows Store Update Settings", LogTypeInfo
    	UpdateWindowsStoreSettings(sSystemDrive)	
    
    	Function UpdateWindowsStoreSettings(sSystemDrive)	
    		
    		oLogging.CreateEntry "Unload the offline registry file", LogTypeInfo
    
    		bFound = False	
    		For each sDir in oFSO.GetFolder(sSystemDrive & "\").Subfolders
    			If oFSO.FileExists(sDir & "\system32\config\software") then
    				oLogging.CreateEntry "Trying to load registry file " & sDir & "\system32\config\software", LogTypeInfo
    				iRetVal = oUtility.RunWithHeartbeat("reg load HKLM\NewOS """ & sDir & "\system32\config\software""")
    				If iRetVal = SUCCESS then
    					bFound = True
    					exit for
    				End if
    			End If
    		Next
    		If not bFound then
    			oLogging.CreateEntry "Unable to find the new OS registry file; Windows Store settings cannot be updated.", LogTypeError
    			UpdateDevicePath = Success
    			EXIT FUNCTION
    		End If
    		
    		oLogging.CreateEntry "Setting the AutoDownload registry value", LogTypeInfo
    		oShell.RegWrite "HKEY_LOCAL_MACHINE\NewOS\Policies\Microsoft\WindowsStore\AutoDownload", "2", "REG_DWORD"
    			' 2 = always off
    			' 4 = always on
    			
    		oLogging.CreateEntry "Unload the offline registry file", LogTypeInfo
    		oShell.Run "reg unload HKLM\NewOS", 0, true
    
    		UpdateWindowsStoreSettings = Success
    			
    	End Function
    
    	</script>
    </job>

    With store updating disabled, you should be safe to remove apps during your build.

    To salvage, you will need to try removing that store app from whichever account it is installed on.


    Daniel Vega

    Friday, April 13, 2018 3:09 PM
  • We need a local admin because the builtin administrator account is disabled after imaging. A local admin account not called "Administrator" which is known to everyone on the planet.

    Windows is already installed and configured manually. It has to be done this way to install the metric ton of apps we use and to answer all of the those app's first run settings for the default user. There's dozens of apps that could be removed. I remove one offending title and sysprep fails on a different one. The script to remove them all (script from previous link) won't work. It doesn't error, just carriage return. 


    Jason

    Friday, April 13, 2018 4:26 PM
  • If you look at the picture I posted, that's my TS to create a reference image. At the point that it removes apps, it hasn't even finished deploying the image. All in one single sequence I have it deploy to a VM and capture the image at the end. I add a Suspend Task Sequence to give me a chance to create a checkpoint as well as make any needed manual changes if I wanted to.

    If you do it like that you will only have one account, the administrator account, when it runs the script to remove the apps you don't want. Because I disable store updates I don't run the risk of apps getting updated and causing issues with removal or sysprep.

    Here's a guide Building a Windows 10 v1709 reference image using MDT which also links to the Sysprep issue and disabling store updates.


    Daniel Vega

    Friday, April 13, 2018 9:06 PM
  • I love that website and their tutorials. I've been through their process, but cannot really use it because customization process with all of the apps balloons the profile. I try to keep a very light profile because it takes so long to log into Windows 10. Our PCs do not keep profiles. They're wiped at logoff. Each time someone logs in, they're doing so for the first time even if they did so yesterday or earlier. Windows 10 takes 3x longer to get someone in than did Windows 7. With 7, I had the whole process done in under 30 seconds from Ctrl+Alt+Delete to desktop. Windows 10 with an untouched profile (3-5MB) takes around 1m 15s on an SSD w/16GB of RAM.

    I build in another account, set whatever I cannot set through the registry or GPO, log in as builtin admin, and set it up as the user should have it. Then, I capture after the other user's profile has been removed. Worked fine on Windows 7 and 10 LTSB (No garbage apps). With a deploy and capture type sequence, audit mode takes days with all of the apps that need to be installed. Many of which are huge.


    Jason

    Friday, April 13, 2018 10:24 PM
  • Not sure what to tell you because with my image a first time login takes 20 seconds or less. The only time it gets anywhere close to a minute is on older hardware with a 5400rpm drive.

    I've built my images based off of Johan's guides since 2012. My Windows 10 reference image has Office, I remove some store apps and also add all the Visual C++ restributables. During imaging to the client is when I deploy all the other software. Most deployments over our 100Mbit network take about 35 minutes to complete. It will be much faster when we finally upgrade our switches to gigabit. 


    Daniel Vega

    Tuesday, April 17, 2018 2:06 PM
  • Ask and you shall receive: https://blogs.technet.microsoft.com/mniehaus/2018/04/17/cleaning-up-apps-to-keep-windows-10-sysprep-happy/

    Jason

    Wednesday, April 18, 2018 1:27 AM
  • I probably haven't seen this issue because I use HideShell=YES and I was already using the script to Disable Windows Store updates during my reference image build.

    Daniel Vega

    Wednesday, April 18, 2018 1:43 PM