Historically, whenever I’ve needed to test a new command added to an SCCM Task Sequence (TS), I would deploy the whole TS. Sure, I could disable most of it to speed up the test , but this would still took a long time. Especially if I had to test, tweak something, and then test again. Along came my colleague @ToddParkin and showed me a way around this, by which I could not only test my SCCM command, but test it as the SYSTEM account. Both are vitally important to make sure you have the syntax of the command correct and to make sure it will execute under the SYSTEM account, the account SCCM uses to execute Task Sequences. A huge thanks to Todd for pointing me in this direction and providing the content for this blog post.
When you’re troubleshooting SCCM installations, it’s important to figure out if the command line you’re using works in the correct security context of the SYSTEM account. Here’s how I usually do it:
- Open an elevated command prompt.
- From that command prompt launch another command prompt as the SYSTEM account using PsExec:
\pathtopsexec.exe /i /s cmd
- Now try to run the installation command line using the source directory path for your SCCM package or application under the SYSTEM context.
If this doesn’t work then you may have issues running under the SYSTEM context. You can then troubleshoot as a local issue outside of SCCM. If it does work, then the issue is with SCCM distributing content for your package or application. Troubleshoot accordingly in the SCCM logs. Here’s a handy list of the most helpful log files: http://configmgrblog.com/2011/08/17/troubleshooting-content-in-configuration-manager-2012/