MSMQ On a Virtual Machine Windows Server

Question

Hi!

I cannot configure an MSMQ private queue on a Windows Server 2019 on an Azure Virtual Machine and make it work. I have created the firewall rule in Azure for 1801 from my IP and on Windows Defender Firewall. I have created the queue and given everyone all access, even anonymous access.

When I run Python code on my computer queue outgoing queue is created and indicates connected. Messages are put into the quue and disappear but don't appear on the virtual machine's private queue

Does anyone know what to look for next?

Best regards,

Answer 1

Hello, @Pedro Sarmento !

How do I get MSMQ to work on an Azure virtual machine?

This is a bit of a gray area as MSMQ is an older solution (introduced in 1997) that currently offers limited support and would be replaced by more modern messaging services on Azure like Azure Service Bus or Azure Storage Queue.

The official guidelines for running MSMQ in Azure Virtual Machines was published in 2013 and has not been updated:
https://learn.microsoft.com/en-us/previous-versions/azure/dn529082(v=azure.100)?redirectedfrom=MSDN

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 when the 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 via HTTP/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’s name 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 supplied inbound 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 maps port 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\IgnoreOSNameValidation is 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.

More recent reports suggest that this is now fully deprecated on Windows Server 2019 and seems to be in alignment with the operating systems listed in the documentation (as well as the Wikipedia page):

https://learn.microsoft.com/en-us/previous-versions/windows/desktop/msmq/ms711472(v=vs.85)

Applies To: Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server Technical Preview, Windows Vista

If you are set on using MSMQ, let me know in the comments and I can try to find a specialist that may have more updated information on supported operating systems.

---

I hope this has been helpful! Your feedback is important so please take a moment to accept answers.

If you still have questions, please let us know what is needed in the comments so the question can be answered. Thank you for helping to improve Microsoft Q&A!