Anyone who has worked with Configuration Manager for a while knows about Packages, Programs, Advertisements, and Collections. They also know the difference between "Software Products" and "Add Remove Programs" as it pertains to inventory reporting. Seasoned software packagers (or more appropriately termed "repackagers") know about creating .MSI and bootstrap .EXE InstallShield packages as well. But there's a sinister problem lurking in all of this...
The names assigned to Packages, Programs, Advertisements and Collections are arbitrary. Sure, many places have adopted standards for naming things, but still, it's a human dependency.
The names assigned to an application are controlled by the vendors, but only if they created the application. And then there's the issue of how well they apply consistent naming standards to their individual components.
Just yesterday I was poking around to find how many installations of a product at version "7.11.3" were in our environment. As I watched the report start to build, it was showing "7.10" and even "7.9.1" installations as well. But the engineers assured me that the package they deployed had uninstalled previous versions before initializing the new installation. After some investigation, it turns out the vendor left components in their 7.11.3 installer that still identified themselves as "Product Name 7.9.1" so Configuration Manager dutifully picked it up and reported it. Switching over to the ARP (that's Add or Remove Programs list) report, it correctly showed 7.11.3 was the only installation.
I won't even get into the products that dump garbage components on computers that identify themselves with product names like "Update", "O&%$__#" and "Company Name". So far, free markets and consumer-driven competition are not doing much to fix that mess, but neither would and overly restrictive government regulation. It's just typical stupid human behavior (e.g. laziness).
Back to the topic.
So, when pulling a report of what software is installed on computers, it can be helpful to also include some attributes for each product such as "Is-Packaged", "Is-Windows7-Ready", "Is-Current-Supported", and so on. You can beat some of that out of Asset Intelligence, but some you cannot. For example, to really know if an installed product has a corresponding Configuration Manager Package and Advertisement, you need to somehow relate the installed Product Name and Version to the Configuration Manager Package and Advertisement. Sounds easy enough, right?
Ok, you've got an environment where you have deployed 500 installations of AutoCAD 2012 using a network license client, and 25 of AutoCAD 2012 with a standalone license. From ARP reports it will show them all as "AutoCAD 2012 English" or something generic like that. But you can't use the same package to deploy both (well, you could, but now we're talking about some twisted branched logic in the package using a script or some other intermediary program logic), so how would you know that you've got "A Package" for "AutoCAD 2012" and which one it belongs to?
Even if you switch to linking to the Installed Programs list (pulled from a query of .EXE files on the computer) it would show "AutoCAD 2012" or "AutoCAD R18.x" or something like that, not "AutoCAD 2012 Network Client", because they will both read from "acad.exe" and the only difference you could pull might be the size of the file itself. What about products that are only installed as part of another product advertisement? What about all those Autodesk Design Review and DWG True View installations that were placed by your various AutoCAD and Revit and Inventor deployment packages? How do you automate the referential integrity of those applications to a source package and advertisement?
In case you haven't already surmised, this is all analogous to Reverse Lookup DNS. Forward lookup is easy: This package and advertisement installs this application. Fine. Now, what package and advertisement installed this application on these 100,000 computers? How do I automate that workflow?
What happens when you have in-house developers and packagers putting together things to deploy? How about those not uncommon cases where the package doesn't really install a product, but registers components and files that support another product, but which are given their own name by virtue of how business operational minds like to give names to things that don't really exist? You know, when you install and register three DLL files, open a firewall port and now the user can access a special web application in their browser, so that deployed bundle of crap is given the name of whatever it is that they connect to via the browser. It's not really an installed application, is it? If the users rely on this to connect to a web application named "Fubar", good luck convincing them to call it "installed components to support Fubar". They're going to call it "Fubar" and ask "when are you going to get my Fubar installed?" Oh yes. You can bet on that.
I'm digressing. It's much easier to convey this verbally than in writing. I have lots of stories to illustrate this weird delusional mess.
This is the mind-bending thought process that swims around in my head as I've been building a web-based asset management process for a customer. The process allows them to overtly control these arbitrary relationships for more than just reporting. It also allows them to manage distribution that comes into play when executing computer replacements versus computer refreshes (refresh in this case means upgrade the OS and map in required application upgrades at the same time).
For example, the computers in a particular department-based collection all have XP and Office 2007, but they will be reimaged via SCCM OSD with Windows 7 and Office 2010, but they each have unique LOB (line of business) applications installed. Many require an upgrade to work with Windows 7, or the customer budgeted for new versions based on feature enhancements and decided to tie it into the same upgrade window. Regardless, they needed a quick and easy way to select an upgrade mapping individually and in batch to say "these computers get the newer version" and "these don't get an upgrade" as well as "remove it from these computers entirely". It's much more complex than this, but that's a simplified example.
In short, all I can say is that I LOVE working with this stuff. It falls squarely in the field of work I crave: "Windows Platform Business Process Automation" or WPBPA. I believe I invented this term, so neener neener neeeeeeener. I need some breakfast and coffee as I've been up all night working on my next book project. Holy cow - what sleep can do for you. Cheers!
No comments:
Post a Comment