Having 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.
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.
Related posts:
So what does the Group Policy Preferences Drive Mapping log file contain?
Saturday Link Roundup–Group Policy, Kerberos, BranchCache
Group Policy and WMI Filters–Round 2
Powered by YARPP.