| Author |
Message
|
| robertr |
 Posted: Tue Feb 17, 2009 6:39 am Post subject: 2035 error with mqsideploy command |
 |
|
Novice
Joined: 05 Jan 2005
Posts: 19
|
Hi,
I believe I may have a machine specific issue that I need help to identify and resolve.
I can connect to solaris broker (BRK1) from my local machine with a domain account, using a svrconn channel specified in the param file and the mqsideploy command works successfully.
When I log on to the windows deployment server as the same user (user1) and execute the mqsideploy command, with the same param files, I get a 2035 error saying user not authorised.
On the solaris broker I have executed the following:
mqsicreateaclentry CFG1 -u user1 -a -x F -p
mqsicreateaclentry CFG1 -u user1 -a -x F -b BRK1
The svrconn channel has 'mqm' specified as the value for the MCA User Id as i initially thought the error relaed to a security exit i was using but again this will not facilitate connection from the deployment machine. (Windows server 2003 - VM slice)
Does anyone have any idea why the mqsideploy command below works locally but not on the server?
(Incidently I can deploy and connect without issue when using the same .configmgr file from the toolkit on the deployment machine.)
mqsideploy -n C:\Install/BRK1.configmgr -b BRK1 -e EG1 -a C:\Install/JTEXT.bar -w 300 |
|
| Back to top |
|
 |
| ramires |
| Posted: Tue Feb 17, 2009 6:48 am Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
Hi,
you can look inside BRK1.configmgr to see the connection parameters, to check what is being used.
Regards
joao |
|
| Back to top |
|
|
| robertr |
| Posted: Tue Feb 17, 2009 6:53 am Post subject: |
|
|
Novice
Joined: 05 Jan 2005
Posts: 19
|
Hi,
I have looked inside and confirmed all details are correct.
The svrconn channel i want to use is specifed and along with the correct QM, port and host details. If i use the SYSTEM.BRK.CONFIG.SVRCONN channel the deploy works successfully but I would prefer to use a user defined channel.
The file works on one machine and does not on another even though the same user is logged on to both and that user has all necessary permissions to connect to the broker and config mgr.
Regards,
Rob |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 17, 2009 6:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| robertr wrote: |
| I would prefer to use a user defined channel. |
Why? What's the requirement here?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| robertr |
| Posted: Tue Feb 17, 2009 7:02 am Post subject: |
|
|
Novice
Joined: 05 Jan 2005
Posts: 19
|
I would not consider using a system defined channel for deployments good practice and the security exit i want to use may have internal implications on the broker/queue manager relationship.
I would prefer a user defined channel to maximise security and remove any potential dependencies by using the system channels, However, regardless of which channel, system or user, the issue still exists. 
Once the acl entries have been set and a mca user id set in the svrconn channel I would not have envisaged any issue while deploying. Since moving to this new VM slice, i cannot deploy and cannot figure out why.
Any help will be greatly appreciated. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 17, 2009 7:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| robertr wrote: |
| I would not consider using a system defined channel for deployments good practice and the security exit i want to use may have internal implications on the broker/queue manager relationship. |
Accepting this may be a little off topic (but only a little) would you mind elaborating a little? Particually on how you've determined the "not good practice" and the requirement for a security exit in this scenario?
Also what the security exit is checking, and against what?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| robertr |
| Posted: Tue Feb 17, 2009 7:12 am Post subject: |
|
|
Novice
Joined: 05 Jan 2005
Posts: 19
|
Vitor,
I agree this is off topic and would prefer to concentrate on the issue at hand. Do you have any suggesstions on why the 2035 error arises?
Regards,
Rob |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 17, 2009 7:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| robertr wrote: |
| Do you have any suggesstions on why the 2035 error arises? |
Only theories I'd be embarassed to share.
I apologise if you find my curiosity irritating. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ramires |
| Posted: Tue Feb 17, 2009 7:26 am Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
I also prefer not using the default channel. With the same channel name I've 3 environments, with 3 different ip's, different ports and same channel name. With different names for the SVRCONN channnels. lets say:
SYSTEM.BRK.CONFIG.DEV
SYSTEM.BRK.CONFIG.QUA
SYSTEM.BRK.CONFIG.PRD
it's one more level for differentiation.
Regarding the 2035, check upper/lower case id?
Regards
joao |
|
| Back to top |
|
|
| robertr |
| Posted: Tue Feb 17, 2009 7:28 am Post subject: |
|
|
Novice
Joined: 05 Jan 2005
Posts: 19
|
No worries Vitor - just under pressure to get issue resolved!
May need to contact IBM as the configuration is "by the book". |
|
| Back to top |
|
|
| robertr |
| Posted: Tue Feb 17, 2009 7:32 am Post subject: |
|
|
Novice
Joined: 05 Jan 2005
Posts: 19
|
Checked the casing and it is correct.
Have been using the same channel from both machines and it works on one and not in another.  |
|
| Back to top |
|
|
| ramires |
| Posted: Tue Feb 17, 2009 8:08 am Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
Enable Authority Event for the queue manager, retry the 2035 error, and then check SYSTEM.ADMIN.QMGR.EVENT, a message related to the 2035 should be there.
Regards
joao |
|
| Back to top |
|
|
| robertr |
| Posted: Tue Feb 17, 2009 8:30 am Post subject: |
|
|
Novice
Joined: 05 Jan 2005
Posts: 19
|
Thanks Jaoa...
This is the error on screen...
BIP1044I: Connecting to the Configuration Manager's queue manager...
BIP1046E: Unable to connect with the Configuration Manager's queue manager (User user1@AD is not authorized to connect to queue manager 'QM1' (MQ reason code 2035 while trying to connect)).
The utility encountered a problem while attempting to connect to the Configuration Manager's queue manager to put a message to its request queue.
Ensure that the correct connection parameters have been supplied to the utility. Also ensure that the Configuration Manager's queue manager is running and that the current user is able to put messages to its SYSTEM.BROKER.CONFIG.QUEUE. If this error text includes an MQ reason code, look up the meaning behind the error in the Application Programming Reference guide and proceed as appropriate.
The message on the queue states...
MQRQ_CONN_NOT_AUTHORIZED
It would appear it is not picking up the svrconn channel MCA User id specified in the param file.
Any ideas why this would arise? |
|
| Back to top |
|
|
| dk27 |
| Posted: Tue Feb 17, 2009 9:07 am Post subject: |
|
|
Acolyte
Joined: 28 Apr 2008
Posts: 51
|
| You can check the groups that domain user id is part of on both machines and then identify differences if any on the machine.. |
|
| Back to top |
|
|
| robertr |
| Posted: Tue Feb 17, 2009 9:11 am Post subject: |
|
|
Novice
Joined: 05 Jan 2005
Posts: 19
|
The user is a member of the mqm and mqbrkrs groups on the windows deployment machine.
The user is not a member of any group on the solaris broker machine, not even a user on that machine. I believe this is ok once the acl entry has been made and the svrconn channel has an mca user id specified that is a member of the mqm group on the Solaris box - which it is.
The funny thing is that I can connect locally (XP) with this configuration but cannot from the windows server? |
|
| Back to top |
|
|
|
|
