Share via

Tracking Messages

  • Article

Applies To: Windows Server 2008

Tracking messages and routes

You can track the passage of messages from a source computer to a target queue by sending test messages. You can also track the route taken in your network by test messages or all messages sent from the source computer to test queues on remote computers by enabling the message route tracking feature. Neither of these features is enabled by default following Message Queuing installation. For instructions on enabling these features, see Enable Route Tracking and Test Messages.

Sending a test message

A test message is a message that is generated by the Message Queuing service on a specified source computer and sent to a target queue on a specified destination computer. The source computer can be any independent client or Message Queuing server, and the specified destination computer hosting the target queue can be any other independent client or Message Queuing server within the same forest. The target queue must be a test queue; that is, a nontransactional public queue with a queue type ID set equal to {55EE8F33-CCE9-11CF-B108-0020AFD61CE9}.

Test messages are sent to verify that messages can be sent from a given source computer and delivered to public queues on a given destination computer and, if message route tracking is enable, to track the route taken by messages sent from the source computer to public queues on the destination computer.

You can either create a new test queue or transform an existing public queue into a test queue. Most existing public queues can be made to function as a test queue by changing the type ID to that of a test queue. However, it is useless to change the type ID of a transactional queue or a queue requiring message authentication to convert it into a test queue, because test messages, which are nontransactional and are not authenticated, will not be delivered to a transactional queue or to a queue requiring message authentication (unless the queue is located on the source computer).

Sending test messages is not enabled by default following Message Queuing installation, and must be enabled before you can send a test message. For instructions, see Enable Route Tracking and Test Messages. For information about how to send a test message, see Send Test Messages.

Report messages, which track the routes of messages through your network, are always sent to the report queue specified by the source computer for test messages if message tracking is enabled on the source computer.

Message route tracking

You can use the message route tracking feature to track the route that messages take through your network. When all the conditions for route tracking are satisfied, a report message is sent to the report queue for the source computer when the message leaves its source computer, when it arrives at its destination computer, and whenever the message arrives at or leaves a Message Queuing server with routing enabled.

After message route tracking is enabled, there are two basic requirements for its use. First, you specify a report queue for the source computer. Second, the route tracking flag (property) in the message must be set programmatically by the sending application. In addition, only messages sent to a remote computer are tracked, and messages sent over HTTP/HTTPS transport as well as messages sent to multiple destinations using IP multicast, distribution lists, or multiple-element format names cannot be tracked in the current version of Message Queuing.

For information about message route tracking, see Track Message Routing. For information about setting properties programmatically, refer to the Message Queuing Software Development Kit (SDK).

Only one queue can be specified in the header of a message as the report queue for that message. If a route-tracked message with a report queue specified in its header subsequently passes through a Message Queuing server with routing enabled that also has message route tracking enabled, Message Queuing sends a conflict report message to the report queue for that server when the message leaves it.

For example, consider three computers, called A, B, and C, where message route tracking is enabled for computer A. In this example, the Message Queuing application on computer A sends a message to computer C through out-routing server B. If the report queue for computer A is called QA, a report message is sent to QA when the following events occur:

  • The message leaves computer A.

  • The message arrives at out-routing server B.

  • The message leaves out-routing server B.

  • The message arrives at computer C.

If out-routing server B is also configured with message route tracking enabled, with report messages being sent to QB, this queue receives a conflict report message when the message leaves out-routing server B since message route tracking is enabled for computer A. The original source queue QA, however, continues to receive the regular tracking messages.

In a second example, computer A does not have message route tracking enabled, but route tracking is enabled on computers B and C. In this case, the message starts reporting its movements when it leaves out-routing server B. A total of two report messages are sent to QB (when the message leaves computer B and when the message arrives at computer C), but no conflict report messages are sent.

In a third example, neither computer A nor computer B has message route tracking enabled, but route tracking is enabled on computer C. In this case, no report messages are sent before the message reaches the destination computer, but one report message is sent to QC when the message arrives at its destination. No conflict report messages are sent.

Report messages consist of a label and a body. The label has the following format:

gggg:dddd:hh sent from <computer> to <address> at <time>
gggg:dddd:hh received by <computer> to <address> at <time>

where gggg is the first four hexadecimal digits of the globally unique identifier (GUID) of the source queue, dddd is the internal message identifier, and hh is the hop count.

The internal message identifier is the message sequence number, which is part of the entire message identifier. The message identifier is not used in its entirety because it is too big to be easily read. It is a 16-byte source GUID and a 4-byte sequence number.

When conflict report messages are sent, the labels contain the string "Report Message Conflict."

The body of a regular report message contains the ID of the message, the target queue, the destination of the next hop (if any), and the hop count in an XML format. For example, the body of the report message sent to QA when the message leaves the out-routing server in the first example will have the following form:

<MESSAGE ID>message_ID</MESSAGE ID>
<TARGET QUEUE>format_name_of_target_queue_on_computer_C</TARGET QUEUE>
<NEXT HOP>IP_address_of_computer_C</NEXT HOP>
<HOP COUNT>1</HOP COUNT>

The body of a conflict report message contains a line that specifies the original source queue. For example, the body of the "Report Message Conflict" message sent to QB when the report message just described is sent to QA in the first example will have the following form:

<ORIGINAL QUEUE>format_name_of_QA</ORIGINAL QUEUE>
<MESSAGE ID>message_ID</MESSAGE ID>
<TARGET QUEUE>format_name_of_target_queue_on_computer_C</TARGET QUEUE>
<NEXT HOP>IP_address_of_computer_C</NEXT HOP>