MDT 2013 UberBug03 – Less Logging is not better

During the announcement of MDT 2013 Update 1 yesterday it was mentioned that one of the new features is:

Updated task sequence binaries from System Center 2012 R2 Configuration Manager SP1

Deployment pros know what a Task Sequence is, it’s the steps performed in order that make up a full deployment.

ts

Even when running LiteTouch, MDT will use System Center binaries to do the heavy lifting of calling each program, managing variables, and logging the results.

Logging

During task sequence execution, the SCCM Stand Alone Task Sequencing Engine will log each step, and log the results, most of the time in %temp%\smsts.log. For example, say we add a bad step to our task sequencer. In our SMSTS.log file would we see:

!------------------------------------------!
Expand a string: WinPEandFullOS
Executing command line: cmd.exe /c Echo Hello TS & exit 28
Process completed with exit code 28
!------------------------------------------!
Failed to run the action: Run Command Line.
The printer is out of paper. (Error: 0000001C; Source: Windows)

That’s great, I created a step in the Task Sequencer that retuned back a non-zero error code, and the step was not marked as “continue on error”, so the Task Sequence stopped because of it. At least we know what step failed.

Updated for MDT 2013 Update 1

Now with MDT 2013 Update 1, they have updated the core Task Sequencing binaries, and there is new functionality. The new functionality is to *not* log the steps, even when there is an error.

No Logging, this sucks.

This means that if one of your steps fails, and returns a non-zero result, the MDT Task Sequence may fail, and you the MDT Administrator may not be able to figure out why or where it failed.

I consider this to be a major flaw of the New Task Sequencing engine. I have filed a bug against the MDT team a while back, but they have indicated that they won’t look at a fix until the fall 2015.

If you think you can create task sequences that never have problems, then you should be OK, but logging after the fact is an important part of any *Production* MDT environment, as it blocks debugging.

There is no known work around.

Advertisements

4 thoughts on “MDT 2013 UberBug03 – Less Logging is not better

  1. Pingback: MDT UberBug04 – Litetouch Success may mean Failure | Keith's Consulting Blog

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