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:
(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
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.
|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.