none
Sysprep does not run after deploying captured image

    Question

  • I'm using MDT 2012 U1 on Server 2008 R2.  I have a sysprep and capture task sequence which I use a few times a year to capture Windows 7 images.  I then import the image into MDT, add it to a standard client ts which is then used to deploy the image to other client machines.  Most of the time sysprep runs after deployment and the ts finishes fine, but 9 times out of 10 sysprep does not run and the machine ends up at the Windows login screen where I cannot login as local Administrator, it says the account has been disabled.

    Again, I'm using the same sysprep and capture ts and the same standard client ts each time, something just acts up every now and then.  I've read some blogs where people say the sysprep step in the capture sequence is unreliable and that it's best to disable that and run sysprep manually before capturing but I'd like to think the MDT team has it down.  Am I witnessing this bug as well, or am I missing something here?

    Friday, July 04, 2014 8:42 PM

Answers

  • MDT automates the execution of sysprep.exe, but it's not particularly good at reporting errors through return codes. As a result, MDT checks the registry on the machine for a "CloneTag" entry to indicate that sysprep completed; if it didn't, you'll see an error.

    That should detect the majority of sysprep errors, especially around bad drivers and incorrect unattend.xml settings.  But there could be some errors that occur after the "CloneTag" entry is created that MDT doesn't catch.  (The only time I've seen this happen is with apps installed from the Windows Store, but that will always fail.)

    The "bad" images should still have the \Windows\System32\Sysprep\Panther folder that has the Setupact.log and Setuperr.log that should record any problems that might have happened.  Can you look at these to determine if there were any problems?


    Thanks,
    -Michael Niehaus
    Senior Product Marketing Manager, Windows Deployment
    http://blogs.technet.com/mniehaus
    mniehaus@microsoft.com

    Friday, July 04, 2014 10:51 PM

All replies

  • MDT automates the execution of sysprep.exe, but it's not particularly good at reporting errors through return codes. As a result, MDT checks the registry on the machine for a "CloneTag" entry to indicate that sysprep completed; if it didn't, you'll see an error.

    That should detect the majority of sysprep errors, especially around bad drivers and incorrect unattend.xml settings.  But there could be some errors that occur after the "CloneTag" entry is created that MDT doesn't catch.  (The only time I've seen this happen is with apps installed from the Windows Store, but that will always fail.)

    The "bad" images should still have the \Windows\System32\Sysprep\Panther folder that has the Setupact.log and Setuperr.log that should record any problems that might have happened.  Can you look at these to determine if there were any problems?


    Thanks,
    -Michael Niehaus
    Senior Product Marketing Manager, Windows Deployment
    http://blogs.technet.com/mniehaus
    mniehaus@microsoft.com

    Friday, July 04, 2014 10:51 PM
  • Thanks for the reply Michael.  On the machine on which I captured the image C:\Windows\System32\Sysprep\Panther\setuperr.log has just 3 lines:

    2014-07-04 16:05:17, Error      [0x0f0082] SYSPRP LaunchDll:Failure occurred while executing 'C:\Windows\System32\slc.dll,SLReArmWindows', returned error code -1073425662
    2014-07-04 16:05:17, Error      [0x0f0070] SYSPRP RunExternalDlls:An error occurred while running registry sysprep DLLs, halting sysprep execution. dwRet = -1073425662
    2014-07-04 16:05:17, Error      [0x0f00a8] SYSPRP WinMain:Hit failure while processing sysprep generalize internal providers; hr = 0xc004d302

    These seem to be caused by the Windows rearm count running out.  When I check my master using slmgr.vbs /dlv it says "Remaining Windows rearm count: 1", does this mean there's one activation left to be used on the machines which receive this image?

    Our process is probably a bit different than other organizations:

    01. I have 1 physical machine that I always use to create/update my thick image.  I make my changes then capture the image with a ts that does not run sysprep, the steps have been disabled in the ts.  This is a backup image that I can go back to in step 3 below.

    02. I capture the image with a ts that does run sysprep.  In the unattend.xml for this ts SkipRearm = 0.  This is image that I deploy to other machines.

    03. I restore the image that I captured in step 1 to my master when I need to make further changes, usually a couple times a year and then repeat steps 1-2

    This process should work right?  I'm not sure how I'm down to 1 rearm in my master


    • Edited by J. Wall Monday, July 07, 2014 2:22 PM
    Monday, July 07, 2014 2:01 PM
  • Be aware that you can only sysprep an image three times over the lifespan of the image. If the master image you used above was previously syspreped, then this may be the problem.

    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Tuesday, July 08, 2014 3:56 PM
    Moderator
  • Yes, I am aware of that limitation .

    I am not totally sure what fixed my problem but after trying different things with the unattend.xml (trying SkipRearm=1), in both the capture ts and the deployment ts and recapturing / redeploying several times, my image now deploys properly again.  While I would like to understand what fixed it my window of opportunity is closing to get my machines imaged so for now I'm just going to be grateful it's working again.

    Tuesday, July 08, 2014 8:10 PM