Search code examples
msmq

Cannot read remote private queue

I'm trying to get MSMQ 5 working on my two Windows Server 2008 R2 virtual machines. I can send to local and remote private queues, and I can read from local private queues. I can't read from remote private queues.

I've read a number of suggestions, especially the ones summarised by John Breakwell at MSMQ Issue reading remote private queues (again).

Things I've already done:

  • Turned off firewalls on both machines.
  • Ensured that Everyone and AnonymousLogon have full control of the queues. (If I take away AnonymousLogon access, then I can't remotely send to the queue, and the message ends up with "Access is denied" on the receiving machine.)
  • Allowed Nonauthenticated Rpc on both machines.
  • Allowed NewRemoteReadServerAllowNoneSecurityClient on both machines.

the sending code fragment is:

        MessageQueue queue = new MessageQueue(queueName, false, false, QueueAccessMode.Send);
        Message msg = new Message("Blah");
        msg.UseDeadLetterQueue = true;
        msg.UseJournalQueue = true;
        queue.Send(msg, MessageQueueTransactionType.Automatic);
        queue.Close();

The receiving code fragment is:

   queueName = String.Format("FormatName:DIRECT=OS:{0}\\private$\\{1}",host,id);
   queue = new MessageQueue(queueName, QueueAccessMode.Receive);
   queue.ReceiveCompleted += new ReceiveCompletedEventHandler(receive);
   queue.BeginReceive();

...

    public void receive(object sender, ReceiveCompletedEventArgs e)
    {
        queue.EndReceive(e.AsyncResult);
        Console.WriteLine("Message received");
        queue.BeginReceive();
    }

My queueName ends up as FormatName:DIRECT=OS:server2\private$\TestQueue

When I call beginReceive() on the queue, I get

Exception: System.Messaging.MessageQueueException (0x80004005)
   at System.Messaging.MessageQueue.MQCacheableInfo.get_ReadHandle()
   at System.Messaging.MessageQueue.ReceiveAsync(TimeSpan timeout, CursorHandle cursorHandle, Int32 action, AsyncCallback callback, Object stateObject)
   at System.Messaging.MessageQueue.BeginReceive()

I've used Wireshark on Server1 to look at the network traffic. Without posting all the detail, it seems to go through the following stages. (Server1 is trying to read from a queue on Server2.)

  • Server1 contacts Server2, and there is an NTLMSSP challenge/response negotiation. A couple of the responses mention "Unknown result (3), reason: Local limit exceeded".
  • Server1 sends Server2 an rpc__mgmt_inq_princ_name request, and Server2 replies with a corresponding response.
  • There's some ldap exchanges looking up the domain, then a referral to ldap://domain/cn=msmq,CN=Server2,CN=Computers,DC=domain which returns a "no such object" response.
  • Then there's some SASL GSS-API encrypted exchange with the LDAP server
  • Then connections to the ldap server and Server2 are closed.

I've tried enabling Event Viewer > Applications and Services Logs > Microsoft > Windows > MSMQ > End2End. It shows messages being sent, but no indication of why trying to receive is failing. How can I debug this further?

Solution

  • The problem was related to domains. Server1 and Server2 were part of a development domain. My login account was part of the corporate domain. The development domain trusts the corporate domain enough for me to log in, be a member of administrators, install features etc. But it seems to be insufficient trust to read remote queues.

    I found this by looking into public queues. If I was having trouble reading remote private queues, perhaps I should get more data by trying public queues. After installing the appropriate directory integration feature, I was able to create a public queue, but not see it in the list of public queues. Trying to refresh the list of public queues gave me this error:

    Not all public queues can be displayed. Only public queues cached locally can be displayed. Error: The object was not found in Active Directory.

    Google pointed me to John Breakwell's answer to a similar problem here, which indicates that trust relationships don't work across messaging protocols.