none
Unable to find LiteTouch.wsf after imaging RRS feed

  • Question

  • I'm trying to deploy Windows 2012 R2 to a Dell M600 blade (same problem happens with Windows 2008 R2). Everything goes fine until MDT2013 tries to login to windows the first time at which point I receive an error saying "Unable to find LiteTouch.wsf needed to continue the deployment".

    The same task sequence works ok on other hardware.

    I inject network drivers during my task sequence and I believe everything is ok since Windows shows I'm conneted to the network and the machine was joined to the domain. MDT is also refusing to set the NIC settings i have in the MDT database.

    I've been looking on the computer to see if there's any logs but I'm not finding any. There is no C:\minint  and in C:\windows\temp\deploymentlogs, the logs all have the date of when i captured the image.

    Does anyone know where I can find the logs or know why this is happening?

    Thanks

    Tuesday, December 9, 2014 7:46 PM

Answers

  • This behaviour occurs when a second hard drive is attached. Perhaps the drive is offline, not visible or reachable.

    There are a few options here:

    - In case of a VM disconnect or remove the drive
    - Format & Partition the drive from within the MDT task sequence
    - Perform a diskpart to clean, partition and format the drive, assign a driveletter

    To my knowledge and experience I have a gut-feeling that one or more scripts within MDT, set drives other than the OSD target drive in offline mode. Will MDT itself uses the second drive to store the MDT scripts, such as cs.ini unattend.xml and litetouch.wsf.

    So clean your drive, reformat it, attach a drive letter and retry your installation.

    Cheers!


    If this post is helpful please click "Mark for answer", thanks! Kind regards

    Wednesday, December 10, 2014 3:20 PM

All replies

  • Logs will usually be in either of those locations, or on the X:\ drive.  You could turn on network logging as specified here - http://blogs.technet.com/b/mniehaus/archive/2009/06/26/mdt-2010-new-feature-1-logging-directly-to-the-network.aspx and you will have a log on your filer for the build that you can supply here.  Make sure you update your DS after you add this configuration.

    Tuesday, December 9, 2014 9:41 PM
  • This behaviour occurs when a second hard drive is attached. Perhaps the drive is offline, not visible or reachable.

    There are a few options here:

    - In case of a VM disconnect or remove the drive
    - Format & Partition the drive from within the MDT task sequence
    - Perform a diskpart to clean, partition and format the drive, assign a driveletter

    To my knowledge and experience I have a gut-feeling that one or more scripts within MDT, set drives other than the OSD target drive in offline mode. Will MDT itself uses the second drive to store the MDT scripts, such as cs.ini unattend.xml and litetouch.wsf.

    So clean your drive, reformat it, attach a drive letter and retry your installation.

    Cheers!


    If this post is helpful please click "Mark for answer", thanks! Kind regards

    Wednesday, December 10, 2014 3:20 PM
  • This would explain the missing logs.  In the off cases I've had of issues with target partitions, I use this little guy to tell MDT where the partition is.

    $tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment
    $OSDisk = Get-WMIObject Win32_Volume | ? { $_.Label -eq 'OSDISK'}
    
    $tsenv.Value("OSDisk") = $OSDisk.DriveLetter

    If you put this in between your partition step and your apply image step, it will find your partition named OSDisk and set that as the target partition letter.  Helped me on some devices in the past that were failing to find target partition.

    Wednesday, December 10, 2014 3:49 PM
  • I pulled the 2nd drive on this machine, did a diskpart -> clean on the remaining drive and then tried again. This time MDT worked!

    I put the 2nd drive back  and before trying MDT again, I checked the 2<sup>nd</sup> drive and found an _SMSsomething folder and a minint folder which appeared to be tricking MDT into thinking there was a in-progress deployment. Doing a “clean” on both drives and trying the deployment again seems to have done the trick.

    To try and make things a little more resilient in the future (eg. if I need to reimage the OS but leave the D drive intact), would the 3 line powershell example given above work? If so, would the following be the correct procedure to use it:

    -Insert a powershell step after the format and partition step

    -Put those 3 lines into a .ps1 file and save it to the scripts folder on the deployment share

    - Reference the script in the new step as %SCRIPTROOT%\mypowershellfile.ps1?  

    Also, is there an easy way to have MDT do a diskpart > clean on disk 0 before starting? Whether or not MDT gets stuck at deployin the image seems to be  little hit or miss when there’s something else on the drive so I’d prefer to wipe out whatever is there before starting (and I generally forget to go into diskpart before starting the task sequence)

    Wednesday, December 10, 2014 7:24 PM
  • You can add a step to your Winpe unattend to clean disk 0 on boot. I don't like that because all it takes is one mistaken boot and you're wiping a device you didn't intend to, so be careful about automating too much. This describes what I'm talking about - http://www.deploymentresearch.com/Research/tabid/62/EntryId/32/Leftover-junk-prevents-new-installation-in-MDT-2010.aspx

    You need to edit it on your unattend for your boot wim though, as if you edit it on your task sequence you'll wipe your deployment scripts from the drive :)

    Wednesday, December 10, 2014 8:33 PM