Why Win32_Product is Bad News!
This entry isn’t strictly related to Group Policy, but something I came across in that context a few days ago. There is a WMI class called Win32_Product. Querying this class lets you enumerate all installed MSI applications on a given system. This might sound useful for, say, a Group Policy WMI filter. You might be tempted to use it to create a conditional Group Policy scenario whereby you only process a policy if a particular application is installed. Here’s why that would be a bad idea. First off, Win32_Product is one of those horribly un-optimized WMI providers. What that means is that it could take many seconds or even many minutes to complete a query such as “Select * from Win32_Product”.In other words, its dog slow. So, putting it in a WMI filter means that GP processing will wait on the completion of that dog slow query before preceding. Not a great thing.
To make matters worse, querying this class has a very annoying side effect that I just learned about, and that is documented in this KB article (http://support.microsoft.com/kb/974524). Here’s the issue. When you query this class, the way the provider works is that it actually performs a Windows Installer “reconfiguration” on every MSI package on the system as its performing the query! You can see the effect of this in the application event log with dozens of Windows Installer messages showing each installed application being reconfigured. A reconfiguration includes validating the application’s install, up to and including doing an MSI repair if there is an inconsistency found between the package and the original MSI file. This was particularly irritating in one case where I had set a policy to disable a service that was installed on the system, but whenever a Win32_Product query ran, it would “repair” the application that had originally installed that service, thus re-enabling the service! Not good.
So, the lesson here is, avoid using Win32_Product at all costs–it stinks! Also note that the Item-level targeting filter for MSI packages in Group Policy Preferences DOES NOT use this problematic class, so you’re safe there.