Motley Queüe

MSMQ and the Windows Firewall

2009-06-16T01:28:00Z

I was called on to assist recently in diagnosing why an MSMQ client was unable to send messages to a queue on a server. One of the things the owner of the machines did was take a network trace on the client of the connection attempt, and what I saw there sent me down the wrong path for a while due to the way MSMQ interacts with the Windows Firewall. To save everyone else the trouble, I thought I'd discuss how the MSMQ installation sets up the firewall to work with MSMQ and why I went astray.

The application in question was using MSMQ's native protocol, so the client was attempting to make a TCP connection to port 1801 on the server. When the client sends the first packet to start the connection process, one of three things will usually happen:

The server receives the packet, and a process (MSMQ's Queue Manager) is listening on port 1801, so the server sends a reply which continues the connection process.
The server receives the packet but no process is listening on port 1801, so the server sends a reply which aborts the connection process.
The server doesn't receive the packet, so there is no reply. The client tries a couple more times, then the connection process times out.

When I looked at the network trace, I could see the client making multiple attempts to start a connection to port 1801 on the server, and the server was not sending back any replies to those attempts, indicating that the network stack on the server wasn't receiving the packets at all. The client had no problem making other kinds of connections to the server, so we knew that the server's networking in general was OK. Selective deafness like that is usually the result of firewall problems, so we briefly went on a wild goose chase looking at the MSMQ-related firewall rules, only to find that they were present and enabled, just as they should be.

Here's the critical bit: when we think of firewalls, we normally think of opening ports, but that is not how the MSMQ installer sets up the firewall rules for MSMQ. Instead, it "whitelists" the mqsvc.exe process for certain network protocols, meaning that (for example) any TCP port which mqsvc.exe opens to listen on causes the firewall to automatically allow packets to that port. This approach was taken because the ports MSMQ uses aren't 100% fixed. This is particularly true of the ports it uses for RPC: MSMQ will automatically use alternate ports if its first-choice defaults are already in use. Other ports can be changed by the use of registry keys. By using these whitelist firewall rules, the firewall automatically adapts to whatever ports MSMQ uses, minimizing surprises and complexity.

The breakthrough in our diagnosing came when we discovered that MSMQ wasn't listening on port 1801, or any of its other usual ports, which quickly led us to discover that it had been inadvertently configured in hardened mode, in which it will only accept messages via HTTP. Since it wasn't listening on port 1801, the firewall wasn't allowing packets to that port, giving the appearance of a firewall problem even though it was doing exactly what we'd asked it to do.

The moral of the story is that, because of the way the MSMQ firewall rules are set up, what appears to be a firewall problem can be a symptom of issues elsewhere. Before you spend too much time staring at the firewall, check that MSMQ is listening on the expected address and port combinations.

JMS and MSMQ interoperability

2009-06-08T10:02:00Z

I have come across this question of whether JMS and MSMQ are interoperabe a number of times and so I decided to address it. Microsoft does not have a JMS provider for MSMQ so basically you will need to use a third party product or implement your own JMS provider.

I came across an interesting article called Enterprise Messaging in a Heterogeneous Environment. The article describes how to use web services as a proxy between MSMQ and a JMS implementation. The solution effectively implements a custom enterprise message bus using which heterogenous applications (.net and java) can communicate asynchronously with each other.

Another way of accessing MSMQ from Java applications is to use JNI (Java Native Interface) as described here. JNI can be used to call the C api that MSMQ exposes, from within Java applications.

MSDN also has some pointers on implementing asynchronous interoperability.

MSMQ and WCF: Getting Started

2009-06-01T06:32:00Z

Windows Communication Foundation (WCF) provides a powerful programming model to develop service-oriented applications. MSMQ integrates very well with WCF so queued applications can be developed using WCF. WCF provides two bindings that support MSMQ - NetMsmqBinding and MsmqIntegrationBinding. NetMsmqBinding provides asynchronous communication between WCF endpoints. The MsmqIntegrationBinding enables a WCF endpoint to communicate with an existing MSMQ application written in C, C++, COM, or System.Messaging APIs.

Here's a list of some useful resources to help you get started.

MSMQ and the Active Directory Recycle Bin

2009-04-25T05:41:00Z

Windows Server 2008 R2 introduces a new feature in Active Directory, the Active Directory Recycle Bin. When MSMQ is installed on a domain-joined machine with the MSMQ directory integration feature installed, it makes use of Active Directory objects, particularly MSMQ configuration objects (objects named "msmq" which are children of computer objects) and public queue objects (which share the name of the public queue and are children of MSMQ configuration objects). We did some experimentation with the AD Recycle Bin and these objects recently and found some points which might be of interest to MSMQ administrators.

Our experimentation covered cases where an MSMQ configuration object or public queue object was deleted accidentally in AD. In you delete a public queue through MSMQ, or uninstall MSMQ on a machine, then you will end up with deleted AD objects, but recovering them from the AD Recycle Bin will not undo that. This is strictly about the case where something has happened in AD and you're trying to undo it, hopefully without affecting your running instances of MSMQ.

Before continuing, I suggest reading the AD Recycle Bin information at http://technet.microsoft.com/en-us/library/dd392261.aspx.

The first note is that part of the process of recovering an AD object from the AD Recycle Bin involves updating its distinguished name, and this property is protected on MSMQ AD objects, so you will need to change the security on the deleted object before you can recover it. Fortunately, this is relatively simple:

In the ldp.exe tool, once you have located in the tree the object you wish to recover, right-click on it, select Advanced in the menu, then select Security Descriptor.
Click on OK in the dialog that comes up.
In the next dialog, select the ACE which denies to Everyone "Write property(cn)". This will usually be the first ACE in the listbox.
Click the Edit ACE button.
In the dialog which comes up, click the Allow radio button, then OK. This changes the deny ACE to allow, temporarily giving Everyone permission to modify the distinguished name.
Click the Update button to actually change the security on the object in the directory.
Now you can follow the rest of the instructions to use ldp.exe to recover the object.

Of course, you will want to undo this security change once you have successfully performed the recovery.

Using the ADSIedit tool, which should be available from the Start menu under Administrative Tools, connect to the DC and drill down in the tree to the object which you recovered.
Right-click on the object and select Properties.
Switch to the Security tab and click the Advanced button.
Select the ACE which allows Everyone, which will usually be the first ACE in the listbox, and click the Edit button.
Switch to the Properties tab.
Scroll down in the list of permissions to "Write cn". There will be a checked box in the Allow column. Click on the box in the Deny column.
OK out of the dialogs. You will see a warning about setting a deny ACE, click Yes.

The second note is that if an MSMQ configuration object is deleted and there were any public queues, you will have to recover all of the public queue objects individually. Start with the MSMQ configuration object, then continue with the public queue objects.

Now, let's consider what happens if a public queue object is accidentally deleted. You won't be able to see the queue in the MMC snapin anymore if you refresh, but any applications currently sending to that queue -- meaning they have an MSMQ handle to the queue which was opened for send -- will continue sending as though nothing had happened. Applications which try to open new handles to the queue may succeed if the local queue manager has a cached copy of the public queue object, otherwise they will fail.

In this situation, do NOT restart the MSMQ service which hosts the public queue whose AD object was deleted. If you can restore the public queue object, then the queue will be visible in the MMC snapin and all the messages in it will still be there, including those sent while the object was deleted. If the MSMQ service restarts while the public queue object is still deleted, then the messages in the queue will be disposed of. Messages for which deadlettering, journaling, or administrative NACKs were requested will be deadlettered, journaled, or NACKed as appropriate, so well-written applications should not experience any loss of messages.

If an MSMQ configuration is deleted, the situation is more complicated. All the public queue objects for public queues hosted on that instance of MSMQ are also deleted, with the effects discussed above. The MSMQ service itself will continue running, and if you can restore the objects quickly enough, there will be little disruption. If the MSMQ service restarts while the objects are still deleted, it will be able to perform operations with any private queues which may be configured. Even in this case, if you restore the objects, MSMQ can recover gracefully: the service will notice that the configuration object has reappeared and directory-integrate itself, and the public queues will reappear as their objects are restored.

How to count messages in a MessageQueue

2009-04-03T21:25:00Z

There are a few different ways of getting a count of the number of messages in the MessageQueue. Here’s a simple one.

public static int GetMessageCount(MessageQueue q)

{

int messageCount = 0;

using (MessageEnumerator messageEnumerator = q.GetMessageEnumerator2())

{

while (messageEnumerator.MoveNext())

{

messageCount++;

}

return messageCount;

}

The GetMessageEnumerator2 method creates a dynamic list of all the messages in that queue. So you can iterate over the list to get the count.

Other ways of doing this are:

Combining LINQ with System.Messaging

2008-02-10T01:26:00Z

Patrick Toolis of the MSMQ test team has written a great whitepaper on using LINQ (Language-Integrated Query) with MSMQ via system.messaging. It's twelve pages long with a number of screenshots and diagrams, so I'm not going to try to post it directly into the blog. Instead, here is a summary and a link to the paper.

Language-Integrated Query (LINQ) provides a way to embed SQL-like query statements into code which iterates over enumerable data. The library System.Linq provides an extension to C# and Visual Basic which allows traditional query syntax to be used in source code. Because the query is embedded in the source, it gets the advantage of compiler facilities such as type-checking, unlike queries in strings which are just text data to the compiler. MSMQ's system.messaging provides enumerators for a number of objects, allowing application writers to use LINQ when dealing with them, particularly messages in queues.

Another New Feature: Transactional Remote Receive

2008-01-23T06:10:00Z

MSMQ has supported receiving messages from queues hosted on other machines ("remote receive") since the beginning. However, remote receives within a transaction have not been supported. That's a significant detail, and has generated a lot of customer requests, because for many applications transaction support is important. Or, to be more specific, the ability to put a message back into the queue if something fails while processing it is important. If the receive was done in a transaction, then the application can abort the transaction, the message reappears in the queue, and the application can try again later; if the application has failed entirely and the process exits, then the transaction is aborted automatically, and the message is not lost and can be retried when the application is restarted. If the receive was not done in a transaction, then at best the application is left unable to either process it or put it back, and at worse the message simply disappears when the application process exits.

If the application and the queue can be hosted on the same machine, that all works fine. However, in some larger customer scenarios, the actual processing of messages requires a farm of machines running the application to provide sufficient capacity, and the queue is hosted on another machine entirely. The application is now doing remote receives, which cannot be transactional, and that presents the serious application architecture problem I just described. Prior to MSMQ version 4, the best workaround was to make the farm machines MSMQ dependent clients whose supporting server was the machine hosting the queue.

With MSMQ version 4, dependent clients are being phased out for a variety of reasons, so the workaround will no longer be available after a certain point. However, it was a workaround rather than the desirable solution, and the MSMQ team has addressed the impending problem by providing the desirable solution: remote receives using transactions are now available, allowing you to implement your application architecture in the straightforward way. Strictly speaking, this feature isn't quite new, since it has been present since Windows Vista was released a year ago. However, the scenarios it is most useful for are more likely to run on Windows Server 2008, so it will probably attract more attention now.

Note that performing a remote transactional receive requires both the receiver and the queue host to be running MSMQ 4, which means either Windows Vista or Server 2008. It also requires MSDTC (Microsoft Distributed Transactional Coordinator) on both machines so that the transaction can be flowed between them. MSDTC itself is present and running by default, but some additional setup is required to enable it to coordinate cross-machine transactions.

Upcoming change in NACK behavior

2008-01-06T00:55:00Z

Hello and welcome back from the holidays!

I will get around to describing how to use acknowledgements and deadlettering soon, but right now, those of you who are already using acknowledgements should know that there is a slight behavior change coming up in Windows Server 2008 and Vista SP1 for certain classes of negative acknowledgements (NACKs).

The classes involved are MQMSG_CLASS_NACK_ACCESS_DENIED (0x8004), MQMSG_CLASS_NACK_BAD_DST_Q (0x8000), MQMSG_CLASS_NACK_BAD_ENCRYPTION (0x8007), MQMSG_CLASS_NACK_BAD_SIGNATURE (0x8006), and MQMSG_CLASS_NACK_UNSUPPORTED_CRYPTO_PROVIDER (0x800B). The thing they have in common is that it is relatively easy for an attacker to craft a MSMQ message which will cause the destination machine to generate one of these NACKs. Depending on how the attacker sets the admin queue formatname in the message, these NACKs could pile up in an outgoing queue on the destination machine or they could spam some legitimate queue on that machine or elsewhere. It's not a very disastrous attack, but it is relatively easy, so in Windows Server 2008 and Vista SP1 these classes of NACKs are suppressed by default. The previous behavior, which was to generate these NACKs, can be restored by creating a DWORD registry value named PermitInsecureNacks under key HKLM\SOFTWARE\Microsoft\MSMQ\Parameters\Security and assigning the value 1 to it.

This behavior change can interact with the MSMQ authentication changes introduced in Windows Vista and described in an earlier posting, since the BAD_SIGNATURE NACK which characterizes some of the issues described there is now suppressed by default.

MSMQ 4.0 Performance Counters and the NetNameForPerfCounters Registry Key

2007-12-15T00:41:00Z

MSMQ provides several sets of performance counters which query the state of the service and other objects (sessions, queues, etc.) and can be used in various monitoring systems. There are a few KB articles and blog entries explaining things you need to know when using the performance counters. This document explains what is new in MSMQ 4.0 performance counters and what you need to know when using the performance counters in cluster setup.

Before MSMQ 4.0 (Vista and Windows Server 2008), MSMQ performance counters were implemented based on PerfLib v1. In this model, a shared memory is created for data exchange between the MSMQ service and the Messaging Queuing Performance Monitoring DLL (mqperf.dll). The shared memory is named by the name of the computer under whose context MSMQ is running. Because PerfLib v1 is not cluster aware, remote query of the virtual server performance counters may not work as expected (http://support.microsoft.com/kb/267316). To solve this issue, a registry key NetNameForPerfCounters was introduced.

In MSMQ 4.0, MSMQ performance counter implementation is based on PerfLib v2, which doesn’t require a shared memory and a performance monitoring DLL. This migration enables local and remote query of performance counters by just specifying the server name; it is expected to work without using the registry key. However, two cluster-related issues were found during the RC testing period:

1. If two or more service instances are running on one node at the same time, performance counter query does not work for either of them.

2. Remote query of clustered MSMQ service counters from a down-level OS does not work as expected.

A decision was made to add back the registry key to partially solve the first issue. Because of the change in PerfLib v2, this registry key doesn’t retain the same behavior as before. The behavior difference is explained under different scenarios. In all scenarios, the performances counters are for services that are running. Some of the terminologies used in the explanation are listed below:

1. Service – the MSMQ service

2. Non-clustered computer – computer that doesn’t have cluster service installed.

3. Clustered node - computer that hosts a cluster.

4. Consumer – applications that call PerfLib APIs to query performance counters.

5. Local – the consumer is running on the same physical machine as the provider (can be under different virtual server context).

6. Remote – the consumer is running on a different physical machine than the provider.

7. Down-level OS – Windows 2000, XP, 2003

8. Virtual server – the Network Name resource an MSMQ resource belongs to.

Scenario 1: non-clustered computer, service is running.

In this scenario, the registry key is not needed. The performance counters are available for both local and remote (including down-level OS) consumers.

Scenario 2: clustered node, node’s service is running and all clustered MSMQ resources are offline.

Assume the node name is XYZ and the query is for XYZ. If the registry key is not set or set to XYZ, the behavior is the same as in scenario 1. Otherwise, no performance counters of any service are available to any consumer. In this scenario, WS08 has the same behavior as WS03.

Table 1: XYZ Counters - Only Node’s Service Running on WS08/WS03 Cluster

Consumer Key	Local	Remote, Vista/WS08	Remote, Down-level
Not set	Working	Working	Working
Set to XYZ	Working	Working	Working
Set to non-XYZ	Not working	Not working	Not working

Scenario 3: clustered node, node’s service is stopped and one clustered MSMQ resource is online (the corresponding service is running).

In the following discussion, counters are assumed for the running clustered service and the name of the corresponding virtual server is XYZ.

If the registry key is not set or set to XYZ, local query and remote query from Vista/WS08 machines are working. Local consumer doesn’t have to be running under the virtual server context. This is an improvement in MSMQ 4.0. Remote query from down-level OS is not working. If the registry key is set but not XYZ, no counters are available to any consumer. The following tables list the results for WS08 and WS03 with differences highlighted.

Table 2.1: XYZ Counters - One Virtual Server Running on WS08 Cluster

Consumer Key	Local	Remote, Vista/WS08	Remote, Down-level
Not set	Working	Working	Not working
Set to XYZ	Working	Working	Not working
Set to non-XYZ	Not working	Not working	Not working

Table 2.2: XYZ Counters - One Virtual Server Running on WS03 Cluster

Consumer Key	Local	Remote, Vista/WS08	Remote, Down-level
Not set	Working only when under XYZ context	Not working	Not working
Set to XYZ	Working	Working	Working
Set to non-XYZ	Not working	Not working	Not working

Scenario 4: clustered node, two or more services are running.

The services running can belong to the node or to virtual servers. Assume the counter that the consumer wants to query is for computer/virtual server XYZ.

If the registry key is not set, performance counter query for any running service is not working for any consumer. This is a regression from Windows 2003, where counter query is working when consumer is running under the same computer context as the service. If the registry key is set to XYZ, the result depends on whether XYZ is the node or a virtual server. If XYZ is a node, the result is the same as in scenario 2. If XYZ is a virtual server, local query and remote query form Vista/WS08 machines are working, but remote query from down-level OS is not working. This is another regression from Windows 2003. If the registry key is set but not XYZ, no counters for XYZ are available for any consumer.

Table 3.1: XYZ Counters - Two or More Services Running on WS08 Cluster

Consumer Key	Local	Remote, Vista/WS08	Remote, Down-level
Not set	Not working	Not working	Not working
Set to XYZ	Working	Working	Working only when XYZ is the node
Set to non-XYZ	Not working	Not working	Not working

Table 3.2: XYZ Counters - Two or More Services Running on WS03 Cluster

Consumer Key	Local	Remote, Vista/WS08	Remote, Down-level
Not set	Working only when under XYZ context	Working only when XYZ is the node	Working only when XYZ is the node
Set to XYZ	Working	Working	Working
Set to non-XYZ	Not working	Not working	Not working

Summary

The results can be summarized as:

1. MSMQ 4.0 performance counters improved for single service scenario. If the consumer is running on a Vista/WS08 machine, no key is needed and the counter query is working even for clustered service.

2. There are some regressions in multiple services scenario. No counters of any service are available when the key is not set. Setting the key will bring MSMQ 4.0 on parity with MSMQ 3.0 if the consumer is running on Vista/WS08 machine.

3. Performance counters of a clustered MSMQ service are not available to any down-level consumers, regardless setting the key or not. This may become a serious issue for customer, and we are actively seeking solutions to it.

Another difference worth mentioning is that, on WS03 cluster, changing the registry key will change the performance counter provider without restarting all services, provided all consumers are shutdown beforehand. However, on WS08 cluster, all services have to be restarted for the registry key to take effect.

On WS03 cluster, the value of the NetNameForPerCounters registry key needs to be in capital letters. This is not required on WS08 cluster.

—Xin Chen
MSMQ Development Team

Determining Whether a Remote Queue Exists, Part 2A

2007-12-09T00:42:00Z

Timeouts, acknowledgements, and deadlettering, working together, will help you deal with not just the situation where a remote queue doesn't exist, but all the other things which could go wrong along a message's way from sender to destination.

MSMQ has two timeouts, which can be set individually for each message: "time to reach queue" (TTRQ) and "time to be received" (TTBR). TTRQ controls how long a message can be in transit before arriving in the destination queue. TTBR controls how long a message can sit in the destination queue before it is "discarded". Both timers start as soon as the message is sent, so TTBR actually includes the transit time as well. TTBR also has priority: the message is "discarded" when the TTBR timer runs out, regardless of how much time may be left in TTRQ. (The act of "discarding" a message may include sending a negative acknowledgment (NACK) and/or deadlettering the message, which I'll talk about later.)

When would you set these timers? Well, suppose you wanted to send a stock price update every minute to an app which would display the current price. If there is a transmission problem, updates could build up on the sender. However, since the receiving app only cares about the latest price, all those intermediate updates building up on the sender are meaningless. Any message which hasn't reached the destination queue in one minute is about to be followed by a message bearing more recent information, so it can be safely thrown away. In this case, you would set TTRQ to 60 seconds. Now, once the message arrives in the destination queue, you don't know exactly when it may be received. If the application only checks the queue once per minute, the message could sit in the queue for another 59 seconds before it is actually received. If it sits in the queue for more than 59 seconds, then there should be another message arriving with more recent information, so you could set TTBR to 119 seconds (or maybe 125 just to allow a little extra margin). On the other hand, if there is a transmission problem, setting TTBR like that could leave the app in a situation where it has no information at all — perhaps you'd like to display an old price rather than nothing. Setting TTBR to 1800 (half an hour), for example, would let updates stay in the queue for a while, but if the receiving app is down, having a TTBR set means you will never have more than a known number of updates sitting in the queue, instead of having them build up indefinitely.

What do timeouts have to do with detecting errors? Timeout settings which are appropriate for your business requirements mean that each message has a definite lifetime, at the end of which you will either get an error indication or you will know that the message has been received, if you have applied the right acknowledgement and/or deadletter settings to the message. Knowing that you will always get a definite answer makes writing your application much easier.

Acknowledgements and deadlettering are how your application gets that answer, and I'll talk about them in part 2B.

Message timers documentation: http://msdn2.microsoft.com/en-us/library/ms705726.aspx

Be Prepared: Known Issues for Upgrading to Windows Server 2008

2007-12-01T06:04:00Z

There are a few differences in MSMQ and IIS functionality between Windows Server 2003 (MSMQ v3.0) and Windows Server 2008 (MSMQ v4.0). This means that there are a few configuration changes you may have to make to your MSMQ system post-upgrade to make everything function the way it did on Windows Server 2003.

Issues with HTTP and transactional messages:

MSMQ’s transactional message support uses internal messages called “order ACKs” to coordinate between sender and receiver so that no user messages are lost. When transactional messages are sent via HTTP, the URLs used to send the order ACKs back to the sender sometimes contain the special character “+”. IIS 7 has a security feature in request filtering to disallow all double escaped characters, and this interferes with the return of order ACKs to the sender if the URL contains a “+”. This results in the transactional messages accumulating in the outgoing queue of the sender in those cases. In order to prevent this issue, which may arise any time transactional messages are sent via HTTP, you can disable the double escaped character filtering in IIS7 for MSMQ’s virtual directory. This can be done using the appcmd tool like so:

%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/msmq" -section: system.webServer/security/requestFiltering -allowDoubleEscaping:true -commitpath:apphost

To Keep Multicast working:

On Windows Server 2003, MSMQ’s multicast support was part of the MSMQ core optional component: if MSMQ was installed, support for multicast messages was also installed, as was the PGM Multicast transport which it depends on, and the firewall did not filter PGM traffic. In order to tighten security for users who aren’t using this feature of MSMQ, multicast support is now a separate optional component, and it is not installed by default during an upgrade. If you intend to use multicast messages after an upgrade, you must explicitly install it the same way you would install any other MSMQ subcomponent. You can either do this through the UI (in Server Manager), or on the command line via ServerManagerCmd. See my previous post on Unattended Installation for Windows Server 2008 for more information on unattended installations.

—Jolie Boushey

This Post Intentionally Left Blank

2007-11-26T01:30:00Z

It's a holiday weekend here. Happy Thanksgiving to all our US readers! Tune in next week for another exciting adventure.

Please Stand By

2007-11-17T21:00:00Z

Justin is out of the country and I'm on the far side of the continent, so we're experiencing a small break in our posting schedule.

For now, a quick tip: MSMQ is a transport. It supports a few mechanisms for scanning through the messages in a queue, but they were never intended for high performance and there is no built-in way to search for a message by property values. If you are thinking about leaving messages in the queue and picking them out according to some selection criteria, you are probably setting yourself up for problems in the future. A better architecture to achieve the same thing is to write a little application that receives messages from the queue and stuffs them into a database, then select messages out of the database with the full power of SQL available to you.

Determining Whether a Remote Queue Exists, Part 1

2007-11-11T02:50:00Z

One of the basic principles of MSMQ's design is that sender and receiver are decoupled. The sending application does not need to know whether the receiving application is running or even reachable under current network conditions: it can just send, and let MSMQ take care of getting the message to the destination at whatever time that's possible. (Note that the decoupling occurs within MSMQ, and that both of the applications are tightly coupled to MSMQ, requiring the local MSMQ service to be running in order to perform MSMQ operations.) This design principle determines how MSMQ behaves in various circumstances when a queue doesn't exist.

When sending, the local MSMQ service knows what local queues exist, so it immediately returns MQ_ERROR_QUEUE_NOT_FOUND, hexadecimal value C00E0003, if you attempt to open a nonexistent queue for send. However, opening a remote queue for send will always succeed, regardless of whether the queue or even the machine exists. This is where and how the decoupling between sender and receiver occurs — MSMQ has no way to tell the difference between a remote machine which is temporarily unreachable, one which used to exist but is never coming back, and one which just plain doesn't exist, so it makes no attempt to do so. It just allows all sends and goes through the same retry procedures to attempt to get the messages to where the sending application said they should go.

Receiving is a little different. If you open a queue for receive and the queue doesn't exist, you will always get error code MQ_ERROR_QUEUE_NOT_FOUND back regardless of whether the queue is local or remote. If the queue you're trying to open is local, then the MSMQ service knows whether the queue exists; if it's remote, then the local MSMQ service must contact the MSMQ service on the remote machine. As described above, decoupling occurs on the sending side, and the original designers chose not to include a second point of decoupling on the receiving side, so even remote receives are tightly coupled.

Getting back to the title of this post — in summary, there is only one place where this question can occur: when sending to a remote queue. In all other situations, the presence or absence of the queue is immediately obvious in the return code of the API call. When sending to a remote queue, this is a question that you probably shouldn't be asking, to be honest. If your application determines whether a remote queue exists before sending to it, then you have given up the decoupling which is a major reason to be using MSMQ in the first place. In part 2, I will cover timeouts, acknowledgements, and dead lettering, at least some of which you should probably be using anyway, since they not only handle the case where the remote queue doesn't exist, they also handle all the other things which could go wrong even if it does. And if you really do need to know whether a remote queue exists, I'll cover how to find out in part 3.

A Preview of Windows Server 2008 MSMQ Clustering

2007-11-03T03:22:00Z

A very user friendly administrator UI tool for creating, configuring and managing MSMQ Clusters

While this isn’t really a new MSMQ clustering feature, it’s worth being mentioned first. If you have used Win2k3 Cluster’s Cluster Admin UI, you will find the new and improved UI tool, which can be launched from Start->Administrative Tools->Failover Cluster Manager, a no-brainer.

When creating a MSMQ cluster virtual server, the UI will create the virtual server with the resource group, all the necessary resources in the group including IP address, disk, network name, MSMQ and MSMQ Triggers, and their default properties and dependencies automatically. It saves you all the steps you would have to do yourself in Win2k3 Cluster. Another cool thing is that the UI first checks if MSMQ and MSMQTriggers are installed on all the nodes before creating the virtual server; if not, it will stop and pop up an error.

No more downloading MMCV.exe for managing MSMQ virtual server

Instead, you will find a link on the Failover Cluster Management UI called “Manage MSMQ”, as shown the picture below.

If you click the link on the active node, you will get the MMC plugin with MSMQ folder under “Services and Applications”. You can view public, private, and system queues.

MSDTC goes Active/Active

What does this have to do with MSMQ clustering, you may ask? How about this: each MSMQ resource group can have its own DTC resource and you can make your MSMQ resource depend on the DTC resource. That means you can guarantee that the DTC resource will come online before the MSMQ resource when a failover occurs.

—Jenny Zhou