Building an MSMQ Cluster


Why bother clustering MSMQ at all?  Fault Tolerance.  As you probably know, Microsoft Message Queuing (MSMQ) is a queuing system which is typically used as middle-ware between applications.  MSMQ can store almost any type of data within MSMQ messages, and route them to another MSMQ queue manager where they can be retrieved by the receiving application.  MSMQ already provides an extra layer of reliability in the case where something on the back-end may not be available, the front-end can continue to receive requests and store them as MSMQ messages.  So what happens if the computer running MSMQ goes down, and the entire machine becomes unavailable?  That’s where a cluster helps us, as it adds provides fault-tolerance for those types of scenarios.  Node #1 fails, and Node #2 automatically takes it place.  An extremely simple and relatively inexpensive (given today’s hardware costs) solution. 


How to Cluster MSMQ?

All you need to cluster MSMQ in addition to the hardware and basic cluster setup, is a network name resource, and a disk-resource.  Step-by-step instructions can be found in the white-paper titled Deploying MSMQ 3.0 in a Server Cluster.


How Many Instances?  How does my Application Distinguish Between Local and Clustered MSMQ?

After you’ve successfully clustered MSMQ, it’s important to understand the difference between local and clustered MSMQ.  By default the local instance of the Message Queuing Service is set to Manual after MSMQ has been clustered, but it’s still there, and can easily be started at any time.  If you try running an MSMQ Application from the local command prompt, it’s either going to use the local MSMQ Service, or if that service isn’t started, it’s probably going to generate an error.

For most people in a typical two-node cluster, there are three instances of MSMQ.  Two local instances (one on each node) and the clustered instance which runs on the Active Node.  The clustered instance an be failed over between nodes from Active to Passive and vice-versa.  There aren’t always three instances though, a better way of stating that you can have (# of cluster nodes) + (# of clustered instances of MSMQ) nodes.

So, if there are so many available instances of MSMQ, how do you get your application to use a particular instance?  The answer depends on the the computer name that the application sees as its native computer name.  If you launch a regular command prompt and type in ” set COMPUTERNAME” it should display the current computer name.  If this is the name of the local node, then the application will try to use the local instance of MSMQ.  In order to get something to run within the context of the cluster, it needs to be using the same Network Name resource as clustered MSMQ.  This can be accomplished in one of two ways:

-Cluster your application in cluster administrator, ensuring it has a dependency on the same Network Name Resource being used by clustered MSMQ.  Then select the “Use Network Name as Computer Name” option

-Create a clustered command prompt.  Basically create a clustered resource for cmd.exe, and ensure that you follow the rules above and create a dependency on the same Network Name Resource being used by MSMQ, and ensure that the “Use Network Name as Computer Name” option is selected.  When you bring the resource online, you should see the command prompt.  From this clustered command prompt, try the same “set COMPUTERNAME” test I mentioned above.  This time you should see the virtual cluster name being displayed instead of the local node name.  If you run your application from this clustered command prompt, it should see clustered MSMQ as it’s native instance.  You can also run Computer Management (compmgmt.msc) from this prompt to administer clustered MSMQ.  Be aware that the prompt will not be displayed if you aren’t either physically at the node, or if you’re not logged in using the /console switch through mstsc.


Administering Clustered MSMQ

In order to properly administer clustered MSMQ, it’s recommended to either run Computer Management from a clustered command prompt (see above), or otherwise you can use the MMCV utility.  MMVC will allow you to launch Computer Management using a particular computer name, so you can easily specify the name of your virtual clustered server.  The syntax to use is “mmcv.exe -s <myVirtualServerName>”, it’s an extremely useful tool, and I’d strongly suggest including a copy of it on all of your MSMQ cluster nodes.  You can find out more about MMCV and find a link with a download in the following article: How to use the Mmcv.exe utility to manage clustered Message Queuing resources

Helpful Tips

Most clusters have multiple IPs, use the BindInterfaceIP registry key with clustered MSMQ to ensure that MSMQ binds to the correct IP: A cluster node with two network cards does not receive messages

Ensure that the local instances of MSMQ are set to run using the Local System account, even if they’re stopped and set to manual.  Having them set to use a particular user in an environment running clustered MSMQ will most likely cause issues.

If you’re going to be using Public Queues, or will have clustered MSMQ installed with the Active Directory Integration option, then ensure that Kerberos is enabled on your Network Name Resource in Cluster Administrator.  This will create an object for the virtual machine in Active Directory which will hold MSMQ’s public information.

Keep in mind that clustered MSMQ inherits the installation settings from MSMQ on the nodes, so only select the features that you need in order to minimize overhead.

Failover over the cluster is equivalent to restarting the MSMQ service.  In short, express messages will be lost, so if you need to preserve your data, then ensure that the message are either set to “recoverable” or use transactional queues.

I hope that you found this brief explanation of clustering MSMQ to be useful, and please don’t hesitate to post any comments, questions, or suggestions.

Comments (9)

  1. MSDNArchive says:

    Is that tumbleweed blowing past?  😉

  2. sureshm says:

    This is very informative and good start for the begginers.

  3. richieNSS says:

    This has explained a lot, but I have a question.  We would like to set up a private queue, one a cluster, we would like a multicast queue.   We will then have applications that will connected to queues on the same multicast address.  We have been told that we can only have one queue on a cluster, is this true?



  4. MSDNArchive says:


    What exactly were you told about "one queue on a cluster"?

    A multicast queue is listening on a IP-address/port-number combination.

    I think what you are after is:

      Running X applications, each with a dedicated queue.

      Having X queues, each with the same IP-address/port-number combination.

      When a message is multicast, each queue and therefore each application gets a copy.

    Is that right?

    That will work fine.


    John Breakwell (MSFT)

  5. Molgev says:

    "When you bring the resource online, you should see the command prompt."

    Does this mean an icon appears on the desktop? I’ve tried the above but nothing happens.

  6. the url don’t work for the deployment doc not even from other ms web site can you check this and let us know

  7. T says:

    Deploying Message Queuing (MSMQ) 3.0 in a Server Cluster…/confirmation.aspx

  8. Mitesh Bhatt says:

    Thanks for the good information, got a question though. I did following, still it doesn't pop command on the console session, any thoughts will be appreciated!

    – Added CMD using Cluster Admin (Add resource) > Passing command line as, %windir%system32cmd.exe should get the Generic application in the Group of MSMQ.

    – Now, the application in cluster administrator, should have the dependency as the same Network Name Resource being used by clustered MSMQ.  

    – Also, we need to select the "Use Network Name as Computer Name" option.

    – So now if we bring up command prompt online from Cluster admin it should pop up. As in, it will be viewable for someone whose doing a console session **only** and not RDP.

    – So, to do this, I did mstsc –console or mstsc -admin (I guess this should take up the console and not RDP session).

    – But I don’t see cmd prompt, I see it in Task Manager running as a process. But on screen, don’t see anything. Did I missed something 

  9. Ashwin says:

    Why do we need to run the local message queuing with " local Account" why nor a service account.

    If yes arise, what type of issues arise.

    Ashwin Thakur