Share via


Trigger rules

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Trigger rules

All rules created on the local computer are displayed in the Computer Management snap-in. You can attach multiple rules to a trigger. If you do so, the rules are executed in the order in which they are displayed in the Attached rules list on the second page of the New Trigger dialog box or on the Attached Rules tab of the YourTrigger Properties dialog box. You can change the priority (order of execution) of rules in this list by selecting a rule and clicking the applicable button. The rules displayed in the Rules list are disabled by default. To enable a rule for use with a trigger, you must attach the rule to the applicable trigger. For more information, see View or change properties of triggers and rules for triggers.

A rule is composed of one or more conditions and an action that is executed when the conditions are true. Each condition is applied to every message arriving at the monitored queue, and the result is either true or false. Multiple conditions must all be true for an action to be executed. If no condition is specified, a true value will always be returned. This is useful when you want a trigger to fire unconditionally every time a message arrives at the monitored queue. The conditions applied to a particular rule are listed in the Condition list on the Conditions page of the Properties dialog box for that rule. New rules are composed by selecting a supported initial string in the New condition list box and typing a concluding string in the text box below it. These conditions are summarized in the following table.

Condition Description

Message label contains/does not contain

Tests whether the label of the newly arrived message contains (or does not contain) the string you specified. This string is case-sensitive.

Message body contains/does not contain

This applies only to messages with a string body type (VT_BSTR, VT_LPWSTR). Otherwise, the condition will always be false, and no action is invoked.

Message priority equals/does not equal/is greater than/is less than

Tests whether the priority of the newly arrived message satisfies the mathematical expression you specified.

Application-specific message number (AppSpecific) equals/does not equal/is greater than/is less than

Tests whether an application-specific message number satisfies the mathematical expression you specified.

Message source computer ID (SourceMachineGuid) equals/does not equal

Tests whether the source computer GUID equals (or does not equal) the value you specified.

The actions performed when a condition or set of conditions is true are expressed either in the form of a stand-alone executable file and parameters (arguments), or in the form of a COM component, a method, and parameters. You can specify one or more parameters to be passed per action.

The supported parameters are:

  • Message ID (as variant)

  • Message label (as string)

  • Message body (as variant)

  • Message body (as string)

  • Message priority (as number)

  • Message sending time (as date variant)

  • Message arrival time (as date variant)

  • Message correlation ID (as variant)

  • Message lookup ID (as variant)

  • Queue path name (as string)

  • Queue format name (as string)

  • Response queue format name (as string)

  • Administration queue format name (as string)

  • Application-specific message number (AppSpecific as long)

  • Trigger name (as string)

  • Trigger ID (as string)

  • Message source computer ID (SourceMachineGuid as string)

  • String literal

  • Numeric literal

These parameters are presented in the list box under Parameter on the Invocation Parameters dialog box, which can be accessed by clicking Parameters on the third page of the New Rule dialog box, as well as on the Action page of the Properties dialog box for a particular rule. Note that the Message Queuing Triggers service runs under the Network Service account, and that executable files invoked by triggers are invoked with the same security privileges as those assigned to the Triggers service. If your rule invokes a COM component, make sure that it can be successfully invoked from the security context used by the Triggers service, is properly registered, and has suitable dependencies.

By default, the Message Queuing Triggers service runs under the Network Service account. Services that are running under this account interact with the network using the credentials of the computer account, and this account has the same level of access to resources and objects as members of the Users group accounts. For heightened security, you can change the default Triggers service account to a more secure setting; for example, the Local Service account, which limits access to the local computer. You can also specify a less secure account for the Triggers service; for example, the Local System account, allowing access to the entire domain. Note that the Triggers service running under the Network Service account does not interact with the desktop. If this functionality is required, you can configure the Triggers service to run under the Local System account, and enable interaction with the desktop in Computer Management.

If your trigger invokes an executable file with command-line arguments, these arguments can be included as parameters of the string literal type. However, you must add a separate parameter for each command-line argument.

You can also use parameters to invoke other types of files that can be included as a command-line argument of an .exe file. For example, you can invoke an .msc file by specifying mmc.exe as the executable file and the full path of the .msc file as an invocation parameter of the string literal type.

Triggers and rules are created and modified by mqtrig.dll, but the service is implemented by mqtgsvc.exe. Therefore, information about the state of any new or modified trigger or rule must be passed to the service. This is done by sending a notification message to a specific internal private queue. The service reads each message sent to this queue, updates its internal data accordingly, and then deletes the message.

For more information on how to create rules, see Create and attach rules to triggers.