If you have problems with WMI on a SCCM server you have will have loads of strange things happening.

Wrote a small VBScript to check WMI… here it is:

Set oLocator = CreateObject("WbemScripting.SWbemLocator")

' --- Checking local WMI
WScript.Echo " Connect: root\CIMV2"
Set oWMIService = oLocator.ConnectServer(".", "root\CIMV2", "", "")

WScript.Echo "   Query: Select UUID from Win32_ComputerSystemProduct"
Set oWmiQuery = oWMIService.ExecQuery("Select UUID from Win32_ComputerSystemProduct")
For Each oUuid In oWmiQuery
        sUuid = oUuid.UUID
        WScript.Echo "Response: " & sUuid
        Exit For
Next
WScript.Echo ""

' --- Figure out site code
WScript.Echo " Connect: root\sms"
Set oWMIService = oLocator.ConnectServer(".", "root\sms", "", "")

WScript.Echo "   Query: SELECT SiteCode FROM SMS_ProviderLocation WHERE ProviderForLocalSite=true"
Set oWmiQuery = oWMIService.ExecQuery("SELECT SiteCode FROM SMS_ProviderLocation WHERE ProviderForLocalSite=true")
For each currentSite in oWmiQuery
        sSccmSiteCode = currentSite.SiteCode
        WScript.Echo "Response: " & sSccmSiteCode
        Exit For
Next
WScript.Echo ""

' --- Connect to site
WScript.Echo " Connect: root\sms\site_" & sSccmSiteCode
Set oWMIService = oLocator.ConnectServer(".", "root\sms\site_" & sSccmSiteCode, "", "")

WScript.Echo "   Query: Select Name, ResourceID FROM SMS_R_System WHERE SmbiosGuid = '" & sUuid & "'"
Set oWmiQuery = oWMIService.ExecQuery("Select ResourceID FROM SMS_R_System WHERE SmbiosGuid = '" & sUuid & "'")
For each myMachine in oWmiQuery
        WScript.Echo "Response: " & myMachine.ResourceID
        Exit For
Next

Or download here: wmiTester.vbs

In a post yesterday there was a script to ping some node, the script uses WMI to ping.
Did some testing, and… Why did I write a script when you can use the built in WMI-support to do the same thing?

Why (not) a script?
OK, there is one thing that (afaik) you can’t do with WMI-queries… JOIN.
I would like to do some sort of query that puts out CSName from Win32_OperatingSystem along with StatusCode and ResponseTime from Win32_PingStatus, but… I can’t figure out how.

Ok?
Since you have the performance mapper to point out Object, Counter and so on you can’t make a simple WMI-query that allows you to get the name of the agent. And if you can’t get that to work you will get a mix of multiple agents performance-data on one counter…
The script returns serverToPingFrom, thats what I’m missing.

The solution
When I first looked at it… I only looked at the WMI-query and didn’t think about what SCOM and the performance mapper can do.
The solution is to name the Counter with use of some data that SCOM already know.

Yada yada yada… on to the script!
Go to OM-Console -> Authoring -> Management Pack Objects -> Rules -> New… -> Collection Rules \ Performance based \ WMI performance
A few next-clicks and then paste the following:

WMI Namespace
root\cimv2

Query

Perfomance mapper
Object = WMIPingRoundtrip
Counter = $Target/Property[Type="System!System.Entity"]/DisplayName$
Instance = $Data/Property[@Name='Address']$
Value = $Data/Property[@Name='ResponseTime']$

En kolega hade problem med ett gäng servrar som sprutade ut WMI-felmeddelanden… han hittade ett inlägg som Ivan Brugiolo skrev i newsgroup’en microsoft.public.win32.programmer.wmi:

—————8<---------------
From a very old post of mine in this same forum, how to check why WinMmgt became un-usable and how to repair it.

Try to remove, if they are there

Some legacy application from the Win9x era are known to create those key that impair many DCOM functionality on the machine.

check the following registry key HKLM\System\Software\Microsoft\WBEM\CIMOM\AutoRecover MOFs it is supposed to have a list of *.MOF and *.MFL files, and it MUST begin with cimwin32.mof
There are ISP connection kits and .NET Framework setups known to corrupt this key.
Please delete it content if it appears to have few files or if it appears corrupt.

check if in %windir%\system32\wbem there are about 40 MOF files.
There are certain applications known to delete them.
If you don’t have them, please recover them from the CD of WinXP.
The complete list is found in %windir%\IFM\wbemoc.inf

Please check the following:
-1- that you system path has still %windir%\system32\wbem in it.
-2- that there are no wmiutils.dll and wbemcomn.dll in the system path that comes before the one in system32\wbem.

check if the wbemutils.dll registered as a COM component comes from the OS or from Visual Studio and/or other development tools. Make sure the OS Supplied one is used.

enable versbose logging

find the PID of the svchost.exe process running WinMgmt

crosss check the pid

it must be the same as above, if not, trust tlist.exe more than the registry for the steps below.

you can get “tlist .exe” and “kill.exe” (needed later) from http://www.microsoft.com/ddk/debugging/installx86.asp

after this, please start %windir%\system32\wbem\wbemtest.exe, and connect to the root\cimv2 namespace.

If something goes wrong, please read the logs under %windir%\system32\wbem\Logs, just to see if there is something obviousely wrong there.

After all of this is done, there might be misconfiguration problems that have changed access permission to registry key and files for the NetworkService account.
The NetworkService account is the one running one of the Provider Host.
To test if this can be the problem, you ca add NetworkService to the administrators group

Please remember to remove it as soon as the misconfiguration problem have been identified
—————8<—————