Environment Context Troubleshooting

Broken Context(s). The story of my weekend project.

Due to a number of reasons, mostly well outside my direct control, I spent part of this weekend working through the application and task sequence refresh process for our multi-user workstations...which will need to be finished by August 27.

Most of the processes will remain as they did for last year. I'm intending to improve and further streamline some of the primary task sequence itself to better isolate certain applications and automatically target their deployments. In the past, specific, targeted deployments (often very location-specific) were handled post-TS with normal collection required deployments, but then the rebuild/refresh wasn't "done done" until some time after the TS completed.

Today's primary task was finally working through the small-ish number (~12) of applications with version changes, in addition to rolling our "keyserver" over to the next major version. The latter part was pretty trivial as it usually goes, and most of the other applications were also fairly straightforward (update version, make minor mods to install script(s), deploy, test, bake into TS).

That "One App," Though...

One application proved to be the bane of my existence today. It was a combination of major version change, license change, and deployment process change. Now the first two things...pretty normal.

The deployment process change can go to a Bad Place...

For anyone who deploys with SCCM, they understand the pain and suffering with applications that won't quite silently install (or activate) without some form of dark magic. Sure, the vendor's custom install app is super sweet and does All The Things, but try to run that thing with a silent switch? Why the hell would you ever not want to run the install manually? It's just a few hundred machines...

So it goes with this vendor. They provide, however, very explicit and detailed instructions on how to do a silent install...which boils down to:

• Unpack the custom installer (read: capture the temp files from the install wrapper);
• Copy the specific files you need for your situation (almost all MSI's, by the way);
• Build a custom script to install all of the extracted MSIs in a specific order;
• Test this stepchild of a process against your environment (they fail to mention salt circles and candles in this step);
• Whip up a custom .ini file used in activating the software;
• Call a specific activation exe to "silently" activate the software (with specific arguments, but not an argument for the .ini file above—that has to be at a specific location). It also doesn't return anything to indicate success or failure...; and
• Pray it all works just exactly as easy as they mention.

Of course, it doesn't. For a time I longed to encounter the "old way" (though I really loathed the need to export and set a bunch of registry entries via Group Policy or Powershell) which at least worked and was relatively trivial. After some thought, I ended up splitting out the MSI's into their own individual deployments (with dependencies to address the specific order just in case I need to run this as a deployment outside of the task sequence), which wasn't awesome but works just fine.

90% of the time spent, however, was getting the damn activation to behave in a Powershell script. And that's what leads me to:

Environment Context Matters

Because this particular app just says "Put x here and run y; it'll work. Trust us." there's very little in the way of documentation or examples on how to accomplish this task. At first I decided to avoid using my trusty, well-worn Powershell deployment wrapper (created by some colleagues a number of years ago), since it seemed way overkill for what ends up being a simple "batch" script call.

So a three-liner of Powershell it was. Worked in a one-off test, so time to roll it to the deployment.

Failed.

Ugh.

It took me far too long to figure out that I'd made a simple context mistake. When run via SCCM, even though the paths are all correct, adding $PSScriptRoot to the path variable totally fixed the problem.

Until I rolled the deployment with SCCM.

Failed. Again.

What the hell?

Rinse, repeat with minor modifications until I finally decide to go overkill with the old standard. I could get the script to run when invoked directly from the ccmcache location; it failed every time I used Software Center's interface, so the old standard way was going to give me more information as to the fail point(s).

It Became Obvious

As soon as I invoked the standard (to me) way, I didn't see the script log written...so I finally knew where my problem lie: the deployment type program invocation.

Sure enough, I was a little rusty with the old commands in the SCCM console. I'd wrapped the .ps1 filename in quotes and included unnecessary arguments in its call (since I was more used to recently using native and solely Powershell), so the failure was actually in the way in which I called the install script...not the script itself.

Wish I'd have known that 45 minutes earlier...

Voila! It worked when corrected...

So the takeaway on this one is multi-faceted. Your environment context totally matters: in calling your script(s), in having your scripts understand where they are, and in "why am I working on this over a weekend, again?"

Headline image via TeX StackExchange