A question came up recently about error codes from WMI that you see in BigFix when using custom relevance to access the WMI… I put together a few notes here to assist:
These codes come from the WMI and BigFix doesn’t control them (we just pass them along).
80041010 – “Specified class is not valid” – Which means you are looking up a WMI class that doesn’t exist or is not implemented on your system.
q: selects “* from fake_class” of wmi
E: The expression could not be evaluated: Windows Error: unknown error 0x80041010
80041017 – “Query was not syntactically valid.” – This message will come up if you make a syntax error in your wmi query OR if you try to look up an object/attribute that doesn’t exist:
q: selects “fake from Win32_OperatingSystem” of wmi
E: The expression could not be evaluated: Windows Error: unknown error 0x80041017
80041002 – “Object cannot be found.” – Similar to the issue above, if you are using the “select object” syntax of the WMI queries and you look up an object that doesn’t exist, you will get this error.
q: property “blah” of select objects “* from Win32_OperatingSystem” of wmi
E: The expression could not be evaluated: Windows Error: unknown error 0x80041002
I don’t know if this applies to the topic, but what about WMI being broken?
I have been using the relevance -
not exists WMI | True
This statement works in the fixlet debugger, but machines that should be relevant are not for a WMI repair fixlet. This statement used to work, but doesn’t seem to be working now.
My bad… there is nothing wrong with the statement
not exist WMI | True
. The problem is that I added the new property “Device Type” for my site criteria. Since “Device Type” uses WMI, machines with broken WMI never evaluate correctly and therefore never get into the site where the WMI repair fixlet is.
I have moved the WMI repair fixlet to the Master Action site.