Opsview Agents installation

As a general rule, to avoid any backwards compatibility issues with older less secured technology, Opsview recommends that the version of the agents used is aligned with the version of Opsview Montior that you are running.

There are three basic approaches to monitoring devices on your network:

This document discusses how to achieve the last item in the list.

Linux Servers

We provide an agent package for all supported platforms for the Opsview Master within our repositories which will be installed automatically when you install any of Opsview Components.

For monitored hosts we also make agent packages available for other platforms through Opsview Download page. Installing this package will start a daemon that Opsview Monitor Collectors can use to interrogate the health of the system. It provides some default plugins (for checking on RAM, CPU and DISK, amongst others) that Host Templates within Opsview Monitor can make use of straight away.

You will need to ensure firewall access is open from relevant Collectors to port 5666.

You may also use any NRPE compatible agent and plugins, but you may need to configure both the agent and Opsview Monitor to make best use of it.


On Debian and Ubuntu:

sudo apt install /path/to/downloaded/opsview-agent*.deb

On RHEL, OL and CentOS:

sudo rpm -Uvh /path/to/downloaded/opsview-agent*.rpm


The agent installation may fail on systems where SELinux is enabled; the agent should successfully install the second time it is attempted.

Microsoft Windows Servers

Agent-based monitoring

Similar to Linux Servers above, an agent can be installed on the system. This agent is available on Opsview website and also includes some plugins usable with pre-defined Host Templates in Opsview Monitor.

You may also use any NRPE compatible agent and plugins (such as NSClient++), but you may need to configure both the agent and Opsview Monitor to make best use of it.

Powershell Agentless monitoring

An alternative method to monitor Microsoft Windows servers is to use agentless monitoring. This is where access is granted to run powershell scripts to specific users over a secure channel. The plugins used are stored within Opsview Monitor and are sent to the Windows server for execution, with the results being returned. This allows for centrally managing the Windows plugins and there is no need to keep agent software up to date on the target devices.


By default, Windows hosts will not allow PowerShell remote scripts to run, and so it must be enabled. This can be configured manually by the Windows Host administrator, or automatically using our recommended way which is using the following Powershell script on the Windows Host. This can be downloaded from Opsview Downloads page.

You need version 5.x of Powershell for Powershell Agentless Monitoring. Check your Powershell version by running $PSVersionTable.PSVersion within a Powershell terminal.

You need to run the ConfigureRemoting.ps1 script with Administrator privileges using a Powershell terminal. This will configure firewall rules, self-signed SSL certificates and authentication for PowerShell remote access.

PS C:\Users\admin\Downloads> .\ConfigureRemoting.ps1

You can check Powershell has been configured successfully by running the command winrm quickconfig.

PS C:\Users\admin\Downloads> winrm quickconfig
WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.

By default, port 5985 and port 5986 must be opened from the Opsview monitoring server to the Windows host you wish to check. WinRM utilises the HTTP/HTTPS protocol and can be configured to use certificates to secure the data in transit.

Test to ensure the service is listening run:

When using basic authentication with WinRM, the following commands must also be entered on the windows host:

winrm set winrm/config/service/auth '@{Basic="true"}'
winrm set winrm/config/service '@{AllowUnencrypted="true"}'
winrm set winrm/config/client/auth '@{Basic="true"}'

If you see a 500 error (which is a known issue on Windows Server 2016) you may need to install WinRM-IIS-Ext. Run the following command Add-WindowsFeature winrm-IIS-Ext.

Test connectivity from the orchestrator/collector to the windows host. Substitute for the IP of the windows host. A return of 0 means the connectivity is good.


Opsview 6.0 onwards will have the winrm package installed automatically and have the check_by_winrm.py plugin installed by default. This plugin is used by monitoring plugins to be run on the Windows Host.

check_by_winrm.py usage is as follows:

$ ./check_by_winrm.py
-H <HOST>: The IP address or resolvable name of the Windows host
-P <PORT>: The TCP port for connecting to the Windows host. Defaults to 5985 (HTTP) or 5986 (HTTPS)
-u <USER>: The Windows username; required unless using certificate transport
-p <PASS>: The Windows password; required unless using certificate transport or pre-authenticated kerberos transport
-t <TRANSPORT>: The authentication mechanism. One of: basic|certificate|kerberos|ntlm|credssp
-s <SCHEME>: Either HTTP or HTTPS
-i: Ignore certificate validation errors when using HTTPS
-C <CA_CERT_PATH>: The CA certificate (bundle) to be used for validating the HTTPS certificate on the server
-c <CERT_PATH>: The client certificate when using certificate transport
-k <CERT_KEY_PATH>: The client certificate key when using certificate transport
-D: Whether kerberos delegation should be used (default: False). This enables the PowerShell script to use your Kerberos ticket to jump to other hosts. Only useful when using Kerberos transport.
-r: The read timeout seconds when reading back from the WinRM connection
-o: The operation timeout seconds when waiting for a WinRM operation to complete
<SCRIPT>: The name of the powershell script to execute. This should be either relative to CWD, absolute, or relative to the plugins.d directory
<PARAMS>: The parameters to pass to the powershell script, if required.

Example usage:

$ check_by_winrm.py -H '' -u 'windows_user' -p 'windows_password' -t 'basic' -s http check_windows_base.ps1 -m cpu_usage

WinRM Host Variables

check_by_winrm.py uses the WINRM_TRANSPORT variables. These variables are:

These should be set on each host that uses check_by_winrm.py

Reload to submit your changes. Any hosts configured with Opspacks that use check_by_winrm.py should now be able to remotely run their Powershell monitoring plugins. See the Opspacks section for more details.

["Opsview"] ["User Guide"]

Was this topic helpful?