So, I tweeted some nonsense about writing a PowerShell script to batch import Applications (or Packages?) into System Center Configuration Manager (aka SCCM, aka ConfigMgr, aka OMG this is a long name). The idea isn’t new or original, and there may be another script already out there to do just that. But I got the idea from dealing with bouncing in and out of customer environments and doing packaging projects for various places, etc. The other part of this hair-brained idea came from seeing what Kent Agerlund had done with importing drivers.
This post is about thinking out loud. Walking through *one* logical (maybe) approach to a challenge from a software development aspect.
The catch, however, with drivers versus applications, is that drivers tend to be somewhat monolithic. They’re either .INF based, or installer based (e.g. setup.exe). Applications can be .MSI, .EXE, .APPX, and any one of a dozen script languages as well. There is a third type also, commonly referred to as “absolute shit”, but I’m ignoring those for now.
So, aside from embracing a proxy installation platform, like NuGet and Chocolatey, which are great, I wondered how this might work with a folder structure, populated with vendor goodies. Something still needs to fill that logical “gap”. The gap between a fairly consistent deployment pipeline (i.e. ConfigMgr), and the soup of diahrea-infused, bong-smoking, pill-popping mess that vendors dump on us to try and “push out” via silent installations.
SIDE NOTE: I have a dream, not like MLK’s dream, but one which involves Microsoft dropping the hammer on vendors and supporting only one process for installing software applications. One that says “do it this way, and provide these characteristics, or good bye”. I know that’ll never happen, but it’s okay to dream.
One approach to closing the gap would be to provide targeted instructions. The catch here, from a logical aspect, is that the instructions need to be as simple, well-defined, and compact as possible, or it risks creating a parallel data environment that only adds to the problem, rather than reducing it. Keeping in mind that the goal is to import a bazillion applications from source content folders, and somehow figure out (during runtime) how each is to be defined within ConfigMgr for both Installation and Uninstallation deployment types.
Here’s my thought so far,
Looking through one customer’s mess, I found most of the source content falls into one of three toilets, oops, I mean ‘bins’:
- Windows Installer (simple .msi files)
- Executable (setup.exe)
- Scripted mess
My first prototype uses a designated data file, named “_appdef.txt”, which contains two (2) lines: one for “install=” and the other “uninstall=”. Assigned to each is an instruction (command) to perform. For example: “setup.exe /VERYSILENT” or “fubar.msi /qb!”
$crap = Get-ChildItem -Path $CrapSource -Directory -Recurse
If the folder contains this magical “_appdef.txt” file, then its contents are imported and used to perform the application definition. If the file does not exist, then it looks for a single .msi file. If more than one exists in the folder, it skips on to the next folder. If it exists, then it uses a PowerShell function to read the “ProductCode” property from the MSI database, and uses that for the uninstall (e.g. “msiexec /x {8E14ADF3-1B18-4711-87BD-E3827D395466} /qb!”)
The Drawbacks
Every model has some drawbacks to consider. It’s part of the way Nature works as well. For example, trees are tall and beautiful, they absorb CO2, and sunlight and make fruits and berries… but they also fall over and kill things at times. So, back to my rambling, …
The drawback with this model is that nature of Application definitions (like Packages as well) is that the “data source” path is tightly coupled to the distribution and deployment process model. That means that anything left in the data source folder gets replicated throughout the distribution channels. This includes the _appdef.txt files as well.
Aside from miniscule file size overhead, which is almost negligible, there’s the data exposure risk. That’s right. Some installation statements may include pieces of information that are somewhat sensitive, such as product keys, license codes, user names, reference paths and servers names, etc. You may not want those distributed throughout a ConfigMgr hierarchy. It’s best that those instructions reside entirely within the database tables, as they would when creating Application definitions within the ConfigMgr admin console.
Another drawback is the input / setup time.
Thoughts
What would be nice, in lieu of vendors being tasered in the crotch and beaten with tube socks filled with pepper spray cans, would be if they provided a consistent ConfigMgr-friendly payload file. That would be some sort of file that provides everything need to import into ConfigMgr. Then customers could copy or extract the source binaries, along with this magical payload file, into their own directory structure, and run a batch import from within ConfigMgr to forage through them all and create the appropriate Application definitions automatically. All that would be left for the customer at that point would be to distribute the content and deploy to Collections.
This is, of course, entirely hair brained and silly. I might as well be talking about “Peace in the Middle East 101” or “Curing Cancer with two sticks and some mud”.
Skatterbrainz Blog 