none
sysprep and caputure using MDT 2010

    Question

  • I am trying to capture a Windows 7 image and after the sysprep completes I receive the following error message: ZTI ERROR: Unhandled error returned by LTIApply: (-2147024784 0x80070070)
    Tuesday, October 27, 2009 5:59 PM

All replies

  • Check the LTIApply.log file...
    Tuesday, October 27, 2009 6:48 PM
  • To further update the issue, it appears the network connection on the windows 7 machine, that I am trying to capture, drops the network connection immediately after the sysprep phase of the task completes.  When the network connection drops the above error message is returned.  Since the connection to the deployment share is lost the task does not create any log files. 

    Here are some details of how I am performing the sysprep and capture.   My deployment share exists on a domian server the machine that I am capturing does not.  I use the net use command to connect to the deployment share to lauch the litetouch.vbs.   The vb script runs without issue and I am able to lauch the preconfigured sysprep and capture task.  Then the computer drops the connection after the sysprep phase not allowing for the task to complete.
    Wednesday, October 28, 2009 2:00 PM
  • You will find the log files in either C:\MININT\SMSOSD\OSDLOGS or C:\Windows\Temp\DeploymentLogs
    Wednesday, October 28, 2009 3:03 PM
  • Sorry looked server side and not local side for error messages.

    <![LOG[Property PE is now = ]LOG]!><time="14:55:21.000+000" date="10-27-2009" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[Microsoft Deployment Toolkit version: 5.0.1641.0]LOG]!><time="14:55:21.000+000" date="10-27-2009" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[The task sequencer log is located at C:\Users\ADMINI~1\AppData\Local\Temp\SMSTSLog\SMSTS.LOG.  For task sequence failures, please consult this log.]LOG]!><time="14:55:21.000+000" date="10-27-2009" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[------  Applying bootable Windows PE image ------]LOG]!><time="14:55:21.000+000" date="10-27-2009" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[LTI applying Windows PE]LOG]!><time="14:55:21.000+000" date="10-27-2009" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[Will boot into Windows PE architecture x64 to match OS being deployed.]LOG]!><time="14:55:21.000+000" date="10-27-2009" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[Copying \\servername\DeploymentShare$\Boot\LiteTouchPE_x64.wim to D:\sources\boot.wim]LOG]!><time="14:55:21.000+000" date="10-27-2009" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[ZTI ERROR - Unhandled error returned by LTIApply:  (-2147024784  0x80070070)]LOG]!><time="14:55:21.000+000" date="10-27-2009" component="LTIApply" context="" type="3" thread="" file="LTIApply">

    I changed the unc path of the deploymentshare to "servername".

    Wednesday, October 28, 2009 3:58 PM
  • It appears that files are not being written to the D: partition.  I have ensured the partition is there and the security rights are correct.  I was able to access the ''source" folder on the partition but there are no files present.  Does anybody have a solution or experiencing similar issues?
    Tuesday, November 03, 2009 4:28 PM
  • I am experiencing the exact same problem.  I connect to the deployment share, run litetouch.vbs, and choose Sysprep and Capture.  Everything looks good but as soon as sysprep finishes it kills my network connections and even my network adapters stop functioning.  When I go to do some troubleshooting they don't even appear in the network adapters list.  They do show up as working in device manager though.
    Friday, November 13, 2009 8:42 PM
  • I too am experiencing this exact same problem.  I have a prepared Windows 7 computer that I want to take an image of.  I manually map to the mdtserver\deploymentshare$ and run the LiteTouch.vbs.  I run a sysprep & capture task sequence that has been created.  The sysprep begins successfully, but then the network connection drops out.  The status is reported as "Media Disconnected" when I type IPCONFIG.  

    What gets me, is that the sysprep & capture process was working before - and now its not. 
    http://www.dreamension.net
    Sunday, November 15, 2009 11:59 PM
  • I'm having the same exact problem with a Windows 7 x64 - after sysprep, the NIC gets knocked out.
    Monday, November 16, 2009 8:39 PM
  • Try not mapping a driveletter... (You will need the updated ZTIUtility.vbs)

    MDT 2010 Annoyances #3 - Bug - Cannot Run Refresh, Replace, Sysprep and Capture
    http://www.deployvista.com/Home/tabid/36/EntryID/109/language/sv-SE/Default.aspx
    Tuesday, November 17, 2009 12:51 AM
  • Is anyone here using Symantec Endpoint Protection 11 in their image?  Taking SEP out of the base image fixed this issue for me.
    Tuesday, November 17, 2009 2:43 PM
  • Just FYI...

    If you do have SEP installed on your image, make sure "Block all traffic until the firewall starts and after the firewall stops" is NOT enabled.
    This will prevent the machine from joining the domain automatically when imaging.
    Tuesday, November 17, 2009 4:41 PM
  • Since I started this thread I will update everyone with what appears to be the issue on my end.  After rebuilding my DeploymentWorkbench server (needed to be done anyways) I recreated the deployment share and the scheduled task.  I started with a newly imaged windows 7 test box and I was able to capture the image without issue.  I tested a second newly imaged windows 7 box and it worked as well.  I tested a third box and midway through the capture I disconnected the network cable to ensure the capture would fail.  I then tried to recapture the image of third box and it failed again with the above error.  I then went back to the other boxes that work previously and try to recapture their images and they failed as well.  It appears to me that you only get one attempt to capture the imageand if it fails for any reason all subsequent attempts will fail as well.  Does anybody know if this is by design or is there something that needs to be performed in order to get subsequent capture attempts to work?  I would hate to have to recreate my custom build from scratch if it fails to capture the first time.

    Thursday, November 19, 2009 2:42 PM
  • Don't know if it's your issue, but c:\minint, c:\_smstasksequence should be deleted before you begin.

    Thursday, November 19, 2009 3:36 PM
  • Another way of dealing with this is to use the new Suspend feature in MDT 2010 Lite Touch.  It will allow you to stop and resume a task sequence, for example to doing some manual steps before sysprep.
    Wednesday, December 02, 2009 9:09 PM
  • I have the same issue, but was able to resolve it by turning off the windows firewall and temporarily disabling SEP on the reference pc... The script ran further without the network disconnect and then I got a nice little Clonetag error... All I can say is Dohhhhh!!!
    Wednesday, December 23, 2009 4:55 PM
  • HAHA - I finally have my answer...
    I turned off the windows firewall, and Disabled SEP, but it still disconnected the network adapter @ the sysprep script....
    My solution was to QUICKLY go into the Device Manager and DELETE the network adapter and then immediately redetect it... The script then was able to continue running and it successfully syspreped this pc...
    Thankfully this issue is behind me.
    ~Anthony
    Wednesday, December 23, 2009 5:15 PM
  • Windows7x64_DeployGuy's solution works, but anyone why this is happening?

    I'm creating my reference image on vmware 7, and I do have SEP installed.
    Thursday, February 04, 2010 1:20 AM
  • I'm also experiencing the exact same problem with SEP 11 RU5 - have SMC service stopped, but network card disappears and sysprep fails. If I don't install SEP everything is golden.  has anyone figured this out yet? I'd really like to get SEP on the image.
    Thursday, April 29, 2010 3:45 PM
  • I talked to a Symantec tech support guy last week. They have an internal document stating that the teefer2 driver - which is like a shim between the OS and the network driver - stops the nic driver from restarting after sysprep stops everything while it's generalizing the system.

    This was last week and I haven't heard back from them whether or not they are working on it. If anyone else who is experiencing this has SEP 11, call up Symantec and open a ticket so we can put some pressure on them for a fix.

    I had our AV guys build me another install with the network protection piece installed but disabled to see if it makes any difference, but I haven't had a chance to test it. Hoping if we can get it installed, we can enable it by policy later. If someone else can try it without the network piece enabled and post the results, that'd be great!

    • Proposed as answer by JoeZeppy Wednesday, May 12, 2010 12:43 AM
    Wednesday, May 12, 2010 12:42 AM
  • JoeZeppy, did the new SEP build make a difference? 
    Wednesday, May 19, 2010 8:15 PM
  • I've been swamped and haven't had a chance to try it. But guess what, Symantec says it's MS's fault.

    " It appears that Sysprep is the source of the issue. Sysprep has issues with the NDIS drivers in Win. 7. What appears to be happening is that the Sysprep run is stopping the "NDIS Usermode I/O Protocol" driver (sc queryex ndisuio). Teefer2 being an NDIS driver, we are dependent on calls from NDIS.sys (Which is also running, "sc queryex NDIS").
     
    Any third party application that interacts with the NDIS driver can experience this Sysprep issue."

     

    So there ya go.

    Friday, May 21, 2010 5:58 PM
  • Thank you for the clarification JoeZeppy!
    Thursday, May 27, 2010 8:46 PM
  • This behaviour will be fixed (at least from MDT's point of view) in MDT 2010 Update 1 (currently in beta). It will now close all networking sessions before running sysprep.
    Thursday, May 27, 2010 9:02 PM
  • I'm testing MDT 2010 Update 1 right now.  I will report how it goes.
    • Proposed as answer by Seiha Thursday, June 10, 2010 6:36 PM
    Thursday, June 03, 2010 8:25 PM
  • Fingers crossed :')

    I just left mine to install on deployment - no time to play around with it.

    Thursday, June 03, 2010 10:55 PM
  • Haven't installed update one just wanted to add for other people searching that the Cisco VPN Client 5.X also has the same problem.
    Wednesday, June 09, 2010 4:13 PM
  • what is sep and how do you disable it on the reference computer?
    Wednesday, June 09, 2010 11:50 PM
  • SEP = Symantec Enpoint Protection.
    Thursday, June 10, 2010 3:04 AM
  • Hadn't noticed that as I install VPN at deploy time based on whether a machine is laptop or desktop, but it seems likely. Also you can't install Cisco as an application in the standard way because it stops networking during the install, so if you are installing it from a share, the install files disappear halfway through the install. You need to copy it local and install it from the hard drive.
    Thursday, June 10, 2010 12:52 PM
  • Has anyone had any problem with mdt01 update issue?  I'm getting this error after mdt01 beta upgrade. 

     

    Error-rule Priority key not set in section [Settings] Error processing Ini settings. No futher processing. Zti error-Non-zero return code by ZTIGather, rc=1 Failure:1:running wscript.exe "X:\Deploy\scripts\ztigather.wsf" Zti error-unhandled error returned by ztigather: objec doesn't support this property of method (438) litetouch deployment failed, return code=-2147467259 0x80004005 Message from the task sequence engine: Failed to run the action: Gather local only. unkow error (error: 00001b6;source:unknow) the execution of the group (initialization) has failed and the execution has been aborted. An action failed. Operation aborted (error:800004004;source;windows) failed to run the last action: gather local only. Execution of task sequence failed unkow error(error:000001b6;source;unknown) task sequence engine failed! code:enexecutionfail task sequence executon failed with error code 80004005 error task sequence manager failed to execute task sequence. code 0x80004005

     

    Thursday, June 10, 2010 6:37 PM
  • I just would like to add, that exactly the same problem exists with Norman Endpoint Protection (NEP).

     I also tried MDT Update beta 1 but with no success. (Still no network access after sysprep)

    The solution which worked for me:

    - Uninstall NEP

    - deactivate Windows Firewall

    - Run Sysprep and capure task with local admin credentials via network (LiteTouch.wsf)

    Since my Image will be a domainmember with GPO (Firewall=on!) and Norman has its own deployment service, this solution just works fine for me.

    Monday, June 21, 2010 12:47 PM
  • Hi Johan,
    I'm experiencing similar difficulties to those described above.  I have an LTISuspend in my task sequence.  After the task sequence is suspended, I'm installing Virtual PC and the MED-V client.  After resuming the Task Sequence, the Sysprep appears to be killing the network and causing the task sequence to fail. I've tried to put another LTIsuspend after the sysprep step in the hopes of uninstalling and reinstalling the network adapter before the task sequence fails, but the suspend doesn't seem to take effect. 
    I upgraded to MDT 2010 Update 1 today, but sysprep still seems to be killing the network connection.  Any ideas how to get around this?
    Tuesday, July 13, 2010 12:49 AM
  • Don't build reference image on physical hardware, if virtual pc needs to be deployed, install it when deploying the image.. do not add it to the ref image...

    Use vmware or hyperv to create your reference image, and don't include any antivirus software in the ref-image either.

    Wednesday, July 14, 2010 4:28 AM
  • I am getting the same issue where network is disconnecting. I will update mdt  today and will see.
    Thursday, July 15, 2010 3:14 AM
  • same story here.

    a vm with w7 64bits in a workgroup.

    caputured 3 times in the past without problems.

    sysprep does the rearm command, figured that out and i reseted the rearm counter so sysprep would run.

    but still the capture process fails.

    loading capture 1 or capture 2 to let me capture it again.

    3 strikes and you are out?

    Thursday, July 15, 2010 12:34 PM
  • I found that the easiest way around this issue is to modify the task sequence.

    Simply move the sysprep task to after "Apply Windows PE" and before "Restart Computer"...

     

    As for getting around the Rearm issue. I just use VMWare Workstation and save a "ready to sysprep" snapshot. Then just revert back to it after getting my image.

     

     

    Thursday, July 15, 2010 6:25 PM
  • After 2 weeks of trying every suggestion found on the internet, I desided to start from scratch today.

    But when it came to the sysprep and capture, the same thing happened...

    But... I found out that for some strange reason the LiteTouchPE_x64.wim and LiteTouchPE_x86.wim did not exist anymore in the boot folder!!

    Luckily I create a backup folder each time I upgrade my deployment share.

    By copying the .wim files to the boot folder, my problem is solved. I can now do again what i have been doing successfully for the last months: Capture and Sysprep my reference computer.

    Friday, July 16, 2010 3:53 PM
  • Nope! Not at alll

    I used MDT 2010, 2012 Beta 1 and the most recent - Beta 2 (came out on Nov 10); Still same issue..

    Amy.

    Tuesday, November 15, 2011 11:04 PM
  • The most common issue for Sysprep failing is having antivirus software in the reference image. Better to install that at deloyment time of the image.

    / Johan


    Regards / Johan Arwidmark Twitter: @jarwidmark Blog: http://www.deploymentresearch.com FB: www.facebook.com/deploymentresearch
    Wednesday, November 16, 2011 5:49 AM
  • Couple things need to be done and can either be part of the task sequence or manual.-

    First in the TS I run a script that runs the diskpart commands,and deletes any remnants on the client (target) machine of the sms or miinint folders using the force command.

    Any network connection issues after it starts means your nic drivers arent there ecspecially if you can't ping from the client to the server, you can test that by pressing f8 in the deployment window on the client.

    Remeber the client pxe boot to wds and once you select LTI for the image it hands it off to MDT so if you get that far then the boot image has the right nic driver and means you need to either iject it into the wim or add it into the drivers folder in mdt.

    I'm working in a TS that will be accessible from the pxe boot like any other and calling it Monthly updates:

    this will drop the base (gold) iimage, apply the updates, sysprep, reboot into WinPE, create a wim file, copy the wimi back top the captures folder on the server.

    Then you just add it as the updated base image with monthly updates included.

     

    • Proposed as answer by Chrism352000 Monday, April 23, 2012 12:49 PM
    • Unproposed as answer by Chrism352000 Monday, April 23, 2012 12:50 PM
    • Proposed as answer by Chrism352000 Monday, April 23, 2012 12:50 PM
    Tuesday, December 20, 2011 2:53 PM
  • i was having a similar issue and if you are all having the same problem most likely it is caused by the cisco VPN adapter.  Remove the VPN adapter and reboot and then run sysprep and capture image..you shouldn't lose your network connection again and the capture should run through.

    '

    Monday, April 23, 2012 12:51 PM
  • My issue is it's saying that there isn't enough room on the drive to install PE. It has over 20Gb available, isn't that enough? Snapshot of the log....

    <![LOG[Set a local default variable RunAsUser]LOG]!><time="13:34:34.885+000" date="04-05-2013" component="TSManager" context="" type="0" thread="1908" file="executionenv.cxx:700">
    <![LOG[Set a local default variable SMSTSRunCommandLineUserName]LOG]!><time="13:34:34.901+000" date="04-05-2013" component="TSManager" context="" type="0" thread="1908" file="executionenv.cxx:700">
    <![LOG[Set a local default variable SMSTSRunCommandLineUserPassword]LOG]!><time="13:34:34.901+000" date="04-05-2013" component="TSManager" context="" type="0" thread="1908" file="executionenv.cxx:700">
    <![LOG[Set a local default variable LoadProfile]LOG]!><time="13:34:34.901+000" date="04-05-2013" component="TSManager" context="" type="0" thread="1908" file="executionenv.cxx:700">
    <![LOG[Set a global environment variable _SMSTSLogPath=X:\WINDOWS\TEMP\SMSTSLog]LOG]!><time="13:34:34.901+000" date="04-05-2013" component="TSManager" context="" type="0" thread="1908" file="executionenv.cxx:668">
    <![LOG[Expand a string: cscript.exe "%SCRIPTROOT%\LTIApply.wsf" /PE /STAGE]LOG]!><time="13:34:34.901+000" date="04-05-2013" component="TSManager" context="" type="0" thread="1908" file="executionenv.cxx:782">
    <![LOG[Expand a string: ]LOG]!><time="13:34:34.901+000" date="04-05-2013" component="TSManager" context="" type="0" thread="1908" file="executionenv.cxx:782">
    <![LOG[Command line for extension .exe is "%1" %*]LOG]!><time="13:34:34.901+000" date="04-05-2013" component="TSManager" context="" type="0" thread="1908" file="commandline.cpp:229">
    <![LOG[Set command line: cscript.exe "%SCRIPTROOT%\LTIApply.wsf" /PE /STAGE]LOG]!><time="13:34:34.901+000" date="04-05-2013" component="TSManager" context="" type="0" thread="1908" file="commandline.cpp:707">
    <![LOG[Start executing the command line: cscript.exe "%SCRIPTROOT%\LTIApply.wsf" /PE /STAGE]LOG]!><time="13:34:34.901+000" date="04-05-2013" component="TSManager" context="" type="1" thread="1908" file="instruction.cxx:2928">
    <![LOG[!--------------------------------------------------------------------------------------------!]LOG]!><time="13:34:34.901+000" date="04-05-2013" component="TSManager" context="" type="1" thread="1908" file="instruction.cxx:2957">
    <![LOG[Expand a string: ]LOG]!><time="13:34:34.901+000" date="04-05-2013" component="TSManager" context="" type="0" thread="1908" file="executionenv.cxx:782">
    <![LOG[Executing command line: cscript.exe "%SCRIPTROOT%\LTIApply.wsf" /PE /STAGE]LOG]!><time="13:34:34.901+000" date="04-05-2013" component="TSManager" context="" type="1" thread="1908" file="commandline.cpp:805">
    <![LOG[Process completed with exit code 2147942512]LOG]!><time="13:35:18.721+000" date="04-05-2013" component="TSManager" context="" type="1" thread="1908" file="commandline.cpp:1102">
    <![LOG[!--------------------------------------------------------------------------------------------!]LOG]!><time="13:35:18.721+000" date="04-05-2013" component="TSManager" context="" type="1" thread="1908" file="instruction.cxx:3010">
    <![LOG[Failed to run the action: Apply Windows PE.
    There is not enough space on the disk. (Error: 80070070; Source: Windows)]LOG]!><time="13:35:18.721+000" date="04-05-2013" component="TSManager" context="" type="3" thread="1908" file="instruction.cxx:3101">
    <![LOG[Sending status message . . .]LOG]!><time="13:35:18.721+000" date="04-05-2013" component="TSManager" context="" type="1" thread="1908" file="utility.cxx:292">
    <![LOG[Executing in non SMS standalone mode. Ignoring send a task execution status message request]LOG]!><time="13:35:18.721+000" date="04-05-2013" component="TSManager" context="" type="1" thread="1908" file="utility.cxx:302">
    <![LOG[Set a global environment variable _SMSTSLastActionRetCode=-2147024784]LOG]!><time="13:35:18.721+000" date="04-05-2013" component="TSManager" context="" type="0" thread="1908" file="executionenv.cxx:668">
    <![LOG[Set a global environment variable _SMSTSLastActionSucceeded=false]LOG]!><time="13:35:18.721+000" date="04-05-2013" component="TSManager" context="" type="0" thread="1908" file="executionenv.cxx:668">
    <![LOG[Clear local default environment]LOG]!><time="13:35:18.737+000" date="04-05-2013" component="TSManager" context="" type="0" thread="1908" file="executionenv.cxx:807">
    <![LOG[Let the parent group (Capture Image) decides whether to continue execution]LOG]!><time="13:35:18.737+000" date="04-05-2013" component="TSManager" context="" type="0" thread="1908" file="instruction.cxx:3210">
    <![LOG[Let the parent group (Capture Image) decide whether to continue execution]LOG]!><time="13:35:18.737+000" date="04-05-2013" component="TSManager" context="" type="0" thread="1908" file="instruction.cxx:2461">
    <![LOG[The execution of the group (Capture Image) has failed and the execution has been aborted. An action failed.
    Operation aborted (Error: 80004004; Source: Windows)]LOG]!><time="13:35:18.737+000" date="04-05-2013" component="TSManager" context="" type="3" thread="1908" file="instruction.cxx:2424">
    <![LOG[Failed to run the last action: Apply Windows PE. Execution of task sequence failed.
    There is not enough space on the disk. (Error: 80070070; Source: Windows)]LOG]!><time="13:35:18.737+000" date="04-05-2013" component="TSManager" context="" type="3" thread="1908" file="engine.cxx:214">
    <![LOG[Sending status message . . .]LOG]!><time="13:35:18.737+000" date="04-05-2013" component="TSManager" context="" type="1" thread="1908" file="utility.cxx:292">
    <![LOG[Executing in non SMS standalone mode. Ignoring send a task execution status message request]LOG]!><time="13:35:18.737+000" date="04-05-2013" component="TSManager" context="" type="1" thread="1908" file="utility.cxx:302">
    <![LOG[Execution::enExecutionFail != m_eExecutionResult, HRESULT=80004005 (e:\nts_sms_fre\sms\client\tasksequence\tsmanager\tsmanager.cpp,767)]LOG]!><time="13:35:18.737+000" date="04-05-2013" component="TSManager" context="" type="0" thread="1908" file="tsmanager.cpp:767">
    <![LOG[Task Sequence Engine failed! Code: enExecutionFail]LOG]!><time="13:35:18.737+000" date="04-05-2013" component="TSManager" context="" type="3" thread="1908" file="tsmanager.cpp:767">
    <![LOG[****************************************************************************]LOG]

    Friday, April 05, 2013 9:08 PM