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
* Execute Shell Command step -
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 -
#vAgentConfiguration.agentTempDir#\alarmgen.txt
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)