Prerequisites for the IBM MQ Monitoring Agent
Prepare your environment for seamless, secure monitoring with the Nodinite IBM MQ Monitoring Agent. On this page, you will:
- ✅ Discover all software and system requirements for a successful installation
- ✅ Learn the exact firewall and network settings for reliable agent communication
- ✅ Understand the Windows and IBM MQ user rights needed for secure operations
- ✅ Get expert tips to avoid common setup pitfalls and ensure business continuity
This page details everything you need to install and run the Nodinite IBM MQ Monitoring Agent with confidence.
A high-level diagram showing the Nodinite IBM MQ Monitoring Agent communicating with the IBM MQ Queue Manager over TCP.
You can install the agent on-premise using TCP/IP for local network access or in the cloud/off-site using Microsoft Service Bus Relaying (see also the external link for additional information 'Azure Relay FAQs').
Software Requirements
| Product | ||
|---|---|---|
| Windows Server | Windows 2025Windows 2022Windows 2019Windows 2016Windows 2012 R2Windows 2012 | |
| .NET Framework | .NET Framework 4.8 or later New 6.0 | |
| IBM MQ Client | V9.2V9.1v9.0v8.05+v7.5+ | Matching the highest version of queue manager to be monitored |
| MSDTC | Windows roles and features | Configure MSDTC as documented with additional demand on 'XA transactions' being allowed |
If you need IBM MQ Client 9.3 or later, contact our support.
Version 6.0 and later require .NET Framework 4.8 or later.
Version 5.4 and later require .NET Framework 4.6.2 or later.
Versions before 5.4 require .NET Framework 4.5.2 or later.
Note
Version 8.0.4 is NOT recommended due to IBM MQ bugs with temporary queues not being removed by the queue manager. Please upgrade if you are on this version.
What firewall settings are required for the IBM MQ Monitoring Agent?
Where you install the Nodinite IBM MQ Monitoring Agent in relation to the Nodinite Monitoring Service and your IBM MQ Queue Managers determines your firewall configuration. The following illustration shows the agent installed on its own server.
Network diagram showing communication between the Nodinite Monitoring Service, IBM MQ Monitoring Agent, and IBM MQ Queue Manager.
1. Between the IBM MQ Monitoring Agent and IBM MQ Queue Managers
The following section details firewall requirements organized by service. Two types of servers participate:
- Agent Server - Where the Nodinite IBM MQ Monitoring Agent is installed
- IBM MQ Server - IBM MQ Queue Manager being monitored
IBM MQ Connection (Agent → IBM MQ Queue Manager)
Required for connecting to and monitoring IBM MQ Queue Managers, queues, topics, channels, and listeners.
| Direction | Source | Destination | Protocol | Port(s) | Purpose | Notes |
|---|---|---|---|---|---|---|
| Outbound | Agent Server | IBM MQ Server | TCP | 1414 | IBM MQ Listener | Default port for MQ channel listener. May be overridden by configuration |
| Inbound | IBM MQ Server | Agent Server | TCP | 1414 | Response traffic | Automatically allowed by stateful firewall inspection |
Tip
SSL/TLS Configuration: If using SSL/TLS for secure MQ connections, additional ports and certificates may be required. Review Configuring TLS security for IBM MQ for complete SSL configuration details.
Tip
Custom Listener Ports: Queue Managers may use custom listener ports instead of the default 1414. Verify the listener port configuration for each Queue Manager being monitored and adjust firewall rules accordingly.
2. Between the Monitoring Service and the Nodinite IBM MQ Monitoring Agent
Allow the following ports on the Windows server where the agent runs:
| Port | Name | Inbound | Outbound | TCP | UDP | Nodinite Version | Comment |
|---|---|---|---|---|---|---|---|
| 53 | DNS | All | The Agent needs to know where your other servers/services are (can sometimes optionally be solved using entries in the local hosts file) |
And further with 'Option 1' or 'Option 2' as documented next:
Option 1a (Nodinite v7 - IIS hosted on local network)
| Port | Name | Inbound | Outbound | TCP | UDP | Nodinite Version | Comment |
|---|---|---|---|---|---|---|---|
| Custom | HTTP/HTTPS | v7 | Agent IIS site port (configured during installation in the Portal). Only required if agent is on a remote IIS server |
Note
Nodinite v7 IIS Hosting: When agents are hosted in IIS on the same server as the Nodinite application (typical installation), firewall rules are not required between the Monitoring Service and the agent. The custom port is assigned during installation via the Nodinite Portal and only needs to be opened if the agent is hosted on a remote IIS Windows Server.
Option 1b (Nodinite v6 and earlier - Windows Service on local network)
| Port | Name | Inbound | Outbound | TCP | UDP | Nodinite Version | Comment |
|---|---|---|---|---|---|---|---|
| 8000 | RPC | v6 and earlier | Communication is initiated by the Monitoring Service. Only used with legacy MSI installer on remote Windows servers |
Note
Nodinite v6 Legacy: Port 8000 is only used when agents have default installations on remote Windows servers using the legacy MSI installer. This port is not required for Nodinite v7 IIS-hosted agents.
Option 2 (Cloud/Hybrid - All versions)
Use Service Bus Relayed connections when Nodinite and the agent are on different networks.
Nodinite uses the same principle as the On-Premise data gateway. See 'Adjust communication settings for the on-premises data gateway'.
| Port | Name | Inbound | Outbound | TCP | UDP | Nodinite Version | Comment |
|---|---|---|---|---|---|---|---|
| 443 | HTTPS | All | Secure outbound traffic | ||||
| 5671, 5672 | Secure AMQP | All | |||||
| 9350 - 9354 | Net.TCP | All |
Note
DNS Resolution: All servers (Agent Server and IBM MQ Servers) require outbound access to DNS on TCP/UDP port 53 for name resolution. This is already listed in section 2 and applies universally. You can optionally solve this using entries in the local
hostsfile on each server.
Important
Stateful Firewalls: Most modern Windows Firewall implementations are stateful, meaning inbound response traffic for established outbound connections is automatically allowed. The inbound rules listed above are primarily for reference and troubleshooting scenarios where stateful inspection may be disabled or restricted.
What Windows User Rights does the IBM MQ Monitoring Agent require?
The agent installs as a Windows Service—usually on the Nodinite application server. Virtual machines are supported.
- Use a local named account or domain account (preferred).
- Grant access and run-time rights.
- Follow the 'How to set logon as a Windows service right' user guide for detailed instructions.
What IBM MQ User Rights does the IBM MQ Monitoring Agent require?
For each IBM MQ Queue Manager to monitor, the configured account must have at least read rights. Some operations require additional rights for changing state, consuming messages, or purging queues.
You can configure which user account to use for each IBM MQ Queue Manager. See the Configuration user guide for more information.
- Member of the MQM user group (local or domain group where IBM MQ Queue manager is installed) OR
- Least privileges - See the sections below for detailed explanations and optimized permission sets
Understanding IBM MQ Permissions
Before configuring permissions, it's important to understand what each permission flag does:
| Permission Flag | What It Does | Used For |
|---|---|---|
+connect |
Connect to the queue manager | Required - Must be able to connect to perform any monitoring or management |
+dsp |
Display object properties | Required - Query object state, configuration, and status |
+inq |
Inquire object attributes | Required - Read detailed metrics (message count, age, inhibit status) |
+put |
Put messages to a queue | Remote Actions - Send PCF (Programmable Command Format) commands to IBM MQ |
+get |
Get messages from a queue | Remote Actions - Retrieve messages for download, purge, or dynamic queue responses |
IBM MQ Object Types:
qmgr- Queue Manager (the IBM MQ instance itself)q- Queues (where messages are stored)channel- Channels (communication paths)clntconn- Client Connection Channels (remote client connections)listener- Listeners (network listeners for incoming connections)topic- Topics (publish/subscribe messaging)process- Processes (application definitions)namelist- Namelists (lists of object names)authinfo- Authentication Information (security configurations)service- Services (Windows services or Unix processes)comminfo- Communication Information (multicast configuration)
Wildcard Pattern:
"**"- Matches all objects of the specified type
IBM MQ Permission Requirements Explained
The table below explains what each permission command does and whether it's required for Nodinite monitoring and management:
| Command | Object Type | Permissions | What It Does | Required For | Necessary? |
|---|---|---|---|---|---|
setmqaut -m QM1 -t qmgr -p "mqadmin" +connect +inq +dsp |
Queue Manager | Connect, Inquire, Display | Connect to the queue manager and query its properties (availability, connectivity status) | ✅ All monitoring - Required for queue manager monitoring | ✅ REQUIRED |
setmqaut -m QM1 -n "**" -t q -p "mqadmin" +dsp +inq |
All Queues | Display, Inquire | Query queue state and metrics (message count, age, get/put inhibit status, quota, dead letter) | ✅ Queue Monitoring - If checkbox enabled | ✅ If monitoring queues |
setmqaut -m QM1 -n "**" -t topic -p "mqadmin" +dsp |
All Topics | Display | Query topic properties and subscriptions for publish/subscribe messaging - Topics are automatically discovered and monitored | ✅ Topic Monitoring - If checkbox enabled | ✅ If monitoring topics |
setmqaut -m QM1 -n "**" -t channel -p "mqadmin" +dsp |
All Channels | Display | Query channel state (started/stopped) and connection status | ✅ Channel Monitoring - If checkbox enabled | ✅ If monitoring channels |
setmqaut -m QM1 -n "**" -t process -p "mqadmin" +dsp |
All Processes | Display | Query process definitions (application configurations) | ❌ Not monitored - No process monitoring features documented | ❌ Not required |
setmqaut -m QM1 -n "**" -t namelist -p "mqadmin" +dsp |
All Namelists | Display | Query namelists (lists of object names for grouping) | ❌ Not monitored - No namelist monitoring features documented | ❌ Not required |
setmqaut -m QM1 -n "**" -t authinfo -p "mqadmin" +dsp |
All Auth Info | Display | Query authentication configuration (LDAP, OS, etc.) | ❌ Not monitored - No authinfo monitoring features documented | ❌ Not required |
setmqaut -m QM1 -n "**" -t clntconn -p "mqadmin" +dsp |
All Client Connections | Display | Query client connection channels (remote client access) | ✅ Channel Monitoring - Client connections are monitored as channel type | ✅ If monitoring channels |
setmqaut -m QM1 -n "**" -t listener -p "mqadmin" +dsp |
All Listeners | Display | Query listener state (started/stopped) for network listeners | ✅ Listener Monitoring - If checkbox enabled | ✅ If monitoring listeners |
setmqaut -m QM1 -n "**" -t service -p "mqadmin" +dsp |
All Services | Display | Query service definitions (Windows services/Unix processes) | ❌ Not monitored - No service monitoring features documented | ❌ Not required |
setmqaut -m QM1 -n "**" -t comminfo -p "mqadmin" +dsp |
All Comm Info | Display | Query multicast configuration for publish/subscribe | ❌ Not monitored - No comminfo monitoring features documented | ❌ Not required |
setmqaut -m QM1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -p "mqadmin" +dsp +inq +put |
Admin Command Queue | Display, Inquire, Put | Send PCF commands to IBM MQ for querying objects and executing remote actions | ✅ All monitoring & Remote Actions - Used to send commands to IBM MQ | ✅ REQUIRED |
setmqaut -m QM1 -n "SYSTEM.DEFAULT.MODEL.QUEUE" -t q -p "mqadmin" +dsp +get +inq |
Model Queue | Display, Get, Inquire | Create dynamic temporary queues for command responses from IBM MQ | ✅ All monitoring & Remote Actions - Used to receive responses from IBM MQ | ✅ REQUIRED |
Note
About PCF Commands and Security:
The two commands above (
SYSTEM.ADMIN.COMMAND.QUEUEandSYSTEM.DEFAULT.MODEL.QUEUE) use PCF (Programmable Command Format), which is IBM's official administrative interface used by all monitoring tools (IBM MQ Explorer, Console, REST API, and Nodinite).Key Points:
- ✅ Object-level security is enforced - Access to
SYSTEM.ADMIN.COMMAND.QUEUEdoes NOT bypass permissions. IBM MQ still checks permissions on queues, topics, channels, and listeners.- ✅ Standard IBM interface - This is the only way to programmatically query IBM MQ. There is no alternative.
- ✅ Temporary queues are safe - Used only for command responses (metadata, not business messages). Should be auto-deleted by IBM MQ.
- ⚠️ IBM MQ 8.0.4 bug - Temporary queues may not be deleted properly. Upgrade to 8.0.5+ or 9.x to resolve.
For security-conscious customers: If you want to limit what Nodinite can query, restrict the other permissions (remove
+dsp +inqfrom object types you don't want monitored). The PCF commands will respect these restrictions.For detailed explanation: See FAQ - About PCF Commands and Security for complete information about PCF command flow, temporary queues, security architecture, and comparison with other monitoring tools.
Remote Actions Requiring Additional Permissions:
The following remote actions available in Managing IBM MQ.md may require additional permissions beyond monitoring:
| Remote Action | Additional Permissions Required | Command |
|---|---|---|
| Purge Queue | +clr (clear) permission on target queues |
setmqaut -m QM1 -n "**" -t q -p "mqadmin" +clr |
| Remove Message | +get permission on target queues |
setmqaut -m QM1 -n "**" -t q -p "mqadmin" +get |
| Download Message | +get permission on target queues |
setmqaut -m QM1 -n "**" -t q -p "mqadmin" +get |
| Edit Thresholds | No additional permissions - configuration only | N/A - Stored in Nodinite database |
Note
If you plan to use Purge Queue, Remove Message, or Download Message remote actions, add
+clrand+getpermissions to the relevant queues.
Optimized Permission Sets
Based on your monitoring configuration checkboxes (Queues, Topics, Channels, Listeners), choose the appropriate permission set below:
Base Permissions (Always Required)
These permissions are always required for any Nodinite monitoring:
# Connect to Queue Manager - REQUIRED for all monitoring
setmqaut -m QM1 -t qmgr -p "mqadmin" +connect +inq +dsp
# Admin Command Queue - REQUIRED to send PCF commands to IBM MQ
setmqaut -m QM1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -p "mqadmin" +dsp +inq +put
# Model Queue - REQUIRED to receive responses from IBM MQ via dynamic queues
setmqaut -m QM1 -n "SYSTEM.DEFAULT.MODEL.QUEUE" -t q -p "mqadmin" +dsp +get +inq
Option A: Monitor Everything (Recommended)
Use this if: All checkboxes enabled (Queues + Topics + Channels + Listeners)
# Base Permissions (always required)
setmqaut -m QM1 -t qmgr -p "mqadmin" +connect +inq +dsp
setmqaut -m QM1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -p "mqadmin" +dsp +inq +put
setmqaut -m QM1 -n "SYSTEM.DEFAULT.MODEL.QUEUE" -t q -p "mqadmin" +dsp +get +inq
# Queue Monitoring (state, age, count, quota, dead letter)
setmqaut -m QM1 -n "**" -t q -p "mqadmin" +dsp +inq
# Topic Monitoring (subscription status - automatically discovered)
setmqaut -m QM1 -n "**" -t topic -p "mqadmin" +dsp
# Channel Monitoring (state, includes client connections)
setmqaut -m QM1 -n "**" -t channel -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t clntconn -p "mqadmin" +dsp
# Listener Monitoring (state)
setmqaut -m QM1 -n "**" -t listener -p "mqadmin" +dsp
Option B: Monitor Queues Only
Use this if: Only Queues checkbox enabled
# Base Permissions (always required)
setmqaut -m QM1 -t qmgr -p "mqadmin" +connect +inq +dsp
setmqaut -m QM1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -p "mqadmin" +dsp +inq +put
setmqaut -m QM1 -n "SYSTEM.DEFAULT.MODEL.QUEUE" -t q -p "mqadmin" +dsp +get +inq
# Queue Monitoring ONLY
setmqaut -m QM1 -n "**" -t q -p "mqadmin" +dsp +inq
Option B2: Monitor Topics Only
Use this if: Only Topics checkbox enabled
# Base Permissions (always required)
setmqaut -m QM1 -t qmgr -p "mqadmin" +connect +inq +dsp
setmqaut -m QM1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -p "mqadmin" +dsp +inq +put
setmqaut -m QM1 -n "SYSTEM.DEFAULT.MODEL.QUEUE" -t q -p "mqadmin" +dsp +get +inq
# Topic Monitoring ONLY (automatically discovers all topics)
setmqaut -m QM1 -n "**" -t topic -p "mqadmin" +dsp
Option C: Monitor Channels Only
Use this if: Only Channels checkbox enabled
# Base Permissions (always required)
setmqaut -m QM1 -t qmgr -p "mqadmin" +connect +inq +dsp
setmqaut -m QM1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -p "mqadmin" +dsp +inq +put
setmqaut -m QM1 -n "SYSTEM.DEFAULT.MODEL.QUEUE" -t q -p "mqadmin" +dsp +get +inq
# Channel Monitoring ONLY (includes client connections)
setmqaut -m QM1 -n "**" -t channel -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t clntconn -p "mqadmin" +dsp
Option D: Monitor Listeners Only
Use this if: Only Listeners checkbox enabled
# Base Permissions (always required)
setmqaut -m QM1 -t qmgr -p "mqadmin" +connect +inq +dsp
setmqaut -m QM1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -p "mqadmin" +dsp +inq +put
setmqaut -m QM1 -n "SYSTEM.DEFAULT.MODEL.QUEUE" -t q -p "mqadmin" +dsp +get +inq
# Listener Monitoring ONLY
setmqaut -m QM1 -n "**" -t listener -p "mqadmin" +dsp
Option E: Full Monitoring + Remote Actions
Use this if: You want monitoring AND remote actions (Purge Queue, Remove Message, Download Message)
# Base Permissions (always required)
setmqaut -m QM1 -t qmgr -p "mqadmin" +connect +inq +dsp
setmqaut -m QM1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -p "mqadmin" +dsp +inq +put
setmqaut -m QM1 -n "SYSTEM.DEFAULT.MODEL.QUEUE" -t q -p "mqadmin" +dsp +get +inq
# All Monitoring (queues, topics, channels, listeners)
setmqaut -m QM1 -n "**" -t q -p "mqadmin" +dsp +inq
setmqaut -m QM1 -n "**" -t topic -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t channel -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t clntconn -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t listener -p "mqadmin" +dsp
# Remote Actions (purge, remove, download messages)
setmqaut -m QM1 -n "**" -t q -p "mqadmin" +get +clr
Tip
Security Best Practice: Start with Option A (Monitor Everything) for initial setup. Once you understand your monitoring needs, switch to a more restrictive option based on your checkbox configuration.
Legacy Permission Commands (For Reference)
The following commands were used in previous versions. They grant permissions to object types that some environments may not need based on monitoring configuration.
These commands are kept for backward compatibility but are not recommended for new installations:
setmqaut -m QM1 -t qmgr -p "mqadmin" +connect +inq +dsp
setmqaut -m QM1 -n "**" -t q -p "mqadmin" +dsp +inq
setmqaut -m QM1 -n "**" -t topic -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t channel -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t process -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t namelist -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t authinfo -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t clntconn -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t listener -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t service -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t comminfo -p "mqadmin" +dsp
setmqaut -m QM1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -p "mqadmin" +dsp +inq +put
setmqaut -m QM1 -n "SYSTEM.DEFAULT.MODEL.QUEUE" -t q -p "mqadmin" +dsp +get +inq
Warning
These legacy commands grant unnecessary permissions to object types that may not be monitored in your environment (processes, namelists, authinfo, services, comminfo). Use the Optimized Permission Sets above instead to follow the principle of least privilege and only grant permissions for the monitoring features you have enabled.
Troubleshooting MQRC_NOT_AUTHORIZED
When you log in to the IBM MQ Broker, the Nodinite IBM MQ Monitoring Agent may receive an MQRC_NOT_AUTHORIZED error. You will see this error in the Monitor Views and in the rolling Diagnostics file.
Please review IBM's documentation 2035 MQRC_NOT_AUTHORIZED when connecting to IBM MQ from WebSphere Application Server to find and apply the proper solution for your environment.
Frequently asked questions
Find more solutions and FAQs for the Nodinite IBM MQ Monitoring Agent in the Troubleshooting user guide.
Next Step
Add or manage a Monitoring Agent Configuration
Installing the IBM MQ Monitoring Agent