Debugging SCCM/ConfigMgr Task Sequences on the Fly

If you have worked with SCCM/ConfigMgr Task Sequences for any length of time, you’ve likely needed to debug them. Many times, you need to check the value of a Task Sequence variable. The generally accepted approach is to add a Run Command Line step to your Task Sequence and run ServiceUI.exe like this:

This approach is great if you planned ahead and you are in a test Task Sequence. It will pause the Task Sequence until you close the commnand prompt which allows you time to do any testing you need to do and even write scripts and test them live within your Task Sequence. It is a really handy tool to use. But what if you are trying to debug a production Task Sequence and can’t add the debug step?

I was trying to track down an issue with my Task Sequence where a variable wasn’t being set, but I didn’t want to add the debug step. The Task Sequence was still in WinPE so I opened a command prompt using F8. Then I launched powershell. From there, I ran the following 2 commands to get the value of my OSDComputerName variable.

Launching PowerShell and accessing the TSEnvironment from the command prompt.

The first line creates the TSEnvironment object which has access to all of the variables inside the Task Sequence. The second gave me the value of the OSDComptuerName variable. You can change this to any valid variable name. If you don’t know what variables are currently loaded, you can run this command to get a list:

This works great in WinPE as long as the Task Sequence is running. In some cases, adding the debug step is a better way to go if you need to pause at a specific point, but if you are just looking quickly check a value, this is a great way to do it. If you want to do this while in Windows, you need to be running as Local System. To do that, I use SysInternals Tools and run:

The -i opens the session interactively. The -s runas as Local System. Powershell.exe can be replaced by whatever process you want to launch in the system context. Once there, you can launch the same commands as above as long as the Task Sequence is running. 

This is just another tool to have in your SCCM/ConfigMgr toolkit. Hope it helps you someday.


  • Reply
    Drew Klingler
    May 3, 2019 at 8:30 am

    Thank you!

  • Reply
    Taylor Harris
    September 11, 2019 at 3:45 pm

    I got so tired of doing this lol. I ended up making a script that dumps all task sequence variables and their values to a CSV. It also collects all TS-related logs, ZIPs them, and saves the ZIP file on a network folder and then emails me with the ZIP file attached with some basic info about the machine and deployment in the body of the email. It will get triggered whenever a task sequence fails or when it completed successfully.

    This may be overkill for average task sequences though. Mine is very complex because it runs an application I made that gives the task sequence user a menu with a ton of options to control the deployment, from applications that get installed to AD options to user profile migrations that get triggered automatically so I tend to need this more frequently when making changes than I would just adding something like an “Install Application” step or running a single script. My app creates tons of variables and all of the task sequence steps essentially have connections of some kind to all of the others.

    If anyone is interested in help with doing something like this, just let me know. It’s not too much work. It’s only about two task sequence steps plus a script that does all of the capture work.

    • Reply
      Adam Gross
      September 11, 2019 at 3:58 pm

      The new Task Sequence Debugger in 1906 should help a lot with this. Also Jorgen from OneVinn has a great TS variables dump script as well.

  • Reply
    May 9, 2021 at 7:48 pm

    Thank you very much for sharing this little gem. Trying to diagnose a TS Variable at the moment for a TS Group step. Cheers!

  • Comment

    This site uses Akismet to reduce spam. Learn how your comment data is processed.


    Fatal error: Uncaught GuzzleHttp\Exception\ClientException: Client error: `POST` resulted in a `400 Invalid instrumentation key` response: {"itemsReceived":1,"itemsAccepted":0,"errors":[{"index":0,"statusCode":400,"message":"Invalid instrumentation key"}]} in /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113 Stack trace: #0 /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Middleware.php(66): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response)) #1 /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(203): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Response)) #2 /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(156): Guzzle in /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php on line 113