MDT "Unable to find litetouch.wsf" Error Post-Reboot Requiring Manual Diskpart Clean

Question

Hi guys! We use MDT to capture a thick image so our field techs can deploy faster without waiting for a massive task sequence to install every single app, but I keep hitting a "Unable to find litetouch.wsf" error right after the first reboot. The weirdest part is that it only goes through if I manually run a diskpart clean on the drive first, even though my task sequence is already set up to format and partition the disk like normal. Its a total pain for the team to have to manualy wipe the drive and restart the whole process just to get a basic image to stick. Does anyone know why MDT is failing to find the boot script on a dirty disk but works fine when the drives totally blank?

Answer 1

Hi Ephelios,

This usually means the task chain is continuing from a disk layout that MDT hasn't fully reset, rather than litetouch.wsf itself disappearing. MDT's LTI process is controlled by LiteTouch.wsf, and the disk preparation script ZTIDiskpart.wsf sends the CLEAN command to Diskpart before creating partitions. The WipeDisk property is also not the same as wiping the entire disk: it only formats DiskIndex 0 / Index 0. So, if the machine still has leftover OEM/recovery/boot partitions or an unwanted boot layout, MDT might return after the first reboot to search its local runtime environment in a location that no longer matches the disk state. That's why manual cleanup using diskpart helps it function correctly.

The practical solution is to have the task sequence perform the same "pre-wipe disk" operation each time, before the reboot point, and verify that it is targeting the correct physical disk. At the same time, ensure the firmware boot mode matches the partition type you are deploying, as BIOS/UEFI mismatches can produce the same type of error after reboot.

To troubleshoot, the critical MDT log files are located in C:\MININT\SMSOSD\OSDLogs during deployment, and then they are moved to %WINDIR%\TEMP\DeploymentLogs after the task sequence finishes. The BDD.log and ZTIDiskpart.log files will typically show whether MDT actually cleaned and repartitioned the disk, or whether it continued working on the wrong drive.