Why bother with wrapping a decent vendor installation package inside a script? To borrow a quote from Lawrence Fishburn’s character in the Matrix: “Control”. Dark room. Smoke. Sunglasses. And no, I’m not taking you to see the Oracle.
Seriously. This is a question that executives and non-technical managers ask very often. If you have a nail why not beat it with a hammer? And if it works on nails, why not use the same hammer on bolts, pins, clamps and clips?
You can laugh or roll your eyes, but this is a very serious question. It often takes on serious ramifications such as decisions regarding budgets, hiring and staff reductions. I’ve seen it more times than I’ve cared to.
More than that, for the aspect of scripting, is the powerful capability of “abstraction”. Usually, when we think about the benefits of scripting or programming, our minds tend to focus on the sequential or batching aspects. Being able to invoke one thing which then invokes many things behind the scenes. Or many things simultaneously.
If you really need a discrete example, consider the all-too-familiar scenario of creating a folder, copying files into that folder, and then applying permissions on the folder (or files within it). You could type in each command statement, press Enter and wait for the request to be completed, and repeat until all of the steps are done. Or you could dump all those command statements into a single script and run it once.
You could crack open InstallShield AdminStudio and make a fresh cup of MSI packaging. But if you don’t own a license, be prepared to crack open your checking and savings account as well. Scripting is free.
But with scripting you also gain access to the many built-in features of the script platform, which allows you to perform condition checks, make adjustments during execution, control logging output, and handle notifications (alerts) if desired. That’s just a small sampling of the benefits. But you already knew that, right?
Back to the main topic now. Let’s examine two (2) scenarios:
– A single .MSI package
– A pair of related .MSI packages
In the first scenario, you are given a basic .MSI package to install. You could open up the ConfigMgr console, create an Application or Package object, and shovel in the standard “msiexec /i blah.msi /qn” program instructions and be done. But what if you’d like to check for multiple conditions and take different actions based on each one? You could create multiple global conditions in ConfigMgr to handle each of them, but what if you can’t justify ever using them for other applications? What if the condition checks are so unique, you are forced to use script code for the condition checking? While you could create new global conditions and requirements for every application, in many cases (most, from what I’ve seen) scripting offers more flexibility with less clutter dumped into the SCCM environment.
In the second scenario, let’s take Microsoft Remote Server Administration Tools or RSAT for Windows 8.1. This actually applies to the older Windows 7 version as well. You have two .MSU files, one each for 32 and 64 bit platforms. You could create two collections, two deployment types and create essentially four program entries (install and uninstall for each), or wrap both in one script that checks for the CPU type and executes the one that applies. Done. In fact, you could wrap all four .MSU packages, two (2) for Windows 7 and two (2) for Windows 8.1 into a single script and now you have one “RSAT” deployment for all of your target platforms.
Am I suggesting never to use global conditions in SCCM? No. In fact, for things like verifying .NET Framework 3.5, it’s probably a good idea. You can add a lot more as well. But for things that are either infrequently needed, or which fall beyond the basic scope of what SCCM provides, like checking for installed version of Internet Explorer, or finding every TNSNames.ora files on a client, or checking each and every version of Java runtime for each and every stupid app that only works with one specific version, script-wrapping is a good option.
So, when a manager asks why you bother writing script code to use with sccm, you can turn around and ask them if they ever salt, pepper or season their food. When they say “yes”, ask them why they don’t just eat it as it comes in the packaging.