MSMQ messages using HTTP just won't get delivered #10

This post refers to the situation where a client is sending MSMQ messages over HTTP to a receiving server hidden behind a firewall.

The messages will be stuck in the Outgoing Queue with a state that switches between "Inactive" and "Waiting to Connect."
If you collect a Network Monitor trace then you should see that the server replied to the message from the client with a response of "HTTP 400 - Bad Request" without including a body in the response.
If you had a PSS engineer format the MSMQLOG.BIN file from the target server then you would see:

[0]694.f28 04/06/2004-15:16:19.608 [lib DestinationQueueToProps] ERROR:Packet is not accepted by QM
[0]694.f28 04/06/2004-15:17:23.636 [qm AppIsDestinationAccepted] ERROR:Packet rejectet because http routing is not supported

The problem here is that the message is being sent to the public IP address bound to the firewall.
The destination server, though, is using a different IP address through Network Address Translation.

As a result, a message being sent to "DIRECT=https://22.33.44.55/msmq/private$/DestinationQueue" reaches the server successfully and IIS delivers the message to MSMQ. However, MSMQ looks at the address and notices that the server does not have a matching IP address assigned to it, having a 192.168.x.y local network address instead. MSMQ decided that the message must be meant for a different machine but there is no routing information available so request is rejected.

The solution is to create a mapping file on the receiving server so that MSMQ knows what to do with messages sent to the 22.33.44.55 address.

The XML mapping file should be located at <%SystemFolder%>\System32\msmq\mappings\ with any filename and looks something like this:

<redirections xmlns="msmq-queue-redirections.xml">
    <redirection>
        <from>https://22.33.44.55/msmq/private$/DestinationQueue</from>
        <to>https://192.168.44.55/msmq/private$/RealQueue</to> 
    </redirection>
</redirections>

Notes

  1. The MSMQ service must be restarted for the mapping file to take affect.
  2. The syntax of the routing file is different between Windows Server 2003 and Windows XP.
  3. You can also get this problem when sending messages using a network name that resolves through DNS to the correct IP address of the destination but the machine actually has a different network name.
  4. In general, to test a connection, browse with Internet Explorer to https://receivingMSMQserver/msmq. You should see something like "Error 501/505 - Not implemented or not supported". This means that you connected successfully but MSMQ was expecting a message and, not surprisingly, complained.

References