My company use MSMQ as the middle tier for its web sites and web services.

Having recently joined the company I was quite alarmed by the configuration, very little understanding of security and networking by my predecessor.  He’s gone to pastures new.

Our DMZ had numerous server hosting queues and an AD domain because MSMQ was installed with AD integration.

I needed to meet following objectives

1. To move these middle their application servers to the internal LAN, to lessen the DMZ foot print and potential attacks.
2. We have an SLA that requires us to keep all message processed for 6 years. There was a very flaky routine that ran on all the queue servers that archived the MMSQ journal messages. I wanted to access the journal queues from the internal LAN and archive messages to fileserver.
3. I also wanted to use our new MS-SQL cluster to host clustered queues, for resilience, our business is soon to run 24/7. This server would be on the Internal LAN giving us a front end and backend firewall. The backend firewall would be ISA 2004.

Figure 1 Current Configuration

Figure 2 - Secure Configuration

Accessing remote queues for reading messages and performing any other queue operations requires additional ports and RPC filter configuring.

Key points are:-

• Always use private queues if you can. Public queues are registered with Active directory which can be troublesome.  Keep it simple.
• If you need to send only to a remote queue then all that is needed is to open TCP Port 1801 with a server publishing rule and use direct format names.
• Accessing remote queues for reading messages and performing any other queue operations requires additional ports and the RPC filter configuring
• Message Queuing needs to be installed to send messages. Messages are sent via the Queue manager on the sending machine
• Although a message appears to be sent it could be stuck in the outgoing queue of the sending server. Unless you build it in to your sending application there is no acknowledgement that a message has arrived.
• To send to remote queues certain privileges need to be assigned to receiving queues. Windows 2003 has security enhancements than can block messages
• Remote transactional queues can’t be read

• There aren’t many utilities for testing so unless you can write you own you’ll need a developer to write one. Luckily I’m a bit of a code dabbler and managed to adapt some code from a book I bought on MSMQ. http://www.apress.com/book/bookDisplay.html?bID=287

I followed the excellent example on the www.isaserver.org website http://www.isaserver.org/articles/2004rpc.html but made the necessary changes for MSMQ

MSMQ support several type of queues the most common being public and private.

You need to address the queues with direct format names. In C# I used FORMATNAME:DIRECT=OS:MYServer\QUEUE1 because MS Cluster work with names when it comes to queues. You could use FORMATNAME:DIRECT=TCP:192.168.1.1\QUEUE1 if your using a single server. These are both for public queues for private queues use FORMATNAME:DIRECT=OS:MYServer\Private$\privatequeue.

You can use HTTP to send messages if you’re using Windows 2003 and just change the format name FORMATNAME:DIRECT=HTTP:www.myserver.com\Private$\privatequeue. This means you need to use port 80 and HTTPS is supported as well, I didn’t want to open up port 80 to my internal LAN.

As I’ve said if you only need to send then TCP port 1801 is all that is required.

MSMQ use the following ports

As stated in the article on www.isaserver.org RPC end points can de difficult to find but I found them by running MS portqry tool.

I pointed this at the queue server with the following command “portqry –n MYServer –e 135”. This produces a fairly long list but it’s quite easy to identify the relevant MSMQ ports.

Creating a New RPC Protocol Definition

We now know the UUID’s to publish so we need to create the firewall rule to implement it.

First of all, we need to create our own ‘RPC protocol’ by giving all the UUIDs to publish.

To do so, create a new firewall rule, but rather than selecting a protocol in the list, click New, then RPC Protocol:

Select -add interfaces manually: This option will provide an interface where we can manually type the UUID(s) we want to publish (on that screen interface means RPC UUID):

The best way to add the interface is to capture the output for the portqry used earlier to a file and then copy and paste the MSMQ UUID’s , this avoids any typo. Don’t forget the curly braces.

Add all the interfaces identified in the MSMQ UUID table above

Next I created a new Protocol for the MSMQ which included all the Ports listed above and I called this MSMQ Inbound

Next you need 2 server publishing rules on for the MSMQ Inbound and one for the RPC filter to the relevant server

Almost there, next we need to configure security

Security

Remote queues need the ‘Receive Message’ for ANONYMOUS LOGON to send messages. This sounds back to front but it’s in respect to the sending application in that it can receive messages from the remote queue.

If you’re using Windows 2003 server then you’ll need to edit the registry because 2003 MSMQ by default establishes an encrypted channel to access queues from domain clients. If your accessing from a non trusted domain then you’ll need to add

at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\security for a non-clustered server and at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Clustered QMs\MSMQ$ Service\Parameters\security for a clustered resource .

See the MSMQ Security Overview http://technet2.microsoft.com/WindowsServer/en/library/97efae9f-8657-43fa-89de-e299b45dc7501033.mspx?mfr=true

Testing

I developed and application from code in the Apress Book Pro MSMQ http://www.apress.com/book/bookDisplay.html?bID=287

This sends in the FormatName:DIRECT=OS: because clusters work with names rather than IP addresses. You’ll need .Net Framework 2.0 and MSMQ installed.

Sending always works because it goes to the local queue manager and then that tries to send. If it can’t get through it will end up in the dead letter queue

Living with MSMQ

My message queues got a lot of blame for causing issues with applications and a common message is “insufficient resources” in the apps logs.  It turned out to be bad design of the application.  The developers were using the queues like a database i.e. searching the queue for messages meeting a certain criteria.  The code was redeveloped to take the top message of and process it, since then MSMQ has been very reliable but has been a steep learning curve.