mom: monitoring exc script processes

i recently deployed an exc connector (excellent company, by the way, and very pleasant to work with) to help with trap forwarding with the intent of doing two-resolution state at some point in the future. one of the problems i noticed with the connector was that the script processes running on the exc connector terminated without any warning that i could detect (and subsequently alert on). my goal in this case was to get a little more familiar with wmi notification queries. after some fiddling around, i finally got it to work. alright, so how to do this? here goes:
  1. create a wmi event provider.
    • name: exc_script_processes (i named mine this because i'm just clever like that. name yours whatever you want.)
    • namespace: root\cimv2
    • query: select * from __instancedeletionevent within 89 where targetinstance isa 'win32_process' and targetinstance.commandline like '%cscript%mom%'
    • property list:
  2. create an event rule.
    • provider name: exc_script_processes (or the equally clever name you came up with)
    • criteria:
    • schedule: always process data
    • alert: use a helpful description since wmi events are not pulled raw and do not provide much in the way of useful data.
now any time one of the script processes (mom receiver or mom sender) stops running, you'll be notified. the portion targetinstance.commandline like '%cscript%mom%' looks for any processes that have an execution command line that matches the text and wildcards. in this case, the command line looks something like this:
c:\windows\system32\cscript.exe //job:momreceiver "c:\program files\ ..."
since the wmi event is a notification query, it should run with a schedule of 'always process data'. anyway, looking at the rest of the query...
select * from __instancedeletionevent within 89 where targetinstance isa 'win32_process' and targetinstance.commandline like '%cscript%mom%'
i broke out the query into its elements. you're probably used to interpreting wmi queries by now. for example, select * from win32_process would list all the processes that are running on a machine. in this case, however, we're querying for __instancedeletionevent which signifies when instances are ... yes ... deleted. since we're looking to find when the script processes bomb out, those instances ending, would be captured. within 89 is simply a polling interval. you have to use the within clause when a class does not have a corresponding event provider. in the "event" that it doesn't, you'll receive this error:
'within' clause must be used in this query due to lack of event providers
the where clause is stipulating a condition. targetinstance is an object created as a response to an event (the event being a deletion). with isa we're specifying what class targetinstance belongs to, that being win32_process. the last part targetinstance.commandline indicates what to look for on that command line property to consider it a match. check out this article for more information. it was extremely useful...

Comments