ConfigMgr Task Sequence Debugger
The Task Sequence Debugger is an essential tool to become familiar with for any admin who works with OSD. I’m going to show how you can enable it, then how you can leverage it.
The docs are a good place to start, it talked about two methods to enable the Debugger, I’m going to show you both.
- Recast TS Tips – Check out the video that I show it in action (towards the end of the video)
When launching a Task Sequence in debug mode from Software Center, you will be prompted for Adminstrator Credentials. If none are provided, the TS wil stall.
There is a “Bug” with the Debugger, if you are going to use it in OSD, you need to “Turn it off and back on” before & after your Setup Windows ConfigMgr Step. More info, check out THIS POST from Mike Marable.
Collection / Machine Variable
This is my preferred way to enable it, I find it easier to add it to a test machine vs creating a deployment to a collection. Typically I only want to test it on one machine anyway.
Here I’m going to show that I’ve created a “Debug” Collection, and add my test machines. I’ve set the variable on this collection, so each machine will have the debugger enabled.
- Step will forward you 1 step
- Run will allow the task sequence to run without pausing until it hits a break or the machine restarts, at which time you’d have to click run again.
- Set Current, allows you to go forward or backwards. Personally, I’d only use this to go backwards and retry something, moving forward is probably a bad test, as many times things later in the TS rely on things set early
- Set Break allows you to set a break point, allowing you to click run and having the TS run normal until it reaches a place you’d like to observe more closely.
- Clear all Breaks… clears the breaks you created
- Log File, launches the SMSTS.log file
- Cmd Prompt – while in WinPE, it will launch the Command Prompt
- Cancel will error out the TS and your done.
- Exit will close the debugger and allow the TS to run normally.
If you’d rather control the debugger at the Task Sequence level, you can do that was well. This method is handy if you’re unable to create additional collections, set machine variables, or want to limit the debugging to a single TS, but have it debug on any machine that runs that deployment. In this example, any of the machines in this collection would be able to debug this Task Sequence, but any other task sequence deployment would be left unaffected.
In this example, I’ve created a Debug Deployment using this method:
In the wizard, I choose my collection, which I made sure had less than 10 (at the time I created the deployment), and used all the defaults, except I allowed it to run from Media & PXE.
What happens is, if you had a “regular” Deployment of that Task Sequence first, it wins. Whichever Deployment is older, is the winner.
In my testing, I deleted the deployments and tested having them created in different orders, and whichever of the two deployments were created first, always won as the option to run.
Behind the Curtains
The Debugger lives in the Boot Media and as part of the CM Client install. TSD.exe is the brain behind it.
The TSManger component controls the debugger, but you’ll see additional information in the log depending on what you’re doing with the debugger
And there you have it, the Task Sequence Debugger in all it’s usefulness.