Cannot programmatically peek into a remote (private) msmq: Access to Message Queuing system is denied
Asked Answered
C

3

5

I've got a very simple console app that is having trouble peeking at a message in a remote private queue.

var queues = MessageQueue.GetPrivateQueuesByMachine(machineName);
var queue = queues.Where(x=>x.FormatName == queueName).Single();
Message message = queue.Peek();

The Peek call fails with a MessageQueueException of "Access to Message Queuing system is denied".

Using the same client machine and user I am able to view the queue using Queue Explorer and with the Message Queuing Snap In.

Experimenting with a local queue I am only able to reproduce the error by taking away the Peek permission on the queue but that also stops it in the other tools.

I've seen lots of information that points me to the issues outlined here.

However, it seems like if any of those things was the issue, I wouldn't be able to do it using the other tools as well.

EDIT I have been able to get this to work using the MSMQQueueInfo/MSMQQueue COM objects without changing any credentials. It would be nice if I could make it work using the .NET libraries but at least I have a workaround.

Caton answered 28/8, 2015 at 15:41 Comment(3)
What do you put in machineName and queueName ? How did you initialized them? How and what you put messages into MessageQueue?Bricebriceno
This example is a bit of a simplification. I am not having any trouble listing the queues or selecting the specific queue I am interested in. For this particular case I am looking at an error queue from one of our production applications. I know there are messages in the queue because I can see them using other tools.Caton
Which permissions you configured?Bricebriceno
C
3

My issue was that when GetPrivateQueuesByMachine is used to get the queue, it uses a access mode of SendAndReceive which is asking for more permissions then I had. I had to use the MessageQueue constructor to specify the AccessMode. (In this case Peek.)

In the end, I was able to get this to work using code similar to the following:

var queue = new MessageQueue(@"FormatName:DIRECT=OS:machineName\private$\queueName", QueueAccessMode.Peek);
Message message = queue.Peek();
Caton answered 21/9, 2015 at 14:7 Comment(0)
D
2

That the queue shows up in various utilities just doesn't tell you that much. Such a utility is pretty unlikely to be peeking at messages. In general, the default access permissions allows everybody to see the queue and post messages to it. But not retrieve them.

On the machine that owns this queue, use Control Panel > Administrative Tools > Computer Management > Services and Applications > Message Queuing > Private Queues. Select the queue and right click > Properties > Security tab. Note how Everbody has some rights, like "Get Properties" and "Send Message". But not "Peek Message".

Sane thing to do is just add the user account that you use on the other machine and tick the rights you need to get the job done. If this machine is managed by an admin then you'll need to ask them to do it for you.

Deviate answered 28/8, 2015 at 15:41 Comment(4)
I do not have access to the machine itself and I cannot view permissions. It isn’t the fact that the queue shows up in other utilities that I am going off of. It is that I can view the full message and do pretty much anything else I want. For example, I frequently copy the messages from the error queue and replay them. I use peek as an example but I cannot get my app to do any of the same operations that I am able to do using other tools. I’m trying to automate some tasks I do frequently with other tools so I know I must have the permissions needed to do it even if I can’t see them.Caton
I suspected as much. That's why I recommended to ask the admin to take care of it. "I can still do this" is still not a slamdunk, looking at the error queue isn't the same thing and "replaying" certainly can't be a problem since everybody can send messages. Talk to the admin so you know a fact.Deviate
I'v confirmed with an admin that I do have peek access.Caton
Then you're down to problems with the user account. Like using an account that's only known to the machine that you run this on instead of a domain account that the other machine knows about as well. Or the machines are not on the same domain. Pay attention to the domain name when you log in. Do ask the admin to look over your shoulder, he might well spot an oops. It is his job to ensure you have access.Deviate
H
2

I too had the same problem. In my case, I was initializing Message Queue in parent thread and accessing Peek function in child thread.

In case you are using multi threading, try to keep initialization and access of function in same thread.

Heterosis answered 15/9, 2015 at 14:12 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.