In MDT 2010, we restructured the ConfigMgr task sequence templates so that they had a common structure to them, with two main groups:

  • Execute Task Sequence
  • This group contained all the actual deployment tasks
  • Gather Logs and StateStore on Failure
  • If any of the steps in the main “Execute” step failed, this group would handle the cleanup:  copy logs to the network, move the state store to a safe location, etc.

But there was one problem in the setup in MDT 2010: the error was caught and the cleanup steps would run, but after that the task sequence would appear to complete successfully.  No dialog would be displayed indicating that there was a failure, and the status messages sent to the server would indicate that the task sequence was successful too .  If you were watching the results from the individual steps (watching for status message 11135 messages), you would see that there was an error though.

In MDT 2010 Update 1, we’ve updated each of the task sequence templates (and included the same logic in the new UDI template) to include two new steps to address this problem.  The first is named “Set Error Code” and (appropriately enough) captures the error code (e.g. everyone’s favorite –2147500037) into a task sequence variable.  The second step, named “Error in the task sequence”, then runs a new script (ZTIErrorMsg.wsf) whose only purpose is to force the task sequence to fail with that same error code.  That solves the problem.

So this is one of the main reasons to consider generating new ConfigMgr task sequences after installing MDT 2010 Update 1.

(10627)