Message storm occurs after deploying "Forward message changes to service desk" policy

  • KM470757
  • 03-Jul-2008
  • 03-Jul-2008


After deploying the "Forward Messages Changes to Service Desk" policy to the Operations Manager for Windows (OMW) management server a storm of unusual messages arrives in the message browser.

The messages in the storm look like the following example:

Could not forward message change to trouble-ticket update program. See annotations for details.
1/8/08 3:28 PM
Original message:
__CLASS (CIM_STRING) ==> OV_Message_NumberOfAnnotationsChangeEvent
__DERIVATION (CIM_ARRAY|CIM_STRING) ==> <Array> __DERIVATION[1] (CIM_STRING) ==> OV_Message_ChangeEvent __DERIVATION[2] (CIM_STRING) ==> __ExtrinsicEvent __DERIVATION[3] (CIM_STRING) ==> __Event __DERIVATION[4] (CIM_STRING) ==> __IndicationRelated __DERIVATION[5] (CIM_STRING) ==> __SystemClass __DYNASTY (CIM_STRING) ==> __SystemClass __GENUS (CIM_SINT32) ==> 2 (0x2) __NAMESPACE (CIM_STRING) ==> <null> __PATH (CIM_STRING) ==> <null> __PROPERTY_COUNT (CIM_SINT32) ==> 5 (0x5) __RELPATH (CIM_STRING) ==> OV_Message_NumberOfAnnotationsChangeEvent.MessageId= bd08af30-bddc-71dc-0f5f-0a01f9ba0000
__SERVER (CIM_STRING) ==> <null>
__SUPERCLASS (CIM_STRING) ==> OV_Message_ChangeEvent MessageId (CIM_STRING) ==> bd08af30-bddc-71dc-0f5f-0a01f9ba0000
NewNumber (CIM_SINT32) ==> 1 (0x1)
OldNumber (CIM_SINT32) ==> 0 (0x0)
Detected by application: Forwarder
Object in question:


This type of problem may occur when creating and deploying a WMI policy to monitor messages arriving on the management server and to run automatic actions for messages matching conditions defined in the policy. This is a technique often used to enable matching messages to be forwarded to an external application (such as Service Desk, an email program, a page application, etc.

When defining such policies care must be taken to ensure a message 'loop' cannot result. It is a rule that every policy MUST send a message when an automatic action succeeds or fails (or both). Typically, in WMI policies designed to forward mesages to external applications, a message is only sent if the automatic action fails. If the automatic action for one message fails, then a 'failure' message will be generated by the WMI policy and sent to the management server. This 'failure' message will then arrive on the management server and be treated the same as any other message -- it will be examined by the WMI forwarding policy. Therefore, care must be taken to ensure that these 'failure' message do NOT match the conditions of the forwaring policy. If they did match, the forwarding policy would run an automatic action to forward the 'failure' mesage to the external application and if this automatic action also failed another 'failure' message would be sent, and so on, until the problem with the automatic action was corrected. This would cause a 'loop' and a 'storm' of messages.




Generally, it is not difficult to ensure that the 'failure' message do not match a condition in the forwarding policy. The HP-supplied policies such as "FwdMsgAsEmail", "Forward To VP", and "Forward Messages to Service Desk" all contain this logic and can be used as an example for configuring other policies.

The "Forward Message Changes to Service Desk" policy, however, does not contain such logic. It is currently not possible to configure a policy which detects changes to
existing messages to be safe from loops. This is because the event class used for such as a policy is OV_Message_ChangeEvent which contains no fields that
are suitable as 'flags' to be set in the outgoing message.

This is under investigation in QXCR1000774468.