I had a very long week, which means I'm writing a short post this time around.
Among several seemingly disparate things I accomplished in the last week or so, I spent some time deploying applications via SCCM (soon to be called Microsoft Endpoint Manager/Configuation Manager/#MEMCM per the announcement at Ignite this week).
My normal process (for most things save for simple .MSI installs) is to use a wrapper Powershell script to encapsulate the command line invocation, handle variables, logging, and anything else necessary like generating specific detection output. It works really well, provides consistent logging output, and is generally well-behaved. As a wrapper process, however, debugging or troubleshooting is further abstracted and has been a pain point for tricky installations.
It's Really Simple
Normally, the "install" command line syntax is pretty straightforward:
powershell.exe [optional arguments] -file ".\WrapperInstallScript.ps1"
I've used it hundreds of times, usually without issue.
I did my testing on a VM as usual, making sure a manually-invoked install with
WrapperInstallationScript.ps1 behaved as expected. It did.
I pushed all the content to the appropriate share, created the application and deployment, and shipped it off to install (via on one of my test/non-production VMs with a CM client). It did not work.
After far too much looking elsewhere, I discovered my problem:
powershell.exe [optional arguments] -file "WrapperInstallScript.ps1"
Don't do the above. You will regret it.
My PEBCAK (Problem Exists Between Chair and Keyboard) stuck out like a sore thumb as soon as I looked there. No wonder "
The system could not find the file specified." As I've said before, context matters.
I feel like I should submit a Dove Chocolate saying:
Use the .\
Key takeaway: look for the obvious in troubleshooting. Keep that zombie in the ground. :)
Headline image via giphy