I know this question has come up a few times, but I'm not sure that it's ever been effectively addressed. It's a question of theory, not specifics, but I'll provide a specific example. The question is:
How would you make an Agent Procedure generate an alarm and categorize it as a specific alarm group?
For example, lets say that I create a Monitoring Set Group that is called "Frag", which now shows up on my Alarm Dashboard as a filterable category for alarms. If I had a script that (without all the details) does a defrag analysis and determines file fragmentation percentage, how would I make the script generate an alarm that is categorized under the "Frag" group?
Please let me know your thoughts. This would be extremely useful and Kaseya support was of no assistance.
Unfortunately the only way to do this is a round about way. You need to get the script to write a windows event log that another even log set picks up and then alarms off. It would be nice for scripts to raise alarms but alas they don't.
I've seen that posted as a viable solution, but the problem is that, to my knowledge (please correct me if I am wrong), all event log generated alarms categorize as something generic like "Alert" or "Event" on the dashboard. I'm looking for specific categorization so that our techs can prioritize their remediation efforts. It seems crazy to me that there isn't an Agent Procedure step that is called "Generate Alarm with Category _______".
You are correct that it would be a generic alarm. I think service desk might offer more and that might be why Kaseya has not added or worked on a Agent Procedure called Generate Alarm but i agree it would be a nice thing to have.
True, I could use Service Desk, but I don't necessarily want a ticket. I want an alarm so that a tech can determine whether it's ticket-worthy or not. Apparently this is not possible (per Kaseya and Kaseya Professional Services). I think I might try to tackle it from the custom WMI object/counter side, since I can monitor those using Monitoring Sets and categorize the alarm that way...
@jhardee have a look at this; community.kaseya.com/.../60854.aspx
I know its a lot of work using the method mentioned in the link and yes the guys at Kaseya could make our work loads easier by just adding it for us.
It will be a step you can select in Kaseya 6.3. Stay tuned :)
That is great news Ben :)
Thanks HardKnox! I have, in a roundabout way, incorporated your method into one of my techniques. I have Service Desk read for certain parameters, and then I have it kick off an agent procedure that kills notepad.exe on a monitoring computer where notepad.exe is being monitored and subsequently restarted via script to generate an alarm. I do need to study your math/findings a bit, because my solution is definitely not bulletproof, but it's a workaround.
@Ben - Wonderful news! Any idea on the target GA for 6.3?
@jhardee the math is easy as the agent procedure does a check-in every 30 seconds you want your fake process to run for more than 30 seconds say 1min. The key to kicking off the fake process is to use the Execute File with the "Wait for the program to complete before continuing" with the checkbox unchecked.
If you use the Execute Shell Command or the Execute File with the "Wait for the program to complete before continuing" checked checkbox the Agent Procedure will block the Process Monitoring from being triggered.
so to dig this up, how do we do this in 6.3? Can't seem to find it :(
Well one workaround is this; when you need an alarm generated in a script, set it up like this:
* Execute Shell Command step -
echo NO >> #vAgentConfiguration.agentTempDir#\alarmgen.txt
* Get File -
#vAgentConfiguration.agentTempDir#\alarmgen.txt as alarmgen.txt, and Overwrite existing file without alarm
echo YES >> #vAgentConfiguration.agentTempDir#\alarmgen.txt
* Get File -
#vAgentConfiguration.agentTempDir#\alarmgen.txt as alarmgen.txt and Overwrite existing file and send alert if changed
* Delete File -
Yes it's a pain, but it's robust, repeatable, and consistent, with no "pre-setup" (as long as you're not using alarmgen.txt for anything else, since it gets created and deleted). Then to "direct" the alarm you use the Get Files alert function, which can be individually set for each machine. And actually, if you change the name of the .txt file in each step where it's referenced you could use it as a notation to help remember what the alarm is for, since the name of the file is the first thing in the subject line (if you're sending an email) and as the summary of the alarm when generated (e.g. "alarmgen.txt has changed on server.group.org ") So the only thing this method can't do is set the type, but it can be used for a pretty-helpful custom alarm, and is tested in 6.2 (no reason it wouldn't work in 6.3 for that matter)