Group Policy and WMI Filters–Round 2

Sexy Coffee at North Denver and Rosa Parks Way in Portland, Oregon - Wikipedia user Visitor7This is more of a link dump than anything else.  I was asked what I thought of a WMI-related Group Policy change.

I don’t much care for them.

So I know that WMI Filter queries are a bad idea, but didn’t know how to measure that badness until I saw this blog post (WMI filter queries and thoughts on performance) by Martin Binder.

You can enclose your WMI Filter in a PowerShell “Measure-Command” command, and measure it that way.

Measure-Command { for ( $i=1; $i -le 1000; $i++ ) { Get-WmiObject –Query "SELECT Model FROM Win32_ComputerSystem WHERE Model LIKE 'Compaq Presario A%BB%'" } } | Select-Object TotalMilliseconds | Format-List

TotalMilliseconds : 23308.6037

As the command is looping 1000 times, you’d divide by 1000 and get the answer 23 milliseconds.

Group Policy and WMI filtering slowness
Optimizing Group Policy WMI Filters
Introduction to WMI Basics with PowerShell Part 1 (What it is and exploring it with a GUI)

The Microsoft “Ask the Performance Team” write about WMI

And I am going to include the links here, because a) they are useful and b) they compliment some of the posts I’ve written about WMI (Group Policy and WMI Filtering Slowness / The WMI Fix – which is better? / The WMI overflow error with getobject )

Ask the Performance Team:

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.

WMI and WMIC example text for common queries

This is straight from the Microsoft Technet July 2005 CD set.  I’ve not seen it elsewhere, and since I’ve found it so useful, I’m going to repost it here.  WMIC is the command line interface to WMI.  Using the WMIC alias makes it easier to return computer information, all from a command line.

The following table contains example text of common queries using WMIC Aliases.  To run one of the queries, cut the entire contents of a cell in the Example Text column, paste at the WMIC command prompt, edit the variables as appropriate, and press the ENTER key.

Continue reading

The WMI fix – which is better?

Back in April, I wrote two posts about fixing a broken WMI.  There was some thought that deleting the WMI Repository WAS A BAD THING.

Well maybe not…

Across 600+ computers, I learnt the following:

  • Not deleting the WMI Repository fixed about half of the computers.  In the computers which were fixed, the SMS client immediately sprung back into action.
  • On the other 300 computers, the WMI fix made NO difference.
    These were the cases where deleting the WMI Repository DID fix the problem.
    BUT the SMS client needed to be woken up by re-running an SMS advertisement on the PCs.

So in summary, for stubborn broken WMI problems, deleting the WMI Repository should resolve the issue, but will require you to do some extra work.

Bookmark and Share

WMI has stopped working on some remote computers.

And I don’t know why.  My strong guess is that it is related to one of the 10+ recent Microsoft security patches I’ve deployed to the fleet.  (I’m looking at you .Net Framework 2.0)

The fix so far? Rebuild WMI and repair the SMS client.

I do this by:

  • copying wmirebuild.bat and runrepair.vbs to the target computer.
    the purpose of runrepair.vbs is to HIDE the running of wmirebuild.bat, so the end user doesn’t see it.
  • remotely run runrepair.vbs via a PSEXEC command.

Yes, it’s a bit kludgey.  It’s a fast fix.

Dim objFSO,objNet,objShell,drive_status
Dim objWMIService, objProcess, colProcess, strComputer, strProcessKill
Dim sWbemPath,sSystemRoot

On Error Resume Next

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objShell = CreateObject("WScript.Shell")

sSystemRoot = objShell.ExpandEnvironmentStrings("%systemroot%")

'check that system32 directory exists.

If Not objFSO.FolderExists(sSystemRoot) Then
End If

If Not objFSO.FileExists("c:\temp\wmirebuild.bat") Then
objShell.Run "c:\temp\wmirebuild.bat", 0, True
End If

Set objShell = Nothing
Set objFSO = Nothing


net stop ccmexec
net stop VMAuthdService
net stop winmgmt
cd %systemroot%\system32\wbem
rem rd /S /Q repository

regsvr32 /s %systemroot%\system32\scecli.dll
regsvr32 /s %systemroot%\system32\userenv.dll

mofcomp cimwin32.mof
mofcomp cimwin32.mfl
mofcomp rsop.mof
mofcomp rsop.mfl

for /f %%s in ('dir /b /s *.dll') do regsvr32 /s %%s
for /f %%s in ('dir /b *.mof') do mofcomp %%s
for /f %%s in ('dir /b *.mfl') do mofcomp %%s

net start winmgmt
net start VMAuthdService
net start ccmexec

echo done >>c:\temp\done.txt

Then kick it all off with
psexec \\COMPNAME -s c:\winnt\system32\cscript.exe //B c:\temp\runrepair.vbs

Update: the wmirebuild.bat script I found here: How Do I Rebuild A Corrupt WMI Repository?

The next post in this series is, “Grumble grumble – revisiting the WMI fix”.

Bookmark and Share