Prerequisites for the Nodinite Windows Server Monitoring Agent

Nodinite Windows Server Monitoring Agent delivers robust, secure, and scalable monitoring for your entire Windows Server landscape. This page details all prerequisites to ensure a seamless installation, optimal connectivity, and compliance with best practices.

• ✅ Secure and scalable monitoring for on-premises and cloud environments
• ✅ All software, user rights, and firewall requirements in one place
• ✅ Expert guidance for PowerShell, WinRM, and Service Bus setup
• ✅ Avoid common pitfalls with clear troubleshooting and FAQ links

This page outlines the prerequisites for installing and running the Nodinite Windows Server Monitoring Agent.

This diagram shows how the agent connects to Windows Servers and pingable devices, supporting both local and remote PowerShell scripts.

You can install this agent on-premises using TCP/IP for local network access, or in the cloud/off-site using Service Bus Relaying. For more details, see the external link 'Azure Relay FAQs'.

We recommend keeping this agent close to Nodinite Core Services. This documentation covers local network setup (usually on the Nodinite application server)

Software Requirements

The Windows Server Monitoring Agent is a Windows Service and is usually installed on the Nodinite application server.

Versions 6.2 and later do no longer require the Microsoft.Web.Administration assembly on Agent Host.
Versions 6.0 and later make use of the .NET Framework 4.8 or later.
Versions 5.4 and later make use of the .NET Framework 4.6.2 or later.
Versions prior to 5.4 make use of the .NET Framework 4.5.2 or later.

Remote Windows Servers with IIS to monitor must have these Windows features installed.

IIS 6 roles and features required for remote monitoring.

If you have three servers with IIS to monitor, you must install this feature on three servers
If you see entries in the Event Log like while activating CLSID {2B72133B-3F5B-4602-8952-803546CE3344}, please review the prereqs, restart, and make sure the following settings have been applied: Setting DCOM Security to Allow a User to Access a Computer Remotely

Management Service

If the IIS is a remote server to the Monitoring Agent; You must also enable remote connections and make sure the WMSVC service is operational. Please review the Remote Administration for IIS Manager for additional details.

1. Enable remote connections
2. Make sure to auto-start the VMSVC service
   
   Ensure to allow remote connections and set the 'WMSVC' service to start automatically.

Enable remote connections

1. In the IIS MMC, click on the node, then, on Management Service.
2. Check the Enable remote connections checkbox.

Click the Apply to persist the changes.

Click Apply to persist the changes.

Set WMSVC to start automatically

The WMSVC service installs with Startup Type set to Manual, which means that the service has to be manually restarted each time the server reboots or if HTTP.sys is stopped (WMSVC depends on HTTP.sys). Set the Startup Type to Automatic if you want WMSVC to start on system boot. Do this in the Services MMC console, or using this command line in an administrative command prompt:

sc.exe config WMSVC start= auto  

Supported Versions

Windows Server is ever-evolving, and Microsoft sometimes adds new functionality and/or deprecates older SDKs, methods and adjust policies. For Nodinite, this means you need to update Nodinite and our Windows Server Monitoring Agent from time to time.

Make sure to subscribe to our Release Notes.

What Windows User Rights does the Windows Server Monitoring agent require?

The Nodinite Windows Server Monitoring Agent runs as a Windows Service on a Windows Server (physical or virtual machine), typically on the same server as the Nodinite application.

Service Account Requirements

You must configure a Windows user account to run the monitoring agent service. This account needs specific permissions:

1. Account Type

Choose one of the following account types:

• Domain account (recommended) - A user account from your Active Directory domain (e.g., DOMAIN\NodiniteAgent)
• Local named account - A local user account on the server where the agent is installed (e.g., .\NodiniteAgent)

Tip

Use a domain account if you plan to monitor multiple servers across your network. This simplifies permission management.

2. Required Permissions

The service account needs two sets of permissions:

a) On the Agent Server (where the agent is installed):

• Log on as a service right - Required for the account to run as a Windows Service
  • Follow the 'How to set logon as a Windows service right' guide for step-by-step instructions

b) On all Servers to monitor (Agent host and remote targets):

• Local Administrator membership - The service account must be a member of the local Administrators group on every Windows Server the agent will monitor. This includes the Agent Server when the agent also monitors its host.

Important

Critical requirement: To monitor Windows Servers (local or remote), the service account must have local administrator rights on each server being monitored. Without this, the agent cannot access WMI, performance counters, remote PowerShell, IIS management or other management operations required for full monitoring.

Example Configuration

If you're using domain account DOMAIN\NodiniteAgent to monitor 5 Windows Servers:

1. ✅ Grant "Log on as a service" right on the Agent Server
2. ✅ Add DOMAIN\NodiniteAgent to the local Administrators group on all 5 remote servers
3. ✅ Configure the Windows Server Monitoring Agent service to run as DOMAIN\NodiniteAgent

Note

Security consideration: While local administrator rights are required for full monitoring capabilities (WMI, performance counters, IIS management), consider your organization's security policies. Some enterprises use dedicated monitoring accounts with restricted permissions or implement least-privilege access patterns. Consult your security team if standard administrator rights are not permitted.

What Firewall settings do the Nodinite Windows Server Monitoring agent require?

Depending on where on the network you install the Windows Server Monitoring Agent and the Nodinite Monitoring Service; To monitor Windows Servers, you may need different firewall configurations on other servers. The following illustration shows the agent installed on a dedicated Windows Server.

This diagram illustrates agent and service communication, including remote WMI and RPC traffic.

The Windows Server Monitoring Agent has both inbound and outbound communication:

1. Between the Monitoring Service and the Windows Server Monitoring Agent
2. Between the Windows Server Monitoring Agent and monitored Windows Server(s)
   • Local (no ports required)
   • Remote ports are used

1. Between the Monitoring Service and the Windows Server Monitoring agent

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

And further with one of the following options depending on your Nodinite version and deployment scenario:

Option 1a (Nodinite v7 - IIS hosted on local network)

Nodinite v7 hosts agents in IIS. When the agent is installed on the same server as the Nodinite application (typical scenario), no additional firewall rules are required between the Monitoring Service and the agent.

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)

Nodinite v6 and earlier versions use Windows Services with RPC communication on port 8000.

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 totally different networks (cloud, off-site, or across firewalls).

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

2. Between the Windows Server Monitoring agent and Windows Servers

There is RPC and WMI traffic between the Windows Server Monitoring Agent and the monitored Windows Servers (1..*)

This diagram shows agent-to-server communication for RPC and WMI monitoring.

The following sections detail firewall requirements organized by service. Three servers participate in the monitoring interchange:

• Agent Server - Where the Nodinite Windows Server Monitoring Agent is installed
• Remote Windows Server - Target server(s) being monitored
• Domain Controller (DC) - Active Directory server for authentication

WMI / RPC Monitoring (Agent → Remote Server)

Required for remote Windows Server monitoring, performance counters, and WMI queries.

PowerShell Remoting / WinRM (Agent → Remote Server)

Required if monitoring via PowerShell Remoting or certain IIS monitoring features (alternative to WMI).

Tip

Use HTTPS (port 5986) in production environments for encrypted PowerShell Remoting sessions.

Authentication (Agent → Domain Controller)

Required if the agent authenticates using domain credentials or queries certificates from Active Directory.

Note

DNS Resolution: All servers (Agent, Remote Windows Servers, and Domain Controllers) require outbound access to DNS on TCP/UDP port 53 for name resolution. This is already listed in section 1. Between the Monitoring Service and the Windows Server Monitoring agent and applies universally. You can optionally solve this using entries in the local hosts file on each server. See How DNS works on TCP and UDP for additional details.

ICMP / Ping Monitoring (Agent → Any Device)

Required for availability checks and network connectivity monitoring.

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.

Add firewall rule

If you want to monitor the IIS on a remote Windows server, additional firewall exclusions may be required.

Please add a new firewall rule on the remote server to monitor to allow the dllhost.exe to accept incoming requests from the Nodinite Windows Server Monitoring Agent.

netsh advfirewall firewall add rule name="Remote IIS inetinfo" dir=in action=allow description="Remote IIS Service Managment" program="%systemroot%\System32\inetsrv\inetinfo.exe" enable=yes  

netsh advfirewall firewall add rule name="COM+ Remote Administration (All Programs)" dir=in action=allow description="" program="%windir%\system32\dllhost.exe" enable=yes localport=RPC protocol=tcp  

WinRM

⚠️WinRM must be enabled on remote Windows Server if you are using the PowerShell feature with remote target.

Run the scripts below on the remote server to enable WinRM:

The user must have administrator rights on the remote server.

Enable-PSRemoting -Force  

Firewall rules must allow PowerShell Remoting (TCP 5985 for HTTP, TCP 5986 for HTTPS).

New-NetFirewallRule -Name "Allow WinRM" -DisplayName "Allow WinRM" -Enabled True -Profile Any -Direction Inbound -Action Allow -Protocol TCP -LocalPort 5985  

Frequently asked questions

Additional solutions to common problems and the FAQ for the Nodinite Windows Server Monitoring Agent exist in the Troubleshooting user guide.

• 🪲Invalid Class
• ⌛Timeout or Connection Error

Next Step

Install Windows Server Monitoring Agent

Related Topics

Add or manage a Monitoring Agent Configuration
Monitoring
Administration