Some more Command Notification Tricks and Tips
Here are a couple a tidbits on command notification with Operations Manager 2007 I’ve seen people asking about recently.
1) I’m getting Alerts “Script or Executable was Dropped” when command notifications execute. How do I prevent it?
What you’ll typically see in the Alert description is the following:
“The process could not be created because the maximum number of asynchronous responses (5) has been reached, and it will be dropped. Command executed: ………”
What is happening here is that notification command execution in response to alerts is attempting to fire more than 5 (default) notification command processes asynchronously. By default the number of command processes executed defaults to 5 to protect the RMS from alert storms potentially overwelming the system with runaway processes.
The default of 5 async notification processes allowed can be overridden. The following solution comes with a warning “Increasing the default number of concurrent command notification processes could cause RMS performance issues”. For those running somewhat lengthy batch files, scripts, executables via command notification the following may allow such to scale out if your RMS has the horsepower to cope:)
It’s worth noting that it is the RMS that runs notifications. The follow registry modification on the RMS and subsequent stop and restart of the HealthService service will trigger the new maximum responses allowed:
One the RMS use RegEdit to navigate to HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft Operations Manager\3.0\Modules
Under this key create a new subkey called Global
Under the new Global subkey create another subkey called Command Executer
Under the Command Executer subkey create a new DWORD value AsyncProcessLimit
For the value of AsyncProcessLimit you can set a minimum of 0x00000001 (Strongly not recommended) and a maximum of 0x00000064 (100) (again definitely not recommended).
So, if you wanted to increase the number of async command notifications from 5 to 10 the key would look like:
HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft Operations Manager\3.0\Modules\Global\Command Executer\AsyncProcessLimit REG_DWORD:0x0000000a
2) When using some notification properties (e.g. $Data/Context…) with command notification the command process never executes and I get the rather annoying alert “Script or Executable Failed to run”
In the alert description you would see “The process could not be started because some of the data items could not be resolved…”
What you are seeing here is that one or more notification properties used in the notification command channel command line doesn’t actually contain anything. A common example is $Data/Context/DataItem/TicketId$ for example (will contain nothing unless you have a connector which sets it). When a notification property contains nothing the command executer will not execute the command since the process being executed may be expecting something as a parameter.
If you’ve hit this here’s a solution I became aware of recently that will most certainly help.
For command notifications (I’ve personally not tried this in other notification methods) you can provide a default value for the notification parameter if no value exists. For example
$Data[Default=’No Ticket ID’]/Context/DataItem/TicketID$
NOTE: Single quotes surround the default value. This then allows properties containing spaces to be easily supplied as parameters to batch, scripts or executables.
For example, in the Notification Command Channel dialog you could enter:
Full path to file: %COMSPEC%
Command line parameters: /C c:\notificationcmds\execsms.cmd “$Data/Context/DataItem/AlertName$” “$Data[Default=’No Description’]/Context/DataItem/AlertDescription$” “$Data[Default=’No TicketID’]/Context/DataItem/TicketID$”
This would allow the notification command to execute and output the defaults No Description and No TicketID if the Alert Description or TicketID did not contain a value.
More info on Notification properties:
https://blogs.technet.com/cliveeastwood/archive/2007/10/12/a.aspx
Comments
- Anonymous
January 01, 2003
The comment has been removed