none
MDT 2013 - Litetouch.wsf continues to run at login RRS feed

  • Question

  • Hi all! I recently imaged a server with MDT 2013 and after it booted into Windows one of the applications I configured to install crashed and we ended up with an incomplete deployment. In this case this was fine and we moved on, but now every time a user logs in something is attempting to launch the Litetouch.wsf script. I ran LTICleanup manually and removed the MININT folder, but I continue to get a pop-up at login that Litetouch cannot be found.

    I have tried every registry key I am aware of HKCU and HKLM Run and Runonce keys and also checked the startup folders for every user. What is calling Litetouch? How can I stop this from happening? Thanks!

    Tuesday, November 25, 2014 1:35 PM

Answers

  • Well there's really only so many spots something like that can come from.. 

    In the registry: http://msdn.microsoft.com/enus/library/aa376977%28v=vs.85%29.aspx

    In the shell:startup location mentioned before or like C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup on Windows 7.

    In the unattend.

    • Marked as answer by Matt McNabb Monday, December 1, 2014 12:57 PM
    Wednesday, November 26, 2014 7:26 PM

All replies

  • There's a shortcut in the all users or admin startup items folder.  This one confused me as well until I found it, I think I just searched C:\ for the script name and saw the shortcut in the all users path.  Let me know if this helps.

    Ryan


    Tuesday, November 25, 2014 3:12 PM
  • There's a shortcut in the all users or admin startup items folder.  This one confused me as well until I found it, I think I just searched C:\ for the script name and saw the shortcut in the all users path.  Let me know if this helps.

    Ryan



    I had previously searched all the startup folders but did not find anything there. I just ran a search for 'litetouch' on the root of c: and got no results. Am I searching for the wrong term?
    Tuesday, November 25, 2014 7:35 PM
  • From a run command window (win+r) run shell:startup and you should see it in that location. You probably didn't find it because of hidden folders.
    Tuesday, November 25, 2014 8:33 PM
  • From a run command window (win+r) run shell:startup and you should see it in that location. You probably didn't find it because of hidden folders.

    nice trick to get to that folder quickly!

    /Brian Gonzalez


    -BrianG (http://supportishere.com)

    Tuesday, November 25, 2014 10:16 PM
  • Unfortunately it isn't there. I previously checked the startup folder for all users and found nothing. Here's a screen of the error and the built-in admin's startup folder:

    Any other ideas where this might be called from? Thanks!

    Wednesday, November 26, 2014 1:30 AM
  • It's gotta be a run key then of some sort.  I would try a ctrl+f in the registry for litetouch.wsf as well.
    Wednesday, November 26, 2014 2:19 PM
  • It's gotta be a run key then of some sort.  I would try a ctrl+f in the registry for litetouch.wsf as well.

    Did that. Got nothing.
    Wednesday, November 26, 2014 3:01 PM
  • What's your unattend look like?  Any run commands in there that might still be calling litetouch?  By default the unattend will be configured to call litetouch on first boot.
    Wednesday, November 26, 2014 3:30 PM
  • What's your unattend look like?  Any run commands in there that might still be calling litetouch?  By default the unattend will be configured to call litetouch on first boot.

    The only suspicious entry in the unattend is this:

    <FirstLogonCommands> <SynchronousCommand wcm:action="add"> <CommandLine>wscript.exe %SystemDrive%\LTIBootstrap.vbs</CommandLine> <Description>Lite Touch new OS</Description> <Order>1</Order> </SynchronousCommand>

    </FirstLogonCommands>


    But ltibootstrap.vbs does not exist on the root drive.

    Wednesday, November 26, 2014 3:54 PM
  • Yep and that's where it's being called from.  You can open up the unattend in WSIM and remove that as you're not calling anything from MDT post installation.  That step comes preconfigured when you create a new standard task sequence for post installation items and configuration.  Hope this helps.
    Wednesday, November 26, 2014 5:32 PM
  • Yep and that's where it's being called from.  You can open up the unattend in WSIM and remove that as you're not calling anything from MDT post installation.  That step comes preconfigured when you create a new standard task sequence for post installation items and configuration.  Hope this helps.

    I removed that section of the xml but this did not affect anything and I still got the prompt at logon. This makes sense as I stated before that the ltibootstrap.vbs did not exist at the path in the unattend file so there isn't any way this could be the culprit.

    There has to be something I am missing here.

    Wednesday, November 26, 2014 6:34 PM
  • Well there's really only so many spots something like that can come from.. 

    In the registry: http://msdn.microsoft.com/enus/library/aa376977%28v=vs.85%29.aspx

    In the shell:startup location mentioned before or like C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup on Windows 7.

    In the unattend.

    • Marked as answer by Matt McNabb Monday, December 1, 2014 12:57 PM
    Wednesday, November 26, 2014 7:26 PM
  • Well there's really only so many spots something like that can come from.. 

    In the registry: http://msdn.microsoft.com/enus/library/aa376977%28v=vs.85%29.aspx

    In the shell:startup location mentioned before or like C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup on Windows 7.

    In the unattend.

    Ok I finally found it in C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp! Deleting this shortcut got rid of the annoying pop-up. Thanks for your help!

    I am not sure why a disk search did not return this earlier. Oh well...

    Monday, December 1, 2014 12:57 PM
  • Yeah that spots hidden, unless you turn on hidden folders the search won't find it.  Good to hear you're all set now.
    Monday, December 1, 2014 3:59 PM
  • Thanks!

    The culprit was in:

    C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup
    Tuesday, May 1, 2018 5:49 PM