Overview of Message Queuing

  • Article

Message Queuing (also known as MSMQ) is a messaging infrastructure and a development tool for creating distributed messaging applications for Microsoft Windows. Applications developed for Message Queuing send messages to queues, which are temporary storage locations, from which messages can proceed to their final destination as conditions permit. Such applications can communicate across heterogeneous networks and can send messages between computers that might be temporarily unable to connect to one another. Message Queuing provides the following benefits:

  • Guaranteed message delivery

  • Efficient routing

  • Improved security

  • Support for sending messages within transactions

  • Priority-based messaging

Software products with these features are often referred to in the industry as:

  • Message-queuing software

  • Store-and-forward software

  • Message-oriented middleware

With Message Queuing, end users can communicate across networks and computers that might be offline, regardless of the current state of the network and computers. System administrators can use Message Queuing to efficiently manage large, complex networks of computers and message queues.

What's New in Message Queuing 4.0?

The following new features are introduced in Message Queuing 4.0, released with this version of Windows:

  • Subqueues. Subqueues are implicitly created local queues that are logical partitions of a physical queue. Applications can use subqueues to group messages. The subqueues feature enables you to logically group messages in a queue without creating another physical queue.

  • Move messages. You can move messages in one of three ways:

    • Using the Move Message dialog box

    • Performing a cut-and-paste operation

    • Performing a drag-and-drop operation

    You can move messages between subqueues of the same main queue, or from a main queue to its subqueue. You cannot move messages from a main queue to a subqueue of a different main queue or between two main queues or between two subqueues of different main queues.

    The message is moved as is, from the source queue to the target queue. The properties of the message remain unchanged, except for the current move count.

  • Per-application dead-letter queues. In Message Queuing 3.0, there is a system transactional dead-letter queue. If one or more applications are sending messages and requesting dead-letter handling, they each use the same system transactional queue. This can result in a bottleneck. It is also hard to determine which dead messages belong to which application because all applications share the same dead-letter queues.

    Message Queuing 4.0, however, introduces per-application dead-letter queues, so that each application can use its own dead-letter queue. An application can request its own dead-letter queue by using the PROPID_M_DEADLETTER_QUEUE property as part of the message. Instead of being sent to the system transactional dead-letter queue, the message is sent to the queue that is specified in the PROPID_M_DEADLETTER_QUEUE property.

    The PROPID_M_DEADLETTER_QUEUE can be set to any legal path of a transactional queue. The transactional queue must be local to the queue manager that will move the negative acknowledgment (NACK) message to the queue. A legal path is defined in Queue Path Names (https://go.microsoft.com/fwlink/?LinkId=69583).

  • Transactional remote receive. Transactional remote receive is a transactional receive of a message from a remote queue. There are scenarios where a transactional remote receive is necessary. For example, when work orders from a remote central queue need to be processed across a farm of application servers, a transactional remote receive will enable the message processing to be load-balanced across the server farm.

Message Queuing 4.0 includes additional new features, such as move count and abort count, which enable poison message–handling scenarios. These are described in the Message Queuing Software Development Kit (SDK) documentation. For more information, see What's New in Message Queuing 4.0 (https://go.microsoft.com/fwlink/?LinkId=68744).

More Secure Encryption and Authentication Algorithms

Message Queuing 4.0 supports more secure encryption and authentication algorithms. The following sections explain these improvements in more detail.

Encryption

The default encryption algorithm in Message Queuing 4.0 is RC4. This differs from the default encryption algorithm in Message Queuing 3.0, which has RC2 as a default encryption algorithm.

Message Queuing 4.0 also adds support for Advanced Encryption Standard (AES), which is a more secure encryption algorithm than RC4.

To summarize, the available encryption algorithms in Message Queuing 4.0 are:

  • CALG_RC2

  • CALG_RC4 (default)

  • AES

MSMQ can also perform negotiation between the Queue Managers to select the best possible encryption algorithm. When MSMQ is operating in domain mode, encryption is supported. In this mode, before a Queue Manager sends a message to a remote queue, it obtains information about the remote Queue Manager from Active Directory Domain Services (AD DS), such as its public key. At the same time, the Queue Manager can obtain other information about the capabilities of the remote computer and can determine an appropriate encryption algorithm to use.

Authentication

Message Queuing 4.0 supports Secure Hash Algorithm version 1.0 (SHA1) and all advanced hash algorithms that are supported in this version of Windows. The default is SHA1. Support for algorithms such as Message Digest version 2 (MD2), MD4, MD5, and Message Authentication Code (MAC) have been disabled by default in Message Queuing 4.0 because these algorithms are considered less secure.

However, weaker algorithms can be enabled to support any Message Queuing applications that require them by adding the WeakHashAlgorithms registry key. If this registry key is not present, as is the case by default, then all weaker algorithms are disabled. If the registry key is present, then all weaker algorithms are enabled. To enable only certain weak algorithms, you must add the registry key and specify the values of those weaker algorithms that you want to continue to disable.

Warning

Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

To continue to disable certain weaker authentication algorithms

  1. Click Start, and in Start Search, type regedit, and then press ENTER.

  2. Navigate to the following registry subkey:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\
    Security

  3. On the Edit menu, point to New, and then click Key.

  4. Type WeakHashAlgorithms as the name of the new registry key, and then press ENTER.

  5. Right-click WeakHashAlgorithms, point to New, click DWORD (32-bit) Value, and then type any name for the new value.

  6. Double-click the new DWORD (32-bit) Value, click Decimal, and then in Value data:, type the appropriate value for the algorithm you want to disable:

    • 32769 for MD2

    • 32770 for MD4

    • 32771 for MD5

    • 32773 for MAC

  7. Click OK to close the Edit DWORD (32-bit) Value dialog box.

  8. Create new DWORD (32-bit) values for additional algorithms that you want to also disable.

  9. On the File menu, click Exit to close Registry Editor.

You can re-edit the registry to remove the respective value for an algorithm to support it.

If the Message Queuing application is run on this version of Windows and chooses a weaker authentication algorithm, Message Queuing will override the choice and use SHA1 instead, by default.