Windows Azure: Guidelines for Running MSMQ in a Virtual Machine

Published: October 2013
Microsoft Corporation

Copyright information

This document is provided "as-is". Information and views expressed in this document, including URL and other Internet website references, may change without notice.

Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

©2013 Microsoft Corporation. All rights reserved.

Message Queuing (MSMQ) supports operation in a Windows Azure Virtual Machine.When using MSMQ in a VM be aware of the following limitations:

  1. Volatile messages are lost whenthe VM is migrated. While volatile messages are always at some risk on any machine, they might be lost more often when MSMQ runs on a VM.
  2. Durable messages experience lower performance due to the nature of the underlying storage. It is advisable to run a performance test to see if the available message throughput is sufficient.
  3. Sending messages viaHTTP/HTTPS over a public IP address is not supported.

Configuring MSMQ to run on an Azure VM

In order to get two or more instances of MSMQ to communicate, the machines need to have TCP/IP connectivity. The simplest way to achieve this is for the machines to be on the same subnet of the same virtual network.More complex topologies can be created with multiple subnets or multiple virtual networks and IP routing.

Once TCP connectivity has been established:

  • Sending messages using DIRECT=TCP: or DIRECT=HTTP: format names with the virtual network IP of the destination machine works with no additional configuration. (DIRECT=HTTP: requires that the HTTP Support subcomponent of MSMQ be installed.)
  • Sending messages using DIRECT=OS: or DIRECT=HTTP: format names with the name of the destination machine requires that the source machine can resolve the name of the destination machine to the virtual network IP. This can be achieved by setting up DNS resolution and have the machines automatically register with the DNS server. Alternatively, an entry with the destination machine’sname needs to be added to %windir%\system32\drivers\etc\hosts. Note that any hosts file entry may have to be manually maintained if the destination machine has a dynamically-assigned IP address and it changes.
  • Remote receive of messages using DIRECT=TCP: or DIRECT=OS: format names requires opening up TCP port 135, the RPC Endpoint Mapper, on the machine hosting the queue. The Windows firewall has a couple of suppliedinbound rules which do this; enabling the rule “Remote Service Management (RPC-EPMAP)” will work, for example.
  • Sending messages using a DIRECT=TCP: format name with the public IP of the destination machine works if a public endpoint for the destination machine is created which mapsport 1801 on the public IP to port 1801 on the destination machine.
  • Sending messages using a DIRECT=OS: format name with the destination machine’s public name (FQDN) works if a public endpoint is created as described above, and the registry key MSMQ\Parameters\IgnoreOSNameValidationis created and set to 1 on the destination machine and the MSMQ service is restarted.

It is not recommended to enable remote reads over the public IP or public FQDN by creating public endpoints for ports 135 and 2105. This would result in a significant security exposure and poor performance.