Group Policy and WMI filtering slowness.

Group Policy and WMIHaving spent time investigating slow network logons, I dislike using WMI for Group Policy filtering.  It just adds a layer of slowness to logons.

WMI filtering does has it’s place, and I do still use, and occasionally recommend it for very specific reasons.  Such as when we’re piloting a new version of Microsoft Office (2010), and we need to only apply the specific Office 2010 group policies to Office 2010 pilot users.

But what I’ve done, and I suspect most people do though, is grab the first applicable WMI class and use that.  The first applicable WMI class I’ve grabbed is Win32_Product.

Which would be a silly thing to do.  In the words of Microsoft:

Win32_product Class is not query optimized. Queries such as “select * from Win32_Product where (name like ‘Sniffer%’)” require WMI to use the MSI provider to enumerate all of the installed products and then parse the full list sequentially to handle the “where” clause. This process also initiates a consistency check of packages installed, verifying and repairing the install. With an account with only user privileges, as the user account may not have access to quite a few locations, may cause delay in application launch and an event 11708 stating an installation failure.

Microsoft KB 974524 Event log message indicates that the Windows Installer reconfigured all installed applications

Far better in this case to follow Microsoft advice and use Win32reg_AddRemovePrograms.  For the sharper eyed readers, you can see that very thing in the picture above.

With thanks to SDM Software, where I first saw this issue written about.