Task Sequence fails to resume after first logon

I think this has become the biggest single FAQ item on the TechNet MDT Site. The symptoms appear to be straightforward, however there are several points of failure where this can break.

Process

  • During a normal Windows deployment we start off with an image that has been syspreped. OS images from Microsoft have been syspreped.
  • Once the user has initiated the Task Sequence, MDT will prepare the local hard disk in WinPE, by formatting the drive, and extracting the OS itself from the install.wim file to the target partition.
  • By itself the WIM file does not lay down the necessary boot loader files to the local machine, so MDT will execute the BCDBoot.exe tool. Good for BIOS and uEFI machines.
  • Once the files are ready, the Task Sequence will exit WinPE for a reboot, if the OS was syspreped properly, the new OS will start OOBE ( Out of Box Experience ) setup.
  • OOBE setup is responsible for reading the c:\minint\unattend.xml file, placed there by MDT.
  • Within the c:\minint\unattend.xml file, there will be instructions to run c:\LTIBootStrap.vbs.
  • LTIBootStrap.vbs will search for the local copy of MDT installed on your machine and execute the Litetouch.wsf script.
  • Litetouch.wsf will prepare the machine for auto-logon, and install itself in the Startup group.
  • OOBE setup will eventually finish, and reboot the machine.
  • Upon reboot MDT should run the Litetouch.wsf script present in the startup group, and continue with the task sequence in the “State Restore” phase.

What could possibly go wrong? Well…

Things to look for

There are a couple points of failure that I’ve seen more than others.

  • SysPrep – Images must be syspreped, MDT uses the hooks in the unattend.xml file to resume the Task Sequence after OOBE. If the image isn’t syspreped, the unattend.xml file is not processed.
    (Did you get the image from a MDT Sysprep and Capture task sequence)?
  • SysPrep Failure – Sysprep must pass. If sysprep runs, but it fails then the unattend.xm file might not even be processed. If you get a missing CloneTag error, then this is a Sysprep Failure.
    (Does your task sequence continue when using known good *.wim file?)
  • Upgrading MDT – If you have recently upgraded your MDT share from a previous version of MDT, MDT may have skipped some files (for various reasons) during the upgrade process
    (Go through each file in the deploymentshare\scripts folder with a fine tooth comb, like WinDiff.exe).
  • Unattend.xml – It may be tempting to create your own unattend.xml file from scratch, or to use one that you have used elsewhere, however MDT is expecting the c:\LTIBootStrap.vbs script file to run.
    (can you go back and use the standard MDT template file?)
  • Script Bugs – It is possible that litetouch.wsf has problems. Look to see if it has executed. by looking in the bdd.log file.
    bdd.log file should show some entries during OOBE from litetouch.wsf.
  • Group Policy – It is possible that your domain has disabled execution through Group Policy changes.
    (Can you perform a successful litetouch run *without* joining a domain)
  • If you come across any other scenarios where the Task Sequence fails to resume after first logon, let me know, and I’ll add it to the list.

    Advertisements

2 thoughts on “Task Sequence fails to resume after first logon

  1. Could also be that MDT tried to continue before the network card was ready. In newer computers with SSDs we’ve seen that it will try to continue before the network is ready so when connecting back to the deployment share it would fail and thus the deployment would fail.

    To solve this we put in a Run Command Line task after the reboot before anything else that simply delays the deployment for 10 seconds until the network card is ready and then continues the deployment without issue.

    The command line we used was “timeout 10”

    Works perfect, gives enough time to reconnect to network and allows for seamless continuance of the deployment.

    • Interesting, however, I would look at your DHCP infrastructure. Get your network team to document the delay in when a machine requests a DHCP address, and when the machine receives the address.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s