I have a public message queue on my local machine that I created with my user account. I have a Windows service also on my local machine that runs under a corporate service account. I have granted the service account full access to the queue, and yet when the service is running, it can't seem to read the messages on the queue. I feel like I'm missing something rather basic, but I haven't been able to figure out what it is.
Code:
string queuePath = "FormatName:DIRECT=TCP:127.0.0.1\MyQueue";
MessageQueue _queue = new MessageQueue(queuePath);
When I step through the code, after the _queue object is created, the CanRead property is always false. I've tried several different ways of setting the queue path ("DIRECT=OS:.\MyQueue", "PUBLIC=[guid]", and without using a format name as well), but nothing has been successful.
The MSDN documentation states that "CanRead is false if a queue is already open with exclusive read access (or if it's open with non-exclusive access and this MessageQueue requests exclusive access), or if the application does not have sufficient rights to access it."
I've made sure that the application has sufficient rights (I think), but how can I tell if something else has "exclusive read access" to it? Is there anything else I'm missing?
Thanks.
Why are you using public queues? You should try re-create the queue as private (queue address will change to FORMATNAME:DIRECT=TCP:127.0.0.1\PRIVATE$\MyQueue) and see if this resolves your issue.
I have been using MSMQ for five years and have never used a public queue. I don't actually understand what they're for. But from experience people who try to use them usually have much more difficulty around authentication.
Related
Maybe an easy question for someone who knows Powershell and O365 well. Is there a way to configure it so when a command is run for example to pull all access to a shared mailbox, that either a service account is permissioned each time to pull that information or the user who is running the script? I looked at connecting an SA to the script but it would have too much access to 0365 to give it the specific permissions. So the account is not permissioned for the access by default but every time the script/command is ran its permissioned for that inquiry which it shows then it won't have access until the next time its called.
Looking to add this type of function to a script which we only want the helpdesk people to see the information when they run the script and the specific command in the script.
Hopefully explained clear enough :)
Thanks all.
I don't think there is a way to do that natively. You could fiddle something with Azure PIM but that's more for one-off operations than minute action that are done often.
You could however circumvent that by making some sort of web interface that triggers commands on another server using a privileged SA and returns the output through the web interface. You can just make it so that the interface can only request one specific command to be run, and the only thing you have to worry about is sanitizing your parameters well to avoid unwanted injection.
Alternatively, what are you trying to protect against by restricting access so much ? Isn't it something that could be done more easily using a read-only account and some clearly defined policy ? If your helpdesk people overstep their allowed scope, that's a management/HR problem as much as a technical one.
I have a project that I have to do that deals with queues being loaded successfully and unsuccessfully whereby I do manually at the moment that can be tedious and also positive negative meaning the orchestrator can state that new queues have been added but when I access the actual job (process) nothing has been added.
I would like to know, is there a way to monitor queue success and unsuccessful rates on orchestrator instead of the using monitoring it manually?
You can access pretty much any information via the Orchestrator API.
You can find the "Orchestrator HTTP Request" activity, which will allow you to access any relevant endpoint.
Note that the provisioned Robot in Orchestrator needs to have the right access permission, so please have a look at what roles are associated to the Robot user.
The API reference can be found here:
https://docs.uipath.com/orchestrator/reference
You will see it mentions swagger, which in turn will give you all the information you need to access the relevant APIs.
I am writing/testing a server side plug-in and am looking to derive if this is running on our development or production TFS instance to allow me to drive a slightly different process (e.g. add some obvious text to any email subjects that it sends out to ensure that people know it has derived from the development instance).
There is a "IsProduction" property that I can access via the requestContext variable (IVSSRequestContext.ServiceHost.IsProduction - was previously TeamFoundationRequestContext.TeamFoundationServicehost.IsProduction before TFS2015), but this property is set to true in both instances.
Does anyone know if/should this can be used for that purpose and if so, how it can be set as I can't find any documentation online and can't see anything obvious in the TFS Admin Console.
No, but I suggest using a global Environment variable (e.g. IsDevelopment).
Another option is to get the server URL (see code snippet) and use it to determine the environment, but I think it is less safe.
private Uri GetCollectionUriFromContext(IVssRequestContext requestContext)
{
ILocationService service = requestContext.GetService<ILocationService>();
return service.GetSelfReferenceUri(requestContext,
service.GetDefaultAccessMapping(requestContext));
}
When I try to test the queue via the Message Bus. I've checked and permissions are set to full control for everyone. I use 'msmqmng.exe send' from a different machine to put a message onto the queue, it works and is absolutely the message I sent. So what other moving parts might I be missing???
I spent couple of days banging my head for this error, and the root cause was that the storage quota for MSMQ was exceeded! which doesn't seem related to the error message, which makes it a difficult cause to detect...
When sending a message to MSMQ, the sender server will use an outgoing queue located on the sender side, and this outgoing queue is using the storage on that sender server.
The MSMQ component has a maximum quota, defined in the MSMQ properties, and when this quota is exceeded, the above error message starts popping (that's why when you sent from another machine, it worked correctly, since the issue is with the sender not the receiver).
Resolution:
To change this quota, right click on Message Queuing (from Computer management if using Windows server 2003 for example) then properties... (I cannot post images since i am a new user), but in the properties window, you will find in the first tab an editable storage limit field.
To check the currently used storage on the server, open the path of the storage, and check its size: (open the storage tab in the same properties window, and get the path of the storage folder)
If the size of the quota is similar to the size of the storage folder, then this is the root cause of your issue.
If you dont have permission to increase this quota limit, you should have your user added to the "Security" tab in the message queuing properties window.
Hope this helps...
Please vote up if you agree in order for me to have some points and post images in my next answer... :-)
Setting up the queue in Server Manager, Message Queueing I neglected to add the data source name to the queue name. (queue_name_dsNAme) So from one side I was able to insert messages. However, from the Server Group, Message Bus, it automatically appends the data source to the queue to be tested. So, the queue really did not exist.
Turns out there's another twist... even after the naming convention was sorted out there was an application that knew of the queue and was reading from it. When the test message was sent the app grabbed it before the test mechanism had a chance to receive it back, which caused the timeouts. By enabling journaling the message gets put there and you can see what went through the queue. While all this may seem obvious... it pays to ask stupid questions.
When I deployed my site that uses nservice to a new production box, it was unusably slow...
After some debugging I discovered that mqsvc.exe was taking up 50% of the CPU usage and the other 50% was being taken up by w3wp.exe
I found this post here:
http://geekswithblogs.net/michaelstephenson/archive/2010/05/07/139717.aspx
which recommended the following:
Make sure you set the windows service for NserviceBus Generic Host to the right credentials
Make sure you have the queue set with the right permissions
Make sure you turn on the right logging configuration in NServiceBus
So I figured the issue was something related to permissions, but even after trying to set the permissions correctly (I thought) I still wasn't able to resolve the issue.
If you allow NServiceBus to create its own queues, then it will create them with the correct permissions it needs.
The problem comes in when you set up a web application, and then the queues are created, and then the identity the application runs under changes. Then you get exactly this problem. NServiceBus tries to check the queue for a message, it does not have access to do so, so it immediately retries over and over, and you spike the processor.
The fix: Delete the queue. Restart the web application. NServiceBus takes over.
Edit: As noted in the comments, NServiceBus 3.x doesn't invoke the installers by default, which means queues are not automatically created in production unless you ask it to. See the documentation page on Installers for more detail.
For a web application (or any other situation where you're not using NServiceBus.Host) you can invoke the installers as part of the fluent config. There is a full example in the NServiceBus download, but here is a link to the relevant file on GitHub.
The issue did end up being that the website needed to be granted explicit permissions to the queues.
I found a number of resources online telling me this, but I still had to spend a good amount of time monkeying around with exactly WHICH account needed access... turned out that since my application pools were set to run as ApplicationPoolIdentity, I need to grant the account permissions by adding the following account to the nservicebus queue:
IIS AppPool\{APP POOL NAME}
I granted full access rights, though I'm sure you could refine that a bit if you needed to.
Hopefully, this will help anyone who runs into the same issues.
(This is my first attempt at the "Answer your own question" mechanism so please let me know if I am doing something wrong..)