- 9 minutes to read

Prerequisites for the Nodinite Monitoring Service

Prepare your environment for a seamless Nodinite Monitoring Service deployment. This page provides a comprehensive checklist and best practices to ensure a successful installation and secure operation in any environment.

✅ Complete prerequisites checklist for fast deployment
✅ Covers SMTP, MSDTC, Windows rights, SQL permissions, and firewall settings
✅ Troubleshooting tips for complex, distributed, or secure environments

This page describes the prerequisites for installing and running the Nodinite Monitoring Service. The Monitoring Service is a Windows Service installed as part of the Core Services package.

Nodinite Monitoring Service Checklist

The Monitoring Service is easy to install on a single server, but in distributed or locked-down environments (with load balancing, firewalls, network zones, domains, DNS, group policies, antivirus, etc.), you may need to address additional requirements for a smooth setup.

Verified Topic
SMTP - Monitoring Service must be allowed to send emails
MSDTC
Windows rights
Database rights
Firewall

Use the checklist above to verify that you have performed all steps required to get Nodinite flying (most probably already managed when you performed similar tasks for the Configuration Database).

SMTP Settings

Alerts are sent using Alarm Plugins and it is very common to use any of the Nodinite e-mail plugins.

The Nodinite Monitoring Service must be allowed to send emails and this is often governed by your organization's policies.

Microsoft Distributed Transaction Coordinator (DTC)

The Monitoring Service is involved in SQL Server related operations and Nodinite uses the Windows Service Microsoft Distributed Transaction Coordinator (DTC) that is responsible for coordinating transactions that span multiple resource managers. We have written a dedicated tutorial for Nodinite with our best practices for how to install and configure the DTC Windows Service.

You must configure the DTC as documented, otherwise Nodinite will not be able to function.

What Windows rights does the Monitoring Service require?

The Nodinite Monitoring Service is a Windows Service (not an IIS application) that runs under a configured service account. The v7 PowerShell installation scripts automatically configure the service during installation.

Service Account Requirements:

  • The service account must have Logon as a Service rights - see How to set Logon as a Service right
  • The service account must have appropriate SQL Server rights (see next section)
  • This service should always be running
  • This service should not be clustered - contact support if you need technical assistance
  • DCOM Local Activation Permission is required for the service to function properly

How It Works:

The v7 PowerShell installation scripts create and configure the Monitoring Service Windows Service with the specified service account. This service coordinates with Monitoring Agents, executes Remote Actions, and delivers alerts through various Alert Plugins.

What SQL Rights does the Monitoring Service require?

The Windows domain account being used for the Monitoring Service must have the following SQL rights assigned (least privileges):

Master

The grants depend on the type of SQL Server instance:

>= SQL Server 2016 < SQL Server 2016
db_owner db_datareader

Grant VIEW SERVER STATE rights.

GRANT VIEW SERVER STATE TO [Domain\user]

Replace [Domain\user] with the Windows account being used for the Monitoring Service.

If applicable, repeat the grant on all nodes part of an AOAG environment.

Nodinite Databases

db_ddladmin is required for the service account to have proper rights to read statistics. Without this permission, performance may be degraded, especially true for remote servers (linked servers). Read more here. Contact our support if you have any questions about this.
All databases on all SQL Instance(s)—where Configuration Database and Log Databases databases are located:

Scope Permission / Role Description Microsoft Docs Link
Instance/Database public Right to log on to SQL instances and databases used by Nodinite public role
Database db_ddladmin Required so the service account can run necessary DDL (and read statistics) for performance-sensitive operations, especially across linked servers db_ddladmin

Important

db_ddladmin is required for the service account to have proper rights to read statistics. Without this permission, performance may be degraded, especially for remote servers (linked servers). Read more here. Contact our support if you have any questions about this.

All Nodinite specific databases

Database Permission Description Microsoft Docs Link
Configuration Database db_datareader Grants read access to all tables and views db_datareader
Configuration Database db_datawriter Grants write access to all tables and views db_datawriter
Configuration Database db_ddladmin Allows running DDL statements (e.g., create/alter/drop objects) db_ddladmin
Configuration Database sysadmin/db_owner Required for certain administrative tasks (e.g., shrinking databases) sysadmin, db_owner
NodiniteLog_* db_datareader Grants read access to all tables and views db_datareader
NodiniteLog_* db_datawriter Grants write access to all tables and views db_datawriter
NodiniteLog_* db_ddladmin Allows running DDL statements (e.g., create/alter/drop objects) db_ddladmin
NodiniteLog_* sysadmin/db_owner Required for certain administrative tasks (e.g., shrinking databases) sysadmin, db_owner

This table lists the minimum SQL Server permissions required for the Nodinite Monitoring Service's Configuration Database and Log Databases. Ensure these grants are set for uninterrupted operation, maintenance, and automation.

Grant Execute rights on all existing and future stored procedures for the account used by the Monitoring Service:

GRANT EXECUTE TO [Domain\\user]

Replace [Domain\user] with the Windows account being used for the Monitoring Service.

What Firewall settings are required for the Monitoring Service?

The Monitoring Service is a Windows Service that executes monitor checks and distributes alerts. It communicates with Monitoring Agents, the Web API, Alarm Plugins, and SQL Server. Proper firewall configuration is required for these interactions.

Four types of servers commonly participate in Monitoring Service deployments:

Server Role
Monitoring Service Server Hosts the Monitoring Service (Application Server role)
Agent / Node Servers Host the Monitoring Agents and any remote resources being monitored
Web Server Hosts the Web API and Web Client (IIS)
SQL Server Hosts the Configuration and Log Databases

Plan firewall rules for communication between these servers (Monitoring Service ↔ Agent servers, Monitoring Service ↔ Web Server, Monitoring Service ↔ SQL Server, Agents ↔ Domain Controller).

Required Firewall Ports

Understanding Port Configuration: v6 vs v7

Nodinite v6 (Legacy - Windows Services):

In Nodinite v6, the Monitoring Service, Logging Service, and Web API run as Windows Services communicating over TCP port 8000. This is the legacy architecture.

Nodinite v7 (Current - IIS Web Applications):

In Nodinite v7, these components are IIS Web Applications hosted in IIS. Port numbers are configured during installation in the Nodinite Portal and can be customized per environment:

Component Default Port Configurable
Web Client 40000 (or 443 with HTTPS) ✅
Web API 40001 ✅
Log API 40002 ✅
Logging Service 40003 ✅
Monitoring Service 40004 ✅

The v7 PowerShell installation scripts automatically configure IIS bindings based on your Portal settings.

Important

Upgrading from v6 to v7: Firewall rules must be updated from port 8000 to the new IIS ports configured in the Portal. The installer does not automatically update firewall rules.

1. TCP Ports between Monitoring Service and Monitoring Agents

For Nodinite v7 (IIS Web Applications):

Monitoring Agents communicate with the Monitoring Service using the port configured in the Nodinite Portal (default: 40004).

The following ports must be allowed on the Windows server where the agent is installed and running:

Port Name Inbound Outbound TCP UDP Comment
53 DNS 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 1 (Local network)

Version Port Name Inbound Outbound TCP UDP Comment
v7 40004 IIS Web App Port configured in Portal; Communication initiated by Monitoring Service
v6 (Legacy) 8000 Windows Service Legacy Windows Service architecture

Option 2 (Cloud/Hybrid)

Use Service Bus Relayed connections when Nodinite and the agent are on totally different networks.

Nodinite uses the same principle technique as the On-Premise data gateway, see 'Adjust communication settings for the on-premises data gateway' user guide.

The following Ports must be open for outbound communication with '*.servicebus.windows.net' from both on-premise and off-site:

Port Name Inbound Outbound TCP UDP Comment
443 HTTPS Secure outbound traffic
5671, 5672 Secure AMQP
9350 - 9354 Net.TCP

2. TCP Ports between Monitoring Service and Web API

Version Port Name Inbound Outbound TCP UDP Comment
v7 40001, 40004 IIS Web Apps Ports configured in Portal; Communication initiated by Monitoring Service
v6 (Legacy) 8000 Windows Service Legacy Windows Service architecture
  1. Monitoring Service and Alarm Plugins
  • 25 – SMTP as described in RFC 5321
  • 443 – SSL
  • 587 – SMTP-MSA as described in RFC 6409
  • 465 – SMTPS as described in RFC8314 (Not common any more)
  • Any other port your custom built Alarm Plugin may require
  1. TCP Ports between Monitoring Service and SQL Server

1. TCP Ports between Monitoring Service and Monitoring Agents

Note

Actual ports with Nodinite v7 depends on your configuration, usually set in the Portal.

graph LR subgraph Server A ro(fal:fa-watch-fitness Monitoring Service) --> | 8000 | ro1(fal:fa-monitor-waveform Monitoring Agent A) ro --> | 8000 | ro2(fal:fa-monitor-waveform Monitoring Agent B) end subgraph Server B ro --> | 8000 | ro4(fal:fa-monitor-waveform Monitoring Agent A) end

Example where agents are installed as Windows Services using the default port 8000.

graph TD subgraph On-Premise ro(fal:fa-watch-fitness Monitoring Service) end subgraph Microsoft Azure ro --> ro1(fal:fa-cloud Service Bus Relaying) end subgraph Off-Site ro3(fal:fa-monitor-waveform Monitoring Agent A) -->ro1 end id1[*.servicebus.windows.net
443 Listeners on Service Bus Relay over TCP requires 443 for Access Control token acquisition
5671-5672 Advanced Message Queuing Protocol AMQP
9350-9354 Net.TCP]

2. TCP Ports between Monitoring Service and Web API

Nodinite v7 (IIS Web Applications):

Nodinite shows the state of the Monitoring Service for Users within the Web Client. The Web Client asks the Web API which in turn queries the Monitoring Service. The Monitoring Service uses the Web API to provide all its features.

graph LR subgraph "Windows Server" roMonitoringService(fal:fa-watch-fitness Monitoring Service - IIS) end subgraph "Web Server" roWebAPI(fal:fa-cloud-sun Web API - IIS) roMonitoringService--> | 400xx | roWebAPI roWebAPI --> | 400xx | roMonitoringService end

Diagram: In Nodinite v7, the Monitoring Service and Web API communicate using IIS ports configured in the Portal (default: 40001).

3. Monitoring Service and Alarm Plugins

Alerts are distributed by the Monitoring Service for Monitor Views when a configuration matches a changed state of Resources. The alert is pushed to each 'Alarm Plugin'. Nodinite ships with default alarm plugins and it is possible for you to add your own Alarm Plugins. These are DLLs written in any .NET language. Templates and SDK are intended for use with C#.

graph LR subgraph Issue Tracking System roIssue(fal:fa-bug Jira API) end subgraph Mail Server roSMTP(fal:fa-envelope SMTP Service) end subgraph Windows Server roMonitoringService(fal:fa-watch-fitness Monitoring Service) roMonitoringService --> | 25 or 587 | roSMTP roMonitoringService --> | 443 | roIssue end

Important

Depending on what external services your custom built Alarm Plugin uses you may need to ensure open TCP ports according to the requirements of that external service provider.

Where do I add my custom built Alarm Plugin?

You simply copy the DLL to the 'Plugins' folder of the Monitoring Service. If the DLL is being replaced then you must restart the Monitoring Service.

Important

Make sure the DLL after the copy-paste operation is not blocked by Windows. Right-click on the DLL and select properties. Click the Unblock button if that option exists.

  1. TCP Ports between Monitoring Service and SQL Server

For performance reasons the Monitoring Service accesses the databases directly using the Windows Service Account configured.

The Monitoring Service communicates with SQL Server using Windows authentication, Kerberos, and distributed transactions (MSDTC). For comprehensive SQL Server firewall configuration, including:

  • DNS resolution (port 53)
  • Kerberos authentication (port 88)
  • MSDTC/RPC (port 135 and dynamic ports)
  • SQL Server instances (port 1433 and custom ports)
  • Linked Servers configuration
  • Azure SQL Managed Instance connectivity
  • Always On Availability Groups (AOAG) requirements

See the comprehensive SQL Server Firewall Configuration guide.

graph LR subgraph SQL Server roConfigDatabase(fal:fa-database Configuration database) --- | Linked Server | roLogDatabase(fal:fa-database fal:fa-database fal:fa-database Log databases) end subgraph Application Server roMonitoringService(fal:fa-watch-fitness Monitoring Service) --- | SQL, DTC, DNS, RPC, ... | roConfigDatabase end

Frequently asked questions

Additional solutions to common problems and the Nodinite Monitoring Service FAQ exist in the Troubleshooting user guide.

Next Step

Install Monitoring Service
System Parameters
Search Fields

Alarm Plugins
Configuration Database
Core Services
Log Databases
Monitoring Agents
Monitoring Service
Monitor Views
MSDTC
Remote Actions
Resources
Search Fields
Service Bus Relaying
SQL Server Firewall
System Parameters
Troubleshooting
Uninstall Monitoring Service
Update Monitoring Service
Users
Web API