Deployment of Server 2012 Fails with "Unable to find litetouch.wsf" RRS feed

  • Question

  • I've been successfully deploying Windows 7 and Windows 8 via LiteTouch for many years, first using MDT 2010, then 2012 Update 1. Little kinks here and there, sometimes relating to the newer version of WinPE, but overall I love it and it works well.

    I've just tried to deploy my first Server 2012 machine via MDT, and it fails at the point where it tries to log into the freshly deployed OS for the first time and resume the task sequence from within Windows. It appears to log in as the local admin, but before the desktop is displayed at all, a pop-up message appears stating "Unable to find litetouch.wsf needed to continue the deployment."  Because the desktop is not displayed, I cannot see whether the network connection is active, and it's not possible to launch or check anything until I respond "OK" to the dialog box. 

    I'm booting from WinPE 5.0, very newly regenerated boot images - in fact, these are the first boot images based on WinPE5.0 that I've ever used. I suspected a problem there, so I used that same boot image to deploy another Win8 machine to the same hardware via my long-used Win8 Client task sequence, and it worked flawlessly. The "hardware" is a VMware virtual machine using the Paravirtual SCSI adapter and the VMXNET 3 adapter.  Once I dismiss the dialog on the Server 2012 machine and reach the desktop my network connection appears normal. The same drivers are used on the workstation and again, it behaves normally.

    One interesting feature is that my deployment of Server 2012 lingers for over 1/2 an hour at the end of Installing Operating System on the "Applying unattend.xml with DISM.EXE" step.  The only other time I ever observed that was when I attempted to apply lots of Windows Update packages to a Win8 client deployment as part of the task sequence. It would take forever on "Applying unattend.xml with DISM.EXE" and some update or other prevented that deployment from ultimately succeeding.  I disabled that part of the task sequence and client deployments started succeeding again.  It's as if my Server 2012 task sequence is attempting to apply lots of updates at this stage, but I've explicitly disabled that in the task sequence so I'm not sure what it's spending so long thinking about. 

    I could flood this post with more info, but let's start there.  Does anything obvious come to mind for anyone?

    Thanks in advance for all replies!


    • Edited by Bryan-L Monday, April 21, 2014 6:12 PM
    Monday, April 21, 2014 6:08 PM

All replies

  • I found the problem - figured I'd post it here to help others in a similar fix. 

    In my case, one of my very first deployment attempts was aborted. Knowing that an incomplete or failed deployment could cause subsequent failures if the leftover files were properly cleaned up, I was careful to start with a clean disk when trying again. (I actually deleted the VMDK for the OS and created a new one.) However, I neglected to look at two additional disks attached to the VM which were to be used for SQL data and log files. Even though they were found to be "Offiline" in disk management after the last failed deployment, bringing them online revealed MDT was indeed using the largest of them as staging space for the deployment. 

    I cleaned up that disk and checked the other to verify it was empty. I shut down, removed and deleted the OS VMDK and created a new one.  I then took the extra measure of removing the other two disks from the VM so the only disk attached to the VM was the single pristine OS disk.

    I fired off the new deployment attempt, went to lunch, and came back to find a successful deployment.  Seems pretty clear that the aborted task sequence from way back was persisting on that second disk and fouling things up. I seem to have a dim memory that MDT will use the largest attached disk for its staging/working data, and the disk containing the uncompleted task sequence files was indeed the largest disk attached to the VM. 

    Hope this helps, and thanks to these forums for giving me a void to shout into. Sometimes THAT helps. :-)


    • Edited by Bryan-L Monday, April 21, 2014 7:42 PM
    Monday, April 21, 2014 7:40 PM
  • Hi Bryan-L!

    Thank you for opening this thread.
    You're right, MDT obviously uses the largest attached disk for its staging/working data.

    But ... is there a way to pedefine for example the OS disk to use?

    Hoping for replies.

    Wednesday, January 21, 2015 9:26 AM