Hardware Inventory and extending Quick Fix Engineering in ConfigMgr
In the comments of one of my PowerBI posts recently someone brought up a question about how do we tell if and when a patch was installed. This prompted me to start working on this post and talk about not only how to enable collection of the quick fix engineering information but why you should or shouldn’t do it and when it is or isn’t useful.
What is Quick Fix Engineering?
Before we get into doing anything with the hardware inventory or ConfigMgr I want to talk about what is Quick Fix engineering and why should or shouldn’t care about it. Quick Fix Engineering, QFE for short, is a WMI class known as WIN32_QuickFixEngineering. The purpose of this class is to track the Microsoft hotfix’s that have been applied to your device. However, with the advent of Windows 10 and the Windows as a Service (WaaS) model, the information that is returned has changed drastically. Historically one could run open Powershell and run the following PowerShell command and get ALL of the updates that are installed on a device:
Get-hotfix -ComputerName 'SomePCHere'
While this is is still true it’s not the case with devices that are in the WaaS model in fact devices in the WaaS model specifically newer Windows 10 machines are only going to show the most recent bundle of updates. To give an example here are the results of get-hotfix from my machine which I update every month.
Notice how there is only one update from earlier this year and that update was a strange one-off security update I manually applied? This should be similar on all Windows 10 devices.
However, if we run the same query on a 2012R2 server or a Windows 7 device we’ll get something that could be construed as much more useful:
At the end of the day, the QFE class is a WMI class that depending on your operating system will store important information about what hotfixes are currently installed.
OK So I know what it is but should I actually do anything with it?
This is a tricky question and I think it depends on what you are looking for and how modern your environment is. In the long run, I think the information in QFE is slowly going the way of the dodo bird. Sure I can think of some very specific use cases for it especially if your environment is still heavily invested in Windows 7 or if you want a second point of validation ‘Compliance’ data generated by WSUS. I’m going to show you how to enable collection of QFE data within ConfigMgr however, I encourage you to review and answer the following questions before extending hardware inventory:
- What percentage of your environment is on Windows 10 and Server 2016? The more devices on 10 and 2016 the less information will be returned from a ‘historic’ perspective.
- What specifically are you trying to get out of the QFE information?
- Most Recently Installed HotfixID and the date -> Is this because you don’t trust WSUS data for compliance or are you looking for more of a True/False statement?
- Installed By -> are you attempting to audit is someone manually patching things or is ConfigMgr doing it?
- Are you just looking for concrete proof of the last CU that was installed?
- Is the volume of data you are going to add to your environment by enabling this feature, worth enabling it based on the above questions and answers?
I answered your questions bridgekeeper now show me the way!
So by now, we’ve learned what QFE is and a little bit in how it’s relevant. It’s useful in telling us the patches that were installed historically for older operating systems, and the most recent installed CU for newer operating systems and while that data can also be gathered or assumed from update compliance information in WSUS this information is a little more True/False.
First lets take a look and see if we have QFE collection turned on anywhere in the environment. We can do this a couple of ways I’m a big fan of SQL and a quick query will answer this:
select * from V_GS_QuickFixEngineering
If you run the above and get the following, you’re not currently collecting any QFE data.
For my example, we are going to pop open the ConfigMgr console go to ‘Administration’ expand ‘Overview’ and select Client settings.
From the ribbon we are going to create a new Custom Client Device Setting I would suggest doing this for testing, but if you implement in production role this setting up with your existing hardware inventory settings.
This will open up the friendly neighborhood ‘Create Custom Client Device Settings’ dialogue box. From here we will want to name our policy, add a description, then select ‘Hardware Inventory’ as that’s what we are going to make a change to and then select ‘Hardware Inventory’ on the left-hand side so we can edit what exactly hardware inventory is doing.
Once we select Hardware inventory we will need to do a little configuration. I personally like hardware inventory to happen a little more aggressively than once every seven days. I actually have mine occur once every 24 hours so the first thing I’m going to do is select ‘Schedule’ and change it to occur every day.
Then I’m going to select Set classes from the previous image and in the search bar enter ‘Quick’ to filter down all the available WMI classes.
Now before we go any further I want to take a moment to examine the contents of what exactly we are turning on and you’ll notice something interesting. If you’ve ever run ‘Get-hotfix’ before you’ve probably noticed this is way more data than what comes back as a result. In fact, even if you run Get-WMIobject or Get-CimInstance its STILL more information than what comes back. A little digging with WBEMTEST or your preferred WMI explorer will reveal why. The information technically not a part of the class but is referenced from that class and can be selected by adding the explicit property to the selection. In the event you don’t, believe me, you can prove this out by:
When you click connect you’ll get the following:
You will then want to select ‘Enum Instances’
And enter the superclass name ‘Win32_QuickFixEngineering’
Select one of the options and double click it, do not click the add or delete buttons.
This will load the object editor for the specific KB and you can see that the ‘Caption’ field if you double click on it is related to an entirely different object.
Returning from our detour for our example I’m only going to select the information that I care about:
You can then hit OK on this, and OK on the client settings. And then deploy them to a collection by right-clicking the client setting, select deploy and then choose the collection you would like to depoy too.
You can then wait for a client to check in, or use client notification to force the test machine to download policy and then collect hardware inventory. As you can see the information for my CAS has already come back:
Now that you’ve started collecting this information you can use it for collecting specific HotfixID’s just be aware of the limitations of the data as well as the upsides in reporting. This table can be joined to other tables using the ResourceID column.
Jordan has been working in the Industry since 2009. Since starting he’s worked with Active Directory, Group Policy, SCCM, SCOM and PowerShell. Jordan currently works in the healthcare industry as an SCCM Infrastructure Team lead supporting over 150,000 endpoints. Most recently his focus has been in SQL Reporting for SCCM, creation of PowerShell scripts to automate tasks and PowerBI.