Its rather unintuitive how to use WMIC to send a Test Indication to HP SIM, here's how to do it.
C:\wmic
/namespace:\\root\hpq Path HP_WinComputerSystem where
Caption="afs00-2.agnet.tamu.edu" CALL SendTestIndication
TestIndicationID=101
First you need to be aware that Methods on a Class can be [Static] or [Non-Static], a static method can be called at the same time as Instantiating (aka 'Creating') a New Instance of a Class. A non-static method can be called only an "Existing" Instance of a Class.
To send indications from a managed server using the HP SIM WMI Providers, they must be installed and running.
The
HPWinComputerSystemProv WBEM/WMI Provider, comes with a Class called
HP_WinComputerSystem which creates a
New Instance on startup and has a [Non-Static] Method called
SendTestIndication.
SendTestIndication takes exactly one [In ] Param
TestIndicationID of Type CIM_UINT32 which maps through VT_I4 to WMI (uint32) -- basically "its a number, not a string" but even if you surround it in quotes when using wmic.exe, it will still treat it as a number and you will not have a type problem.
Ok, works - TestIndicationID=101
Ok, works - TestIndicationID="101"
As a concrete example you can "walk" the CIM using WMIC to Create a brand new "shiney" copy of any Object based on the HP_WinComputerSystem Class definition, and retrieve (all) of its default Properties and Values, as follows:
C:\wmic /namespace:\\root\hpq Path HP_WinComputerSystem GET /all /format:list
And this brand new Object instance has a Method on it, we can "ask" how to use it, as follows:
C:\wmic /namespace:\\root\hpq Path HP_WinComputerSystem CALL SendTestIndication /?
Beware! - This might lead one to believe its as simple as then providing the param TestIndicationID with a value and the Method would be executed. -- That [
will not ] work!
There is a really [ BIG ] difference between a brand new Instance (copy of a Class definition) which you just Created, and a "Pre-Existing Instance" that has been hanging around since the System started up. The original Instance has been kicked, used, abused and had first access rights to everything in the system. As such it has "Experience" and "History" within the system in which it lives, or exists, and is probably the one you actually want to be using, when you perform a Method Call.
To really drive this point home, some Methods will "refuse" to Execute on brand new Instances, because those brand new Instances are "second rate" copies that probably do not have the Information or Control over the things you want the Methods to operate on.
And you should probably be aware that as soon as wmic.exe is finished with this brand new shiney object, its going to be "thrown away" by the operating system, reaped, garbage collected.. desolved.. and its resources recycled.. hasta la vista.. so your wmic "derived" shiney new object will not be hanging around for very long. In this regard [Static] implies for "this instance in time", very temporary, and "not very useful".. so Executing a Method on a [Static] object is just silly. It's like taking a hammer to a glass sculpture.. its very brittle.
Dynamic objects (or [Non-Static]) objects are much more robust, they hang around and get used alot, they've been around the block a time or two and invoking Methods on these types of Objects is much more useful. Of course they need long term caretakers that "sponsor" them in the operating system ecosystem, so they are not taken out and thrown away by the operating systems recycling system. And that's the job of the WMI Providers that provide WBEMServices, when they startup they create these default Instances of the Classes and keep them going.
To a degree declaring a Method as [Non-Static] saves you time, and helps eliminate confusion, did you remember to refer to the Object you really wanted to execute that Method on? Or did you create a new one and immediately turn around and invoke a Method that is not going to return anything useful?
For example:
This ERROR message can be misleading, because it refers to the CALL verb and not the Method.
This Method is [Non-Static] meaning it cannot be CALL'ed without referring to an 'Existing' Instance.
You 'cannot' call the Method by 'Creating' a new instance at the time of the CALL (that would require a [Static] Method),
SendTestIndication is
not a [Static] Method. That is what the ERROR is saying, the Class instance provided, that is, the
brand new one...
just created.. has a Method called
SendTestIndication but since it is [Non-Static] it cannot be called on a recently created Instance.
In a way, you made a choice by [not] specifically telling the CALL (which) Instance of the Class you want to invoke this Method on.. by providing no specific way of telling (which) Instance.. wmic "assumed" you wanted to "Create" a whole brand new one in memory, and proceeded to do so for you.. then it <pointed> the CALL at this brand new copy and said { This "one".. use This "Instance" that I just created.. and invoke the Method attached to this "New" copy. }
Its a little confusing, because the Method is attached to the Object just created, but its a matter of "where else" would you logically declare methods that are going to work on this Object type in source code? Group them together.. and we'll make a note the CALL can read later that says [caution! do not allow this Method to be called if the Object is brand new.. aka "static"] If the object hangs around it will be declared "non-static" and CALL will allow that.
The CALL'er is looking at the Parameters proposed to feed the Method and 'saying' { You know what? Nope.. that's wrong, its not right and I'm not going to allow this. Your providing "Invalid method Parameters" and I'm shutting this operation down.. end of story. }
The Class Instance is "new" not "existing" and that is an {'Invalid method Parameter'}
[Instead] a reference must be made to the {one} Instance of HP_WinComputerSystem that was created when the HP WMI Provider service was started on the system. That means a CALL must be made referencing the "already Existing" instance of the HP_WinComputerSystem Class.
In WMIC a reference can be acquired by "prefixing" the "CALL" with a specific "query" such as the following:
C:\wmic /namespace:\\root\hpq Path HP_WinComputerSystem where Caption="afs00-2.agnet.tamu.edu" GET /all /format:list
The original "walk" of the CIM properties for this Class "Instance" revealed a property named "Caption" since there is only "one" Instance for this Class possible per machine, the query will return exactly one reference to an "Existing" Instance which will then be used as the starting point for invoking the Method.
If you run the last wmic command and look closely at the Properties of the Object it returns, you will see as "Christmas trees" go.. this Object is much more detailed and decorated with more Values than a shiney brand new copy that hasn't really been around very long. Its probably been hanging around in memory for quite a while and other Classes and services have strolled on by decorating it and updating with useful state information.
It is possible for some Classes to manifest themselves as "more than one" Instance, in which case either the query must narrow the possibilities down to a single instance, or a command line FOR /F loop must be used to wrap the entire call to perform the same Method for each Instance found.
In that case the loop statement effectively "filters" the results and presents only "One" object to the Method invoker at a time, it queues them up and makes everyone stand in line.. so only one Method is invoked by the magic CALL'er wand at a time.
Enabled and disabled, multiple network interfaces on a server come to mind..
When the original "walk" was listed it also provided the current value for the Caption property and it is used as the selector for the instance in the following example. The "name" property is also commonly used.
In reality probably any Instance property could have been used, this one was picked at random.
The results will now return a ReturnValue, but in 'this case' is still not sufficient to achieve a successful Indication event on the HP SIM server.
In this case the Method is invoked, and returns an OUT param called "ReturnValue = 4"
This is actually an Error coming from the Method, and is explained by looking at the Description for the Method
C:\wmic /namespace:\\root\hpq Path HP_WinComputerSystem where Caption="afs00-2.agnet.tamu.edu" CALL SendTestIndication /?:Full
In this case the Method is 'saying' the ReturnValue = 4 means an inappropriate value (not valid) is being submitted by the param 'TestIndicationID=1'
A look at the Description for the MOF of the param 'TestIndicationID' using WBEMTest reveals appropriate values for the TestIndicationID:
Internal identifier of the test event to generate
101 - Informational Test Event
102 - Warning Test Event
103 - Critical Test Event
And the final result is:
C:\wmic
/namespace:\\root\hpq Path HP_WinComputerSystem where
Caption="afs00-2.agnet.tamu.edu" CALL SendTestIndication
TestIndicationID=101
note: while this will work from a standard console prompt, it will return a syntax error from a powershell prompt. "Unexpected switch at this level." The pre-processing of "quotes" within powershell is especially complex when calling legacy command line tools which also depend upon and pre-process the quotes, which I suspect "provokes" a technically accurate "if inconvenient" syntax error at "one of" the pre-processing times, either by powershell or the command line invoker of the legacy command line tool. I suspect a mixture of pre-processor specific "escape" characters and redundant or re-diracted specific single and double quotes would result in the same result without an actual syntax change to the original statement, simply by accounting for the extra powershell pre-processor oversight.
The TestIndicationID values will correspond to the EventID numbers {1,2,3} available to choose from in the SMH and standalone applications GUI
101 - Informational Test Event
102 - Warning Test Event
103 - Critical Test Event
When the Method is called there will be a discernable [ delay ] before returning the [ ReturnValue ] output, the Indications will immediately show up in the HP SIM Management Console as a generic
[ Event Type ] "Test Event"
Orange (!) Major Inverted Triangle for TestIndicationID=103
Yellow (!) Minor Triangle for TestIndicationID=102
White (I) Info Circle for TestIndicationID=101
It might belong in a different Blog entry but quickly.
You can do the same thing with WBEMTest.exe
1. open a command prompt
2. type wbemtest.exe
3. press Connect
4. change the Namespace to [ root\hpq ] this is where all HP Providers put their Classes, Instances
5. press Connect
6. from this new Viewpoint, conduct a Search for "Instances" of Class "HP_WinComputerSystem"
7. press the [Enum Instances] button and type in a Search pattern for the Instances of Class
8. there will be a long "pause" while it conducts the search with very little feedback
9. it will return a list of "all" Instances that originated by instantiating a copy of the SuperClass
A. Its important to notice the result box cannot be resized, but all of the line is important when referring to this very specific "Instance", which you will need to "launch, fire, or properly execute" a [Non-Static] Method - so manually copy it down or make a note of it; the cut and paste, clipboard does not work in this tool
B. Close the Query Result and press [ Execute Method..] button
C. type in the "very specific" Instance line you found before
D. use the drop down to select the [Non-Static] Method of this "specific" Instance of HP_WinComputerSysetem - (method) SendTestIndication
E. press the [Edit In Parameters...] button (notice: "In" corresponds to the [In] parameters )
F. in the "center" Properties box, scroll down select TestIndicationID and [Edit Property]
G. punch the "Not NULL" Value radio button and type a value of 101 then press [Save Property]
H. then press [Save Object]
I. then press [Execute!]
J. after a very long pause the Result box will appear, and the HP SIM console page will indicate it received an Event from this end point
.bmp)
