Prerequisites for the Nodinite Message Queueing Monitoring Agent
Tip
This page describes the prerequisites for installing and running the Nodinite Message Queueing Monitoring Agent.
Unlock seamless monitoring of your enterprise message queues with the Nodinite Message Queueing Monitoring Agent. This page guides you through all prerequisites to ensure a smooth installation and optimal performance for ActiveMQ, MSMQ, and Azure Service Bus environments.
✅ Effortless integration with leading message queue platforms
✅ Centralized, real-time monitoring for on-premise and cloud deployments
✅ Enhanced security and compliance with granular user rights
✅ Scalable architecture for enterprise-grade reliability
Architecture overview: The Nodinite Message Queueing Monitoring Agent connects to multiple queueing technologies for unified monitoring.
Instances of this agent can be installed on-premise using TCP/IP for local network access and/or in the cloud/off-site using Service Bus Relaying (see also the external link for additional information 'Azure Relay FAQs').
We recommend that you keep this agent close to Nodinite Core Services. This documentation covers local network setup (usually on the Nodinite application server)
Software Requirements
The Message Queueing Monitoring Agent is a Windows Service, typically installed on the Nodinite application server for best performance and security.
Versions 7.0.4 and later require .NET 10 Hosting Bundle.
| Product | Version/Edition |
|---|---|
| Windows Server | Windows 2025 Windows 2022 Windows 2019 Windows 2016 Windows 2012 R2 Windows 2012 |
| .NET 10 Hosting Bundle New 7.0.4 | Required for v7.0.4 and later. Download from Microsoft |
| ActiveMQ | 5.14.0 and later |
MSMQ
|
For supported Windows versions. NOTE: Additional roles and features may be required depending on the intended usage |
| Azure Service Bus | Current public (GA) version by Microsoft in Azure |
Versions 6.0 -> 7.0.3 require .NET Framework 4.8 or later.
.NET 10 minimum OS: Windows Server 2012 / 2012 R2.
Versions 5.4 and later require .NET Framework 4.6.2 or later.
Versions before 5.4 require .NET Framework 4.5.2 or later.
What Windows User Rights does the Message Queueing Monitoring Agent require?
The agent installs as a Windows Service—usually on the Nodinite application server or a supported virtual machine.
Service Account Options New 7.0.4
- Group Managed Service Account (gMSA) - Recommended for automated password management. See Configure Group Managed Service Accounts (gMSA) for setup instructions.
- Traditional Account - Use a local named account or, preferably, a domain account.
- Follow the 'How to set logon as a Windows service right' user guide for detailed instructions.
What ActiveMQ User rights does the Message Queueing Monitoring Agent require
Review the Apache ActiveMQ Security guide for best practices on securing your message queues.
What MSMQ User rights does the Message Queueing Monitoring Agent require
For MSMQ, refer to the Securing Messages Using Transport Security user guide for configuration and security recommendations.
What Azure ServiceBus User rights does the Message Queueing Monitoring Agent require
For Azure Service Bus monitoring, this agent uses an App Registration (ClientId/ApplicationId) to connect with the Azure REST API. Configure roles with least privilege as described in AzureApplicationsAccess - Least Privileges.
The Nodinite Message Queueing Monitoring Agent requires the following Azure Roles to be set on the ClientId/ApplicationId used to connect with the Azure REST API:
| Service Name | Permission | Comment |
|---|---|---|
| Service Bus Namespace | Azure Service Bus Data Owner | Allows for full access to Azure Service Bus resources. Set on Subscription, or Resource Group Level |
| Subscription | Reader | Show Details and Match/Validate the Subscription Id with the current configuration. NOTE: This right inherits to all other Resources in selected Subscription |
You can apply these rights on different scopes. For more details, review the Authenticate and authorize an application with Microsoft Entra ID to access Azure Service Bus entities user guide.
Firewall
Where you install the Nodinite Message Queueing Monitoring Agent in relation to the Nodinite Monitoring Service and your message brokers determines your firewall configuration. The diagram shows every host involved, with the agent on its own server; each arrow starts at the side that opens the connection.
Network diagram: the Monitoring Service calls the agent, and the agent connects to each broker you configure. Dashed arrows are optional hops.
Note
When the agent runs on the Core Services Server (the typical installation), you need no firewall rule between the Monitoring Service and the agent.
Between the Monitoring Service and the Message Queueing Monitoring Agent
The Monitoring Service opens every connection; the agent never calls it. On Windows Server, Nodinite v7 hosts the agent as its own IIS web site, on a port you set per environment in the Nodinite Portal (Servers step).
| Direction | Source | Destination | Protocol | Port(s) | Purpose | Notes |
|---|---|---|---|---|---|---|
| Inbound | Core Services Server | Agent Server | TCP (HTTPS/HTTP) | Agent site port | Poll the agent, send configuration, run Remote Actions | v7. No fixed default; use the port set in the Portal. Only when the agent is on a remote server |
| Inbound | Core Services Server | Agent Server | TCP | 8000 | Same, for Windows Service agents | ⚠️ v6 and earlier only (legacy MSI installer on remote servers) |
Option: Service Bus Relaying (cloud or hybrid)
Use Service Bus Relayed connections when Nodinite and the agent are on different networks. Both sides connect outbound to the Azure Relay namespace, so neither server needs an inbound rule. Nodinite uses the same principle as the on-premises data gateway; see 'Adjust communication settings for the on-premises data gateway' and the 'Azure Relay FAQs'.
| Direction | Source | Destination | Protocol | Port(s) | Purpose | Notes |
|---|---|---|---|---|---|---|
| Outbound | Agent Server | Azure Relay (*.servicebus.windows.net) |
TCP | 443 | HTTPS | All versions |
| Outbound | Agent Server | Azure Relay (*.servicebus.windows.net) |
TCP | 5671, 5672 | Secure AMQP | All versions |
| Outbound | Agent Server | Azure Relay (*.servicebus.windows.net) |
TCP | 9350 - 9354 | Net.TCP | All versions |
| Outbound | Core Services Server | Azure Relay (*.servicebus.windows.net) |
TCP | 443, 5671, 5672, 9350 - 9354 | Monitoring Service side of the relay | Same ports as the Agent Server |
Between the Message Queueing Monitoring Agent and ActiveMQ
Required for monitoring ActiveMQ queues and topics.
| Direction | Source | Destination | Protocol | Port(s) | Purpose | Notes |
|---|---|---|---|---|---|---|
| Outbound | Agent Server | Target (ActiveMQ Broker) | TCP | 61616 | ActiveMQ remote connection | Default OpenWire protocol port; use the port in your Connection String |
| Inbound | Target (ActiveMQ Broker) | Agent Server | TCP | 61616 | Response traffic | Automatically allowed by stateful firewall inspection |
Tip
Custom Ports: The ActiveMQ Broker port can be configured in
activemq.xml. Common configurations include port 61616 (OpenWire), 8161 (Web Console), 5672 (AMQP), or custom ports. Adjust firewall rules to match your configuration.
Tip
SSL/TLS: For secure ActiveMQ connections, configure SSL on a custom port (e.g., 61617). Ensure the Agent Server trusts the ActiveMQ SSL certificate. See Apache ActiveMQ Security guide for details.
Between the Message Queueing Monitoring Agent and MSMQ
Required for monitoring MSMQ queues on the servers you configure.
| Direction | Source | Destination | Protocol | Port(s) | Purpose | Notes |
|---|---|---|---|---|---|---|
| Outbound | Agent Server | Target (MSMQ Server) | TCP | 1801 | MSMQ TCP connection | Primary MSMQ port |
| Outbound | Agent Server | Target (MSMQ Server) | UDP | 1801 | MSMQ UDP connection | Alternative MSMQ protocol |
| Outbound | Agent Server | Target (MSMQ Server) | TCP/UDP | 135 | RPC Endpoint Mapper | Maps RPC requests to MSMQ services |
| Outbound | Agent Server | Target (MSMQ Server) | TCP | 2101, 2103, 2105 | MSMQ RPC | Additional MSMQ RPC ports |
| Outbound | Agent Server | Target (MSMQ Server) | UDP | 3527 | MSMQ Ping | MSMQ discovery protocol |
| Inbound | Target (MSMQ Server) | Agent Server | TCP/UDP | 135, 1801, 2101, 2103, 2105, 3527 | Response traffic | Automatically allowed by stateful firewall inspection |
Tip
MSMQ Port List: For a comprehensive list of MSMQ ports, review the Microsoft guide 'Network Ports Used by Message Queuing'.
Tip
MSMQ Security: For production environments, enable MSMQ transport security with encryption and authentication.
Between the Message Queueing Monitoring Agent and Azure Service Bus
Required for monitoring Azure Service Bus queues, topics, and subscriptions. All traffic is outbound HTTPS/AMQP to Azure; you need no inbound rule.
| Direction | Source | Destination | Protocol | Port(s) | Purpose | Notes |
|---|---|---|---|---|---|---|
| Outbound | Agent Server | Microsoft Entra ID (login.microsoftonline.com) |
TCP (HTTPS) | 443 | Acquire access tokens | App registration used in the Authentication tab |
| Outbound | Agent Server | Azure Resource Manager (management.azure.com) |
TCP (HTTPS) | 443 | Discover subscriptions, resource groups, and namespaces | Azure REST API |
| Outbound | Agent Server | Target (*.servicebus.windows.net) |
TCP (HTTPS) | 443 | Service Bus management and monitoring | Namespace endpoint |
| Outbound | Agent Server | Target (*.servicebus.windows.net) |
TCP | 5671, 5672 | AMQP with TLS | Advanced Message Queuing Protocol; used for message operations |
| Inbound | Azure | Agent Server | TCP | 443, 5671, 5672 | Response traffic | Automatically allowed by stateful firewall inspection |
Tip
AMQP Ports 5671 and 5672 Configuration: For comprehensive guidance on configuring, testing, and troubleshooting AMQP ports 5671 and 5672 for Azure Service Bus and Event Hub, firewall rules, PowerShell connectivity testing, and authentication requirements, see AMQP Port Configuration - 5671 and 5672.
Between the Message Queueing Monitoring Agent and MuleSoft AnypointMQ
Required for monitoring AnypointMQ queues. All traffic is outbound HTTPS (TLS 1.2) to the Anypoint Platform; see the 'Anypoint MQ FAQ' for control planes and regions.
| Direction | Source | Destination | Protocol | Port(s) | Purpose | Notes |
|---|---|---|---|---|---|---|
| Outbound | Agent Server | Target (Anypoint Platform, anypoint.mulesoft.com) |
TCP (HTTPS) | 443 | Authenticate (client id/secret) and query queues | US control plane. With Use EU Anypoint Platform checked, use eu1.anypoint.mulesoft.com |
| Outbound | Agent Server | Target (AnypointMQ broker, mq-{region}.anypoint.mulesoft.com) |
TCP (HTTPS) | 443 | Anypoint MQ Broker API | {region} is the configured Region ID, for example mq-us-east-1.anypoint.mulesoft.com |
Between the Message Queueing Monitoring Agent and the Domain Controller
Required for MSMQ monitoring with Windows authentication (domain service account).
| Direction | Source | Destination | Protocol | Port(s) | Purpose | Notes |
|---|---|---|---|---|---|---|
| Outbound | Agent Server | Domain Controller | TCP/UDP | 88 | Kerberos authentication | Required for domain authentication |
| Outbound | Agent Server | Domain Controller | TCP/UDP | 389 | LDAP | Standard LDAP queries |
| Outbound | Agent Server | Domain Controller | TCP | 636 | LDAPS (Secure LDAP) | Required for LDAPS authentication |
| Inbound | Domain Controller | Agent Server | TCP/UDP | Same as outbound | Response to Kerberos / LDAP | Usually allowed by stateful firewall inspection |
Between the servers and DNS
| Direction | Source | Destination | Protocol | Port(s) | Purpose | Notes |
|---|---|---|---|---|---|---|
| Outbound | Agent Server | DNS Server | TCP/UDP | 53 | Name resolution | Resolve the brokers, the Core Services Server, the Domain Controller, and the Azure and Anypoint hostnames. A local hosts file can replace DNS for on-premises hosts |
| Outbound | Core Services Server | DNS Server | TCP/UDP | 53 | Name resolution | Resolve the Agent Server |
Important
Stateful Firewalls: Most Windows Firewall implementations are stateful, so response traffic for established outbound connections is allowed automatically. The inbound response rules above are for reference and troubleshooting.
Release Notes
For detailed information about the features and bug fixes, please visit the Portal
Next Steps
Install Message Queues Monitoring Agent
Related Topics
Add or manage a Monitoring Agent Configuration
Monitoring
Administration