none
MDT2012 won't Sysprep

    Question

  • MDT2012 will not Capture/Sysprep from within Windows using the default Capture Sysprep TS. Receiving Exec Sysprep failure message "Incorrect Function". Originally my issue was related to a deployment failing the State Restore phase, but I tracked it back to a failed Sysprep after the update to MDT2012.

    Below is my original post and findings...

    --------

    Since I upgraded to 2012 I recently noticed my that my captures do not display the "task sequence finished successfully" message and that my C: drive still had files _SMSTaskSequence or w/e it's called still present.  I also had to modify my capture task sequence adding a registry entry for Clonetag, or my sysprep would fail in a few seconds. The capture appears to be working now however...

    Regarding the State restore issue, here I am 1 week later having tried everything except uninstalling MDT from the server starting from scratch. Most recently I modified my image to reset all Domain policies at the possibility that CTRL+ALT+DEL or the Legality message was preventing auto-login. So I assume the system has to have autologin to be able to execute LITETOUCH.WSF...or wait, was it LTIBootstrap.vbs??? That's certainly the question...I'm comparing a functioning TS/Unattend.xml created under MDT2010 that references "cscript.exe C:\MININT\Scripts\LiteTouch.wsf /start in the Unattended file . This is located in step 7 oobeSystem (edited through the deplyoment work bench). Now in the new Unattend.xml I see: "wscript.exe %SystemDrive%\LTIBootstrap.vbs" in the same place. Anyone know what's going on with the different file references? The .vbs does appear to be one of the files left over sitting on the C: drive. I'm desperate for a solution so I just built a task sequence that references the .WSF file for giggles. Nextup I'll but all of the references in there however I'm still thinking that the auto-login is not processing correctly. Any ideas?




    • Edited by LoXodonte Sunday, August 25, 2013 11:22 PM
    Sunday, August 25, 2013 6:10 AM

Answers

  • Got it resolved. The problem was due to a capture that did not properly execute sysprep before capturing the image. Sysprep did not run because a modification had occured in a core LiteTouch script in order to work past a Clone-Tag issue in Windows 8. I commented a line out back in April and had completely forgotten about it. Bad bad idea. Ultimatiely after I reployed my virtual from VM, sysprepped and recaptured, deployment went the smoothest it ever has...except for an unattend.xml error due to IE10 Welcome startup. Sheesh...what a weekend, now back at work. CHEEERs.

    • Marked as answer by LoXodonte Monday, August 26, 2013 6:07 PM
    Monday, August 26, 2013 6:07 PM

All replies

  • I see now that the vbs more or less finds litetouch.wsf and runs it, so my issue remains either auto-login, or perhaps I need to manually map to the LTIbootstrap instead of %SystemDrive%...

    something else I just noticed, while I did put in the admin password for AutoLogon, I noticed there is another UserAccounts Admin password that was populated with garbled text. I added the password there and about to test again.

    Sunday, August 25, 2013 6:26 AM
  • I'm running out of ideas, I wondered why the password field appeared garbled well it was because "Hide Sensitive Data" was checked the the Unattend editor in the deployment work bench. (Windows System Imaage Manager). The weird thing was that other task sequences showed the same fields as plain txt, one's created with 2010. Even stranger is that one of the passwords in the 2012 TS still viewed as plain txt.

    I hoped that perhaps that was the root of my issue so disabled Hide Senstive Data and edited unattend updating the Admin password. Weird thing is, the more I got to thinking about it I don't think Admin autologin has ever worked. The way I remember it is right before state restore, the machine would be sitting at the login screen, as soon as I login it would resume LiteTouch.

    What I have found is if I I manually launch the LiteTouch vbs that is in C:\, it removes the VBS file and nothing else appears to happen until reboot. The next time I reboot I am sitting once again at the login screen. I login, then the lite touch resumes, performs cleanup, then reports 0 errors in summary.

    What I have found particularly strange is when I go to a run prompt after all of this, and it remembers the last address I entered, which is the deploymentserver. Shouldn't this be cleared on format??

    Sunday, August 25, 2013 2:52 PM
  • In BDD.log I found:

    The syspre.inf file was not found.

    also

    The unattend.txt file was not found.(but it found it on the UNC deployment share and copied to V:\

    that was followed by several No value entries.

    It seems as though I'm still having issues with Partions or drive label names getting mixed up?

    BDD.log

    Sunday, August 25, 2013 6:21 PM
  • You should not be doing any of the changes you have made so far, something is seriously wrong in your image or deployment share.

    For troubleshooting purposes, create a new deployment share, add a plain vanilla Windows 7 SP1 image from Microsoft, create a task sequence, update the deployment share, and verify that the deployment works. Then take it from there.

    / Johan


    Regards / Johan Arwidmark Twitter: @jarwidmark Blog: http://www.deploymentresearch.com FB: www.facebook.com/deploymentresearch

    Sunday, August 25, 2013 7:13 PM
    Moderator
  • I image is being captured from a virtual, the same virtual used previously with win 2010 without issue just some software updates from Symantec added to it. I don't think

    What changes should I not be doing? Clonetag seems to be a well covered issue for many during capture. Autologin troubleshooting is also pretty common during the State Restore phase.

    You do have a good suggestion to to try the same TS with a different image, I have a vanilla and our WIM captured under MDT2010. Will see what results I get from that...

    Sunday, August 25, 2013 8:31 PM
  • successful deployment with a wim captured from MDT 2010, and a TS from 2012. So apparently my capture TS is broke and clonetag did nothing more than suppress an error message. Now that I've watched a successful deployment I think I realize that MDT is not actually sysprepping in my new capture sequence.
    Sunday, August 25, 2013 8:56 PM
  • When trying to Capture within windows  the default Capture  task sequence returns FAILURE to run the action: Execute Sysprep Incorrect Function
    Sunday, August 25, 2013 9:23 PM
  • Don't use the capture only task sequence, it's not very reliable in MTD 2012 Update 1 or MDT 2013 preview.

    Use the full build and capture task sequence (standard client task sequence), and if you need to do something manually in the ref image, add the LTISuspend.wsf option.

    As far as syspre issues goes, antivirus software in the ref image is a no-no, there is no single more common reason for sysprep to choke and die.

    / Johan


    Regards / Johan Arwidmark Twitter: @jarwidmark Blog: http://www.deploymentresearch.com FB: www.facebook.com/deploymentresearch

    Sunday, August 25, 2013 9:28 PM
    Moderator
  • AV shouldn't be the problem although that's probably a good rule of thumb. In this instance I was originally building a DVD image so I had to keep the size down so SEP was the first app I uninstalled.

    The issue remains the failed execution of Sysprep. I don't know if LTISysprep.wsf is even getting executed, it almost sounds like a credential issue from the error I receive: "Failed to run the action: execute Sysprep, Incorrect function .. Source Windows

    And then I wonder what changed with the LTISysprep in the MDT2012 release, because it is the most recently modified file in my scripts folder...

    Sunday, August 25, 2013 11:18 PM
  • Well, most times I have seen Sysprep failing with MDT 2012 Update 1 it has been because one or more of the following conditions:

    1. Using a physical machine instead of a virtual machine

    2. Having Antivirus software in the reference image

    3. Using the (buggy) Capture Only Task Sequence, instead of the standard build and capture

    So, use Hyper-V or VMWare for your ref-image (don't use Virtualbox), don't include Antivirus software, and use the standard client task sequence for your build, sysprep and capture process.

    / Johan


    Regards / Johan Arwidmark Twitter: @jarwidmark Blog: http://www.deploymentresearch.com FB: www.facebook.com/deploymentresearch

    Monday, August 26, 2013 11:12 AM
    Moderator
  • Got it resolved. The problem was due to a capture that did not properly execute sysprep before capturing the image. Sysprep did not run because a modification had occured in a core LiteTouch script in order to work past a Clone-Tag issue in Windows 8. I commented a line out back in April and had completely forgotten about it. Bad bad idea. Ultimatiely after I reployed my virtual from VM, sysprepped and recaptured, deployment went the smoothest it ever has...except for an unattend.xml error due to IE10 Welcome startup. Sheesh...what a weekend, now back at work. CHEEERs.

    • Marked as answer by LoXodonte Monday, August 26, 2013 6:07 PM
    Monday, August 26, 2013 6:07 PM