Recently, Andreas Stenhall posted a fantastic blog post showing some PowerShell code to identify applications that are dependent upon other runtime frameworks such as .NET for Visual C++. This got me extremely excited as Visual C++ 2005 is already End Of Life and VC++ 2008 will be going EOL early next year.
Being able to quickly and easily identify applications that could be impacted if one or more of these legacy frameworks are removed has been, up until now, been primarily a manual effort.
This post is designed to expand upon Andreas` work and extend his solution into SCCM where a majority of us actually manage our systems.
Extending SCCM Inventory
The first step is to extend your ConfigMgr inventory to collect the proper WMI Class data during Hardware Inventory.
To do so, open up your Configuration Manger Console and browse Administration > Client Settings > Default Client Settings and open Properties.
Select Hardware Inventory and hit the Set Classes button.
Click Add, Connect to a computer and search for the following WMI classes
Hit OK thru the remaining windows to save your changes. During the next inventory cycle the information should begin to populate in your ConfigMgr Database.
Creating a Report
Now that we’ve inventoried the data, we need to do something with it. Creating a report is a great first start as we can start searching for applications running EOL or near-EOL frameworks and begin either upgrading those applications or working with the Application Developers or 3rd Party ISV’s to get them updated to use a newer framework.
Now, for those of you who are used to writing SQL Queries and reports against inventoried data, I caution you to leverage the SQL Code below and/or the RDL I’ve attached to this post. The v_GS_INSTALLED_WIN_32PROGRAM View can get HUGE. This in turn dramatically slows down the SQL. Especially in an environment with tens of (or hundreds of (thousands of clients.
If you simply want a SQL dump of all the Programs and their associated frameworks, you can use the following SQL code:
SELECT DISTINCT prog.Vendor0, prog.Name0, prog.Version0, pf.FrameworkName0, pf.FrameworkVersion0 FROM (SELECT DISTINCT ProgramId0, FrameworkName0, FrameworkVersion0 FROM v_GS_INSTALLED_PROGRAM_FRAMEWORK) pf LEFT JOIN (SELECT ProgramId0, Vendor0, Version0, Name0 From v_GS_INSTALLED_WIN_32PROGRAM) prog on pf.ProgramId0 = prog.ProgramId0
This query has been optimized so that it executes within about 25 seconds in my environment with ~30K systems. To further improve this (as I have done with the report), add on a WHERE statement to filter the information down even further by the FrameworkName as such:
SELECT DISTINCT prog.Vendor0, prog.Name0, prog.Version0, pf.FrameworkName0, pf.FrameworkVersion0 FROM (SELECT DISTINCT ProgramId0, FrameworkName0, FrameworkVersion0 FROM v_GS_INSTALLED_PROGRAM_FRAMEWORK) pf LEFT JOIN (SELECT ProgramId0, Vendor0, Version0, Name0 From v_GS_INSTALLED_WIN_32PROGRAM) prog on pf.ProgramId0 = prog.ProgramId0 WHERE pf.FrameworkName0 = @FrameworkName AND pf.FrameworkVersion0 = @FrameworkVersion ORDER BY prog.Name0, prog.Version0, pf.FrameworkName0, pf.FrameworkVersion0
The above query is what I use within the report. You will notice two SQL Parameters which correspond to the FrameworkName and FrameworkVersion that you want to query against. This allows you to search for systems based on a specific framework and version (think EOL hunting).
Download Report – You’ll need to update the datasource within Report Builder and point it to your own data source.
Now that you have access to the data, you can begin identifying applications that are dependent upon older versions of software frameworks including Visual C++, Java, etc. From there, start building collections of systems that have these older applications installed to handle upgrades as well as the (eventual) removal of the legacy runtimes.