- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
a month ago
Has anyone been able to successfully discover IBM Integration Bus (formerly WebSphere Message Broker) without the need to be part of the mqm/mqbrkrs group to run "mqsireportproperties" command?
BIP2164E: An error occurred while opening registry file 'Permission denied'. The program cannot proceed, because it cannot read the value in the registry for this key. Contact your IBM App Connect Enterprise administrator. BIP8081E: An error occurred while processing the command. An error occurred while the command was running; the command has cleaned up and ended. Use messages prior to this one to determine the cause of the error. Check for some common problems: Does the user id have the correct authorities (for example a member of the mqbrkrs group)? Is any operating system limit set too low to allow the command to run? Is the environment correctly set up? Correct the problem and retry the command, otherwise, contact your IBM support center.
Thanks,
Ragini
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
Hi @Ragini BG ,
As per my understanding Why This Happens
* The mqsireportproperties command is the main way to get IIB broker configuration during ServiceNow Discovery.
* IBM’s security model requires the command to be run by a user in either:
* mqm group (for MQ queue manager-level access), or
* mqbrkrs group (for broker access)
* If the discovery credential user is not in one of these groups, the command cannot read the internal registry file → hence Permission Denied.
OOB ServiceNow Discovery Behavior
* The WebSphere Message Broker / IBM Integration Bus pattern in ServiceNow executes:
* mqsilist
* mqsireportproperties
* The pattern assumes the credential used has sufficient OS-level permissions.
* There is no OOB bypass for the group membership requirement — the IBM tools themselves enforce it, not ServiceNow.
Possible Solutions
1. Grant Minimum Required Permissions (IBM Recommended)
* Add the ServiceNow discovery credential account to the mqbrkrs group.
* Log out & back in (or restart agent) so group membership takes effect.
* This is the most straightforward OOB-supported fix.
* If security team is concerned, limit permissions in MQ/IIB to read-only commands.
2. Use a Wrapper Script (Custom Pattern Change)
If adding to mqbrkrs is not possible:
1. Create a local script owned by an authorized user (mqbrkrs member) that:
* Runs mqsireportproperties
* Outputs results to a file or stdout
2. Grant the discovery account sudo permission to run this script without password:
discovery_user ALL=(mq_user) NOPASSWD: /opt/ibm/iib-<version>/scripts/report_iib.sh
4. Modify the IIB pattern in ServiceNow to call this script instead of running mqsireportproperties directly.
3. Pre-Staging Output for Discovery (Semi-Manual)
* Schedule a cron job (as mqbrkrs user) to periodically dump broker properties to a known location.
* Have ServiceNow Discovery read the file instead of running the command.
* Only useful for environments where real-time discovery is not required.
4. Pattern Modification + Privileged MID Server
* Use a privileged MID Server service account that already has mqbrkrs access.
* Let the MID Server execute the commands locally and pass results to Discovery.
* Keeps OS-level permissions away from the ServiceNow credential store.
Recommendation
For a supported, OOB-aligned setup:
* Add the Discovery credential account to mqbrkrs group (least privilege that allows mqsireportproperties).
* If security will not allow that, use sudo for a single whitelisted script that wraps the command.
Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
Hi @Ragini BG ,
As per my understanding Why This Happens
* The mqsireportproperties command is the main way to get IIB broker configuration during ServiceNow Discovery.
* IBM’s security model requires the command to be run by a user in either:
* mqm group (for MQ queue manager-level access), or
* mqbrkrs group (for broker access)
* If the discovery credential user is not in one of these groups, the command cannot read the internal registry file → hence Permission Denied.
OOB ServiceNow Discovery Behavior
* The WebSphere Message Broker / IBM Integration Bus pattern in ServiceNow executes:
* mqsilist
* mqsireportproperties
* The pattern assumes the credential used has sufficient OS-level permissions.
* There is no OOB bypass for the group membership requirement — the IBM tools themselves enforce it, not ServiceNow.
Possible Solutions
1. Grant Minimum Required Permissions (IBM Recommended)
* Add the ServiceNow discovery credential account to the mqbrkrs group.
* Log out & back in (or restart agent) so group membership takes effect.
* This is the most straightforward OOB-supported fix.
* If security team is concerned, limit permissions in MQ/IIB to read-only commands.
2. Use a Wrapper Script (Custom Pattern Change)
If adding to mqbrkrs is not possible:
1. Create a local script owned by an authorized user (mqbrkrs member) that:
* Runs mqsireportproperties
* Outputs results to a file or stdout
2. Grant the discovery account sudo permission to run this script without password:
discovery_user ALL=(mq_user) NOPASSWD: /opt/ibm/iib-<version>/scripts/report_iib.sh
4. Modify the IIB pattern in ServiceNow to call this script instead of running mqsireportproperties directly.
3. Pre-Staging Output for Discovery (Semi-Manual)
* Schedule a cron job (as mqbrkrs user) to periodically dump broker properties to a known location.
* Have ServiceNow Discovery read the file instead of running the command.
* Only useful for environments where real-time discovery is not required.
4. Pattern Modification + Privileged MID Server
* Use a privileged MID Server service account that already has mqbrkrs access.
* Let the MID Server execute the commands locally and pass results to Discovery.
* Keeps OS-level permissions away from the ServiceNow credential store.
Recommendation
For a supported, OOB-aligned setup:
* Add the Discovery credential account to mqbrkrs group (least privilege that allows mqsireportproperties).
* If security will not allow that, use sudo for a single whitelisted script that wraps the command.
Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
Hello @AJ-TechTrek,
Thank you for your helpful write up. I'll discuss all the possible approaches you shared with my team and choose the best option for us.
As a fun fact, I raised a HI case asking for support in addition to posting in the community, and they suggested that I refer to your response. 🙂
I'll keep you posted on our final decision.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @Ragini BG ,
Thanks for your feedback — I really enjoyed hearing that fun fact!
Thanks
AJ- TechTrek with AJ