none
MDT 2013 Update 1 drops network connection during SYSPREP RRS feed

  • Question

  • Hi,

    I have just upgraded a MDT 2012 server to MDT 2013 Update 1 (6.3.8298.1000) and am currently having issues with capturing a Windows 10 Professional x64 image.

    I installed Windows Assessment and Deployment Kit - Windows 10 (10.0.26624) when i upgraded MDT.

    The MDT 2013 install has been upgraded and updated, and new Lite Touch PE images have been created, and i created a new task sequence for the new capture.

    From the newly built Windows 10 computer, i am able to connect to the network drive and run the Deployment\Scripts\LiteTouch.vbs script as normal.

    The issue arises during the SYSPREP process.

    The network driver is removed, meaning the computer is disconnected from the network, and when the process tries to access the network files for the next step in the capture process, it throws an error message stating it cannot find LTICopyScript.WSF. When I click on the OK button, the computer restarts, and if I complete a network boot, the MDT screen appears and the WIM capture starts.

    The computer is not on the domain, and I have double checked that anti-virus is not installed.

    Any ideas or suggestions on how to resolve this and allow me to use MDT as it was designed would be appreciated.

    Thanks in advance,

    PD

    Wednesday, September 30, 2015 5:28 AM

Answers

  • Removal of the networking stack during sysprep is by-design.

    MDT is designed to handle this scenario, you should not be running sysprep manually, and *then* run litetouch.vbs, instead use the captureonly.xml task sequence to sysprep for you.


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

    Thursday, October 1, 2015 7:56 PM
    Moderator

All replies

  • Can you post your BDD.log to something like OneDrive and share the link to it here?

    The error about LTICopyScript.WSF shouldn't be happening however it is normal for you to see a message about losing network in the logs.


    Most important details are logs. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/

    Wednesday, September 30, 2015 5:53 PM
    Moderator
  • Thanks for the quick reply.

    I have uploaded the BDD.log file to

    PD


    • Edited by peter-digby Thursday, April 4, 2019 5:46 AM Removiing personal information
    Thursday, October 1, 2015 1:14 AM
  • Removal of the networking stack during sysprep is by-design.

    MDT is designed to handle this scenario, you should not be running sysprep manually, and *then* run litetouch.vbs, instead use the captureonly.xml task sequence to sysprep for you.


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

    Thursday, October 1, 2015 7:56 PM
    Moderator
  • I don't see anything in the log either.

    Most important details are logs. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/

    Thursday, October 1, 2015 9:15 PM
    Moderator
  • Thanks for looking into this for me.

    I was not running sysprep manually, i was running the LiteTouch.vbs script from the \Deployment\Scripts\ folder on the deployment server.

    This morning I deleted and created a new 'Sysprep and Capture' task and selected the wim file created from the task which was erroring previously, and the capture is now running as expected.

    Once again, thank you.

    PD

    • Proposed as answer by J_Saunders Friday, November 20, 2015 9:01 PM
    Sunday, October 4, 2015 10:27 PM
  • Thanks for looking into this for me.

    I was not running sysprep manually, i was running the LiteTouch.vbs script from the \Deployment\Scripts\ folder on the deployment server.

    This morning I deleted and created a new 'Sysprep and Capture' task and selected the wim file created from the task which was erroring previously, and the capture is now running as expected.

    Once again, thank you.

    PD


    I'm not sure why Keith's post was marked as the answer, given that it wasn't very helpful in resolving the issue. I was also experiencing the same problem, and creating a new "Sysprep and Capture" task as per PD's suggestion worked perfectly.
    Friday, November 20, 2015 9:03 PM