Win32_Product Is Evil.
February 20, 2012 9 Comments
This is an encore presentation from my old blog.
I’m a bit of a fan of Windows Management Instrumentation (WMI), but today’s post is a bit of a ‘buyer beware’. I’ll sum it up, and then provide some detail and give you some ideas of where this can be a very bad thing. For starters, go to a TEST system (Windows Server 2003, Windows Vista or later), launch a PowerShell command prompt (run as administrator so that you have full rights), and run the following command:
get-wmiobject win32_product
(PowerShell is used for simplicity here – this issue occurs in every way you query Win32_Product )
Win32_Product will return some great information about each windows installer-based application. In fact, you can even view additional properties by running get-wmiobject win32_product | select * . However, even though you called a basic query of the Win32_Product class, you actually performed a consistency check of each installation. Take a look at the Application Log after running the previous command (event viewer), and you will see something similar to this:
EventID = 1035
Source = MsiInstaller
Details = “Windows Installer reconfigured the product…. ”
Each of these entries is for a Windows Installer product, and you can see in the details that each product was ‘reconfigured’ – luckily, if you have healthy Windows Installers, everything should be happy, and the consistency check just confirms that. If however you have systems that are unhealthy, or the installation has been altered in some way, this could cause a failure during the consistency check, or a failure of the application after the reconfigure.
The bottom line is that I expect when I query a WMI namespace, that ONLY a query occurs. Unfortunately, with Win32_Product, that’s not the case.
Here’s a KB article for Vista and Server 2008 that explains a scenario with using Win32_Product as a WMI Filter in group policy – the same info applies when querying Win32_Product manually or with an enterprise systems management tool.
Event log message indicates that the Windows Installer reconfigured all installed applications
http://support.microsoft.com/kb/974524
The article only applies to Vista and Server 2008, but I can confirm that the same thing happens on Server 2008 R2 and Windows 7.
Now that we’ve talked about the general issue, let’s talk about where things can go bad with using Win32_Product in ConfigMgr.
| Win32_Product Use | Potential Issues |
| System Center Update Publisher (SCUP) | Using Win32_Product in an Applicability rule will cause every system in your site (regardless of collection membership) to run the query, which causes the consistency check/repair. You can’t control this on a collection level. All clients that are configured to the Software Update Point will perform the scan. This custom update automatically replicates to all children sites with Software Update Points. Each time a scan is run, the Windows Installer consistency check/repair will run. |
| Desired Configuration Management | Creating a Configuration item (CI) with win32_product will cause every system that is targeted with the CI to initiate the consistency check/repair each time the baseline rule is evaluated. |
| SMS_DEF.MOF (hardware inventory) | Untested, but I believe the consistency check/repair will occur each time hardware inventory runs for all clients in the site. |
| ConfigMgr 2012 App-Model Deployment Types | If deploying to USERS, the consistency check/repair will occur when a user attempts to install the software from the software catalog. If deploying to DEVICES, I the consistency check/repair will occur when the client checks to verify that software is installed. |
So as you can see, in the ConfigMgr world, there are many ways to use win32_product that can cause you to have a bad day. So be careful with win32_product!
The good news is that (so far) the message reported is benign, and it doesn’t seem to actually cause a repair. If you encounter a product where this does cause a repair, please send me the info asap.
Greg
About Greg Ramsey
Greg's Systems Management Blog 
Pingback: Win32_Product Is Evil « « Chris Nackers BlogChris Nackers Blog
Pingback: Retrieve UninstallStrings to fix installer issues | Tech thoughts
Pingback: Uninstall Software En Masse - ConfigMgrFTW!
Holy Cr__ ! I, like a fool, decided to try this before I read further about what about get-wmiobject win32_product was evil… I’m a fan of WMI also. Which goes to show how evil it is – a query forces a consistency check which possibly changes the install!? Wow – that is evil. What have I done?
Pingback: Using PowerShell to Uninstall Applications with Hardware Inventory | Enhansoft
Pingback: Using PowerShell to Uninstall Applications | Enhansoft
Out of curiosity I just tested this on Windows 10 1909 (build 18363) Enterprise Win64, it’s still happening. It created event ID 1035 from MsiInstaller, 56 times on a new test VM with hardly anything installed.
yep! win32_product IS evil! 🙂
As a better alternative for SCCM enabled clients, you may use the WMI namespace “root\cimv2\sms” and Class “SMS_InstalledSoftware”, you can get the Product Code of the MSI installation from the property “SoftwareCode”.
It works like a charm, just a small advice regarding Powershell based scripts, better use “Get-CIMInstance” instead of “Get-WMIObject”, it gives you a cleaner output that is also a breeze to manage/use.
My 2 cents Greg 🙂 (long time no see)