It is finally here! The Task Sequence Debugger finally debuted in SCCM 1906. We first heard of this amazing tool at MMS 2016. You have heard of MMS right?

The GUI is a bit different, but definitely what we were looking for. The great Kerwin has finally delivered, and it seems from his Twitter picture he is pretty excited for this new tool as well!

Let’s dig in!

Docs

Whats new in SCCM 1906 – Task Sequence Debugger

Debugging a task sequence

Prereqs

Full OS: Must be logged as account with administrative rights SCCM 1906 client or higher (5.00.8853.1006)

WinPE: Boot image updated with SCCM 1906 client or higher (5.00.8853.1006)



Deployment

To setup the debugger, you actually create a debug deployment when selecting a task sequence. You can right click or use the ribbon.

This pre-populates some of the fields on the deployment wizard for you, such as the purpose and available platform.

Running the debugger

I will be testing in Full OS. Now on your client, run the available deployment from Software Center. The first thing you will notice is a UAC prompt. Considering that the task sequence, like most things in SCCM, runs as the LOCAL SYSTEM account, you would need administrative permissions and elevation to be able to edit what a task sequence is doing.

Notice the path: c:\windows\ccm\tsd.exe

The task sequence then kicks off, and you get a beautiful popup with the TS Debugger and some of the TS variables.

The official documentation has an explanation for each of the steps.

Step – From the current position, run only the next step

– From the current position, run only the next step Run – From the current position, run the task sequence to the end, next break point, or next step failure

– From the current position, run the task sequence to the end, next break point, or next step failure Set Current – Select a step and use this to move the current pointer to that step

– Select a step and use this to move the current pointer to that step Set Break – Select a step and use this to set a break point

– Select a step and use this to set a break point Clear All Breaks – Remove all break points

– Remove all break points Log File – Opens the current smsts.log in CMTrace

– Opens the current smsts.log in CMTrace Cmd Prompt – In Windows PE, opens the command prompt

– In Windows PE, opens the command prompt Cancel – Close the debugger, and fail the task sequence

– Close the debugger, and fail the task sequence Quit – Detach and close the debugger, and run the task sequence normally

Variables

Glancing through the variables I found a few new ones.

TSDebugMode – true or false

– true or false _SMSTSNextInstructionPointer – Integer for the next step pointer

– Integer for the next step pointer _SMSTSInstructionStackString – Does not correlate to steps ran. Appears to be hex or binary bits?

– Does not correlate to steps ran. Appears to be hex or binary bits? _SMSTSInstructionTableSize – Size of the instruction pointer table (Kilobytes? Bytes? Bits? Not sure.)

Logs

Let’s look at the smsts.log. The first difference you notice is some additional logging around the debugger, pointers, and instructions. The instructions actually have number assigned, starting with 0.

As each step starts and ends, the debugger sets up the next pointer. See below as it moves from 2 to 3.

By using the Set Current button you can choose the step to run next. In this case, I am starting over, 9 to 0.

You can also see the _SMSTSInstructionStackString in the log, but this does not seem to correlate to the steps ran so far.

Finally, after testing, I quit the debugger to let the task sequence finish running. You see it quit in the log.

Conclusion

This tool brings to SCCM admins, something that has been needed for a long time: A way to debug task sequences on the fly! No more pausing the task sequence, rerunning to test, or any other custom methods you may have been using out there.

What could be next for the TS Debugger? Enabling it mid-TS? Running it standalone (no deployment, no policy)? What if you could load it on an endpoint while it is running an in-place upgrade? Running a ZTI rebuild? Stop on a failure, debug, fix the issue, and continue the task sequence. This is very exciting to help make task sequence deployments much more successful in the future!