This topic came up recently in the forums. After pondering it for a bit, I thought of several ways to obtain the information you need about a non-security hotfix. Which approach you might take depends upon what you need, or what you need to do about the information, once you have it.
Beginning with the OS' of Windows 7 and Server 08; hotfixes aren't listed in Add/Remove Programs. That is normally fine because we have Software Updates.
But some non-security hotfixes seem to never be detectable with Software Updates.
A couple of suggestions:
- Before you check into any of the below possibilities, there are a lot of non-security updates which ARE detectable via SUM. It may be that you simply haven't enabled that Category in your Software Updates Management. Do a custom Search Folder in your Updates, and look for that hotfixID; see if it's there already. If not, go to Site Settings, Component Configuration, Software Update Component, and carefully review the "Classifications", and "Products" tabs. You normally do NOT want to enable everything. But just check to see if what you are missing is simply because you didn't check the box for that product.
- If you have the addon to ConfigMgr, System Center Updates Publisher 2011, you can design your own rules for deploying an update, using the same methods that are used by security hotfixes. That does take time, testing and planning of course. There are guides out there on how to do so when you need to deploy a third party update which doesn't have a SCUP catalog. For example, Adobe does have a 3rd party catalog for SCUP, but currently Java does not. (This is the one I would pursue if I needed to have a long term solution, if it was a quick one-off, I'd probably pick one of the other possibilities below).
- Another possibility for finding non-security updates is the following. Although it was no longer enabled by default in the inventory definition file (sms_def.mof), it does still exist, and can be enabled (win32_quickfixengineering). So you could enable that (change from FALSE to TRUE) and get the information back. Personally, this is a lot of data for very little return; but it is one of the easiest solutions to implement. (I wouldn't enable it in my environment, but it may be the right answer for your company.)
- If you know exactly which hotfixid you are looking for, you could create a DCM ConfigItem to look for
that specific hotfixid in win32_quickfixengineering. (This is my favorite; of course, I'm enamored of DCM in general)
- And Yet Another Possibility is this. win32_quickfixengineering does contain all of the information, including security hotfixes. We're already getting Security hotfix information from Software Updates. So to have that information twice just seemed like a waste of space. Here's a potential custom mof edit, to get back updates, but not security updates which you already get. There will still be some overlap; because some non-security updates are already available in SUM (Software Update Management), but it's less overlap if you use this mof edit:
///Put the following on the bottom of your configuration.mof
//======================================
// Quick Fix Engineering, Limited
//======================================
#pragma deleteclass("qfeLTD",NOFAIL)
[Union, ViewSources{"select HotfixID,Description,ServicePackInEffect from win32_quickfixengineering where Description<>'Security Update'"},
ViewSpaces{"\\\\.\\root\\cimv2"},
dynamic,Provider("MS_VIEW_INSTANCE_PROVIDER")]
class qfeLTD
{
[PropertySources{"HotfixID"},Key ] string HotfixID;
[PropertySources{"Description"} ] string Description;
[PropertySources{"ServicePackInEffect"},Key] string ServicePackInEffect;
};
////Put the following on the bottom of your sms_def.mof
//======================================
// Quick Fix Engineering, Limited
//======================================
#pragma deleteclass("qfeLTD",NOFAIL)
[dynamic, provider("MS_VIEW_INSTANCE_PROVIDER"),
SMS_REPORT(TRUE),
SMS_GROUP_NAME("qfeLTD"),
SMS_Class_ID("CUSTOM|qfeLTD|1.0")]
class qfeLTD : SMS_Class_Template
{
[SMS_Report(TRUE), key] String HotfixID;
[SMS_Report(TRUE) ] String Description;
[SMS_Report(TRUE),key] String ServicePackInEffect;
};
My company did have the custom mof edit in place for about a month. It worked fine, but we determined that it was literally one non-security hotfix that was being looked for. So instead of getting back everything (it ended up being 8gb of data in the database!) I instead created a DCM rule to look for the specific hotfixid in win32_quickfixengineering.