MSMQ: Frequently Asked Questions

Microsoft Message Queuing (MSMQ) is a component of the Windows operating system that allows cooperating applications to send and receive messages to each other, even if the intended recipient application is not running or the computer on which the sender or recipient application is running is disconnected from the network. Messages are stored and forwarded by MSMQ until they reach the destination queue. Later, when a recipient application runs, it can retrieve the messages from the queue. MSMQ decouples sender and recipient applications so they do not need to run at the same time. Message Queuing provides built-in enhanced security, transaction support, and other features.

MSMQ is useful when custom applications need to communicate reliably across potentially unreliable or occasionally connected networks. MSMQ is also useful as a persistent storage mechanism for a list of items. For example, a server-based application could use MSMQ to store queued orders that would be submitted as a batch to an order-processing system at the end of the day. MSMQ is also the underpinning infrastructure for reliable messaging in Windows Communication Foundation, first available in Windows Vista, the next version of the client operating system.

MSMQ is available as a component of Windows 2000, Windows XP (excluding Home Edition), Windows Server 2003, Windows Vista (all editions), and will be included in future server versions of Windows.

To install Message Queuing on a computer running Windows 2000, Windows XP, or Windows Server 2003, administrators use the Add/Remove Windows Components feature of Add or Remove Programs in Control Panel. No other software is required.

Because Message Queuing is a component of Windows, its use is covered by the Windows license. If you have a valid license to use Windows, then you can use MSMQ. There is no additional fee, above the cost of Windows itself, to use MSMQ.

No. The Windows 2000 and Windows Server 2003 built-in schemas include all the definitions that are required by Message Queuing. The Windows Server 2003 Active Directory schema includes new objects and attributes for Message Queuing. If you install Message Queuing 3.0 (the version included in Windows XP and Windows Server 2003) in an Active Directory environment that deploys only Windows 2000 domain controllers, Message Queuing 3.0 will not be able to use these new objects and attributes. For example, you will not be able to define a multicast address for a public queue in such an environment.

Message Queuing is accessible by way of several programming interfaces. The .NET Framework includes a System.Messaging class library that allows access to MSMQ, and this is available to any one of 20 .NET languages, including VB.NET, C#, J#, and many others. In addition, there is a C/C++ library available, as well as a COM library for COM-enabled environments.

The minimum overhead for a message that is sent over the native Message Queuing protocol is approximately 150 bytes, which includes a signature (unrelated to message authentication), source and target computer IDs, a target queue name, and message properties. The overhead increases if you use transactions, multiple queue format names, or security features (such as authentication and encryption). For example, for authentication and encryption, the following overhead applies:

The overhead for messages sent over the HTTP or multicast protocols is higher because of SOAP formatting. It adds at least 1 KB of headers, for a message sent without authentication.

Message Queuing stores messages in multiple 4 megabyte (MB) files in the MSMQ\Storage folder. In MSMQ 3.0, you can specify the location of this folder from within the MSMQ plug-in to the Microsoft Management Console (MMC). Messages destined for remote computers are kept in the same files that are used to store local messages. The Message Queuing service dynamically manages the storage for local as well as outgoing messages, while transmission to other computers is pending.

Message Queuing can be accessed and used by any Windows application, including Windows Forms applications that present graphical user interfaces (GUIs), smart client applications built on top of the Microsoft Office System, server-side applications running within ASP.NET, Windows Services, and others.

Yes. The scope of a Message Queuing transaction is the local computer. This means when an application sends a message within the scope of a transaction, and then performs other transactional work—for example updating a transaction-aware database—and then commits the transaction, Message Queuing guarantees that it has the necessary resources on a local computer to save the message and send it to the destination. MSMQ does not guarantee that the message will eventually reach the destination queue. For example, the message might expire before it reaches the destination computer, or the message might be rejected by the destination computer because of quota. Use the message confirmation mechanism to track message progress.

Message Queuing supports a variety of security-related features. For example, queue operations are protected by Access Control Lists (ACLs). Queue events can be tracked by way of audit messages in the Windows Event log. Messages can be automatically authenticated (signed) or encrypted upon sending, and verified and decrypted upon reception.

MSMQ utilizes Active Directory for security information related to encryption and decryption, or message authentication. MSMQ also uses Active Directory for public queue lookups – in this way the sending or receiving applications do not need to know the machine-name of the computer hosting the destination queue.

Yes. Message Queuing is supported across a load-balanced cluster of machines, for non-transactional messages and private queues. Simply address the message to the IP of the cluster.

Yes. Message Queuing is supported across an MSCS cluster for reliability of message storage.

Natively, MSMQ is accessible by way of APIs provided within Windows. The MSMQ-MQSeries Bridge, part of the Host Integration Server product from Microsoft, allows bidirectional bridging between MSMQ and MQSeries. A sending application can send a message by using MSMQ programming interfaces, and the remote receiving application can receive it using IBM MQSeries programming interfaces. Or, an application can send a message to MQSeries, and the receiving application can receive the message by using MSMQ.