.net application send and receive directly to Remote Queue Manager - vb.net

i'm trying to connect my VB.net application to Remote Queue Manager.
but keep getting the followig Erorr: MQRC_Q_MGR_NAME_ERROR. can anyone tell me what i'm doing wrong?
here is the code i'm using:
Dim mqQMgr As MQQueueManager = Nothing
Dim props As New Hashtable()
props.Add(MQC.HOST_NAME_PROPERTY, "192.168.28.191")
props.Add(MQC.CHANNEL_PROPERTY, "SYSTEM.ADMIN.SVRCONN")
props.Add(MQC.USER_ID_PROPERTY, "AQ")
props.Add(MQC.PORT_PROPERTY, 1313)
props.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_BINDINGS)
mqQMgr = New MQQueueManager("QMSEPAM", props)
i also tried differentconnection method (MQC.TRANSPORT_MQSERIES_CLIENT) and i get the following error:
"MQRC_NOT_AUTHORIZED"
Thanks in advance.

You need to set MQC.TRANSPORT_PROPERTY property to MQC.TRANSPORT_MQSERIES_MANAGED or MQC.TRANSPORT_MQSERIES_CLIENT for connecting through TCP/IP socket to a queue manager that is running on a remote machine or on the same machine as your application . The MQC.TRANSPORT_MQSERIES_BINDINGS should be used only when the queue manager is running on the same machine as your application in which case your application would communicate with queue manager using shared memory.
The MQRC_NOT_AUTHORIZED (2035) is thrown if the user with which your application is attempting to connect to a remote queue manager does not have authority. There are multiple ways of providing access to queue manager, talk to your IBM MQ Administrator to provide you the required authority. Take a look at this link. BTW what version of MQ are you using?
Update: Two points
1) Is user AQ same as logged in user of the machine where the .NET application is running? MQ .NET v7.5 sends the logged in user id to queue manager for authorization unless you are using a security exit. If you are not using any security exit then the logged in user id must exist on remote machine and has authorizations to connect.
2) Do not add user to mqm as users in that group are blocked from connecting to queue manager by the Channel Authentication feature
There are couple of posts in SO that you can read:
WebSphere MQ v7.1 Security User Credentials
MQRC_NOT_AUTHORIZED error while connecting to Websphere MQ 7.1
Finally if you are just testing out your application and do not really need user id authorization, then you can disable channel authentication by running the below runmqsc command.
ALTER QMGR CHLAUTH (DISABLED)

Related

How can I use RabbitMQ user access management in iAPC?

I'm setting up a new RabbitMQ service in iAPC (Swisscom app cloud) and I need to control the user access of the different producer/consumer application.
My access control requirement:
Application A can only write to queue X.
Application B can only read from queue X.
RabbitMQ provides usually user management functionalities. However, the whole user management in the admin section, RabbitMQ management GUI, is not available.
What solution does exist in iAPC to manage read/write permissions for different applications which have an app binding?
Is it even possible to setup different users?
I believe there is no way to add additional users in these managed RabbitMQ service deployments provided by Swisscom. This is quite similar across all of the available shared services (e.g. ElasticSearch or MariaDB) which come with a preset of defined users. I assume that this is true because those are actually shared services (as opposed to dedicated ones), where there may be authentication / security concerns if you are allowed to administer existing users.
For anyone who is interested the way to access your RabbitMQ CloudFoundry service admin interface via the provided environment parameters to see what is possible:
bind your RabbitMQ service to a running app instance (e.g. MY-APP)
look at the environment of that app with cf env MY-APP
tunnel the RabbitMQ management port to your localhost:
cf ssh -N -T -L 15000:rabbitmq.service.consul:15672 MY-APP
open a webbrowser and look at http://localhost:15000
Use the Username and Password you found in step (2) under rabbitmqent > credentials > management to log in

Mule ESB WebsphereMQ connection with JMS connector works in Mule Design, but not standalone server

I am new to Mule and followed this blog to create a "websphere-mq connector" through the jms connector. I am using the community edition.
In order to connect to the websphere mq server, I must run the application under a specific Windows username. Running the mule application in Mule Design under the specific username, I am able to connect and receive messages. However, I am unable to connect to the websphere mq server through the standalone application running on a windows server. I changed the user on the service that is running mule to the specific user but am unable to get authorization to the websphere mq server.
Any additional insight would be much appreciated.
I would suggest reviewing the "Getting going without turning off security" article for an introduction to MQ security. This might help get the MQ system correctly configured.
The stand alone application runs the Tanuki Software wrapper as the user assigned to the environment variable %USERNAME% in windows. Even though I updated the user in the Mule service to run as the approved user, the wrapper will take the environment variable.
To solve the problem, I updated the wrapper.conf file to include the following:
set.USERNAME=<approvedUsername>
the environment variable %USERNAME% is now set to the approved username, in which mule will allow the JMS connector to the authenticate with the correct username.

What are the default MSMQ private queue permissions on Windows 2008 Server

I have installed MSMQ on a publicly hosted standalone Windows 2008 Server (workgroup), already running IIS 7.0 and a number of .NET websites.
I've created a private transactional queue named 'Requests' as per the screen shot below.
Without changing any permissions or settings, is this private queue available remotely ? How can I verify who can and can't read/send messages to this queue.
Are there any tools or scripts I can run using PowerShell that are available to attempt to connect to a remote private queue ?
Private queues are queues that are not published in Active Directory and are displayed only on the local computer that contains them.
Read this: http://technet.microsoft.com/en-us/library/cc776346(v=ws.10).aspx
This means you won't be able to use powershell to acess a remote private queue - you will have to make that queue public.
Then see this page for details on accessing the queue: http://technet.microsoft.com/en-us/library/hh405007(v=vs.85).aspx

WCF error 0xc00e0069 (MQ_ERROR_REMOTE_MACHINE_NOT_AVAILABLE)

I have a WPF app that uses WCF (duplex netMsmqBinding) to talk to a self-hosted service app in our domain.
I'm now trying to move this WPF app to the big wide world out there, to talk to the WCF service over the internet (well, make them talk to each other).
I've installed MSMQ and created the services on both, and checked queue and firewall permissions. Based on the reading I've found, what I needed to do then is:
1) Enable MSMQ's HTTP addon.
2) specify the binding's useActiveDirectory=false and queueTransferProtocol="Srmp" to ensure that it uses DIRECT to find the private queue.
However I did that and the WPF app receives the error
An error occurred while opening the queue:Unrecognized error
-1072824215 (0xc00e0069). The message cannot be sent or received from the queue. Ensure that MSMQ is installed and running. Also ensure that
the queue is available to open with the required access mode and
authorization.
Which translates to MQ_ERROR_REMOTE_MACHINE_NOT_AVAILABLE.
I can browse to the remote server ok, and the rest services work fine, so I must be missing something with HTTP or the fact that it's self hosting. Any ideas?
MSMQ over HTTP is a push technology (client -> web server).
You cannot open a remote queue and pull messages from it.

MQ With WLS Foreign Server

I am facing two issues when i try to connect to MQ which is deployed on a Remote Server from Weblogic Server(WLS) by creating a Foreign Server.
1. When I try to connect to MQ Queuemanager in Bindings mode(after importing the .Bindings file) i keep getting the below error in WLS console:
java.lang.UnsatisfiedLinkError: no mqjbnd05 in java.library.path
If i Switch the Transport to Client i keep getting:
JMSWMQ0018: Failed to connect to queue manager '' with connection mode 'Client' and host name 'localhost'. Check the queue manager is started and if running in client mode, check there is a listener running. Please see the linked exception for more information.
Has anyone seen this, and are there any performance implications which dictate the use of client over bindings and vice versa?
TIA
Finally i was able to resolve this, i had to recreate the .bindings file in the client mode, with changes to the IVTsetup.bat which is most likely present in
C:\Program Files\IBM\WebSphere MQ\java\bin, I had to run this
def qcf(psQCF) TRANSPORT(CLIENT) HOST(SMEKA) PORT(1415) CHANNEL(ps_SRV_CHANNEL) QMGR(psQM)
to generate the .bindings file.
Refer to this link for more details:
http://publib.boulder.ibm.com/infocenter/wbihelp/v6rxmx/index.jsp?topic=/com.ibm.wbia_adapters.doc/doc/peoplesoft/peopleso103.htm
Where the question states that I try to connect to MQ which is deployed on a Remote Server from Weblogic Server I assume this means that WLS and WMQ are on two different hosts. If that is the case, then a bindings mode connection (which relies on shared memory segments) won't work.
The client mode connection appears to be using a CF that is pointed to localhost rather than the IP or hostname of the WMQ server. This would work for an application on the same host as the queue manager but not when the app and QMgr are on separate servers.
As far as choosing between client and bindings mode, the answer is that if the QMgr is local use bindings. This provides highest reliability, best performance and XA transactionality. When using client mode, two-phase XA commit is not supported without the Extended Transactional Client. Per the JMS specification, there is an ambiguity that can exist if an app loses the connection during a COMMIT call. Depending on how the app handles this it's possible to end up with duplicate messages. (The JMS spec refers to these as "functionally duplicate.") This ambiguity is much less likely to occur with a bindings mode connection since there is no network latency and not even any traversal of the IP stack or interface. So use bindings mode where possible.
UPDATE:
Removed note about Extended Transactional Client being a chargeable component. As of April 24th, XTC is free of charge for all versions of WMQ on all platforms.