PRTG Release Notes:
Preview Channel

We have improved the runtime performance of the PRTG installer, which has included the PRTG database since PRTG stable version 26.1.118.1380. This change applies to all new installations.

We fixed an issue that occurred in previous Preview version 26.1.119.1641 where placeholders for credentials in custom sensors were not resolved anymore in certain cases. This issue could have led to authentication failures and the sensors to go into an error state.

You can verify the authenticity of the PRTG installer with the Secure Hash Algorithms for the following versions and release channels:

Preview 26.2.119.1662

• sha256_exe 6781DB15B7005A7D4891B2365E07FB547C14759A62151EE71E4B201C94A03719
• sha256_zip E2860C55595BF4E1769264D77E083233ECE5A3E4F3278DDCD2C38072AC0E6BD4

With this release, version 26.2.119.1663 is also available, as we are currently executing an A/B test. This version will therefore only be displayed for installation if you are in the corresponding group for a PRTG trial installation via website download. Apart from all changes that are included in 26.2.119.1662, this version comes with improvements and new features for our New UI.

With this PRTG version we introduce the new SNMP RMON v2 sensor that was rewritten to work also on the Multi-Platform Probe. The SNMP RMON v2 sensor monitors traffic on a device using the Remote Monitoring (RMON) standard via SNMP. In the Specific Sensor Settings you have the option to edit the settings Description or 64-bit on request. This information is collected during sensor creation and if 64-bit counters are enabled in the compatibility settings.

With this PRTG version we introduce the PRTG Installation Report, a new built-in report available by default in all standard PRTG installations under Reports menu. With this report you can collect data about your PRTG installation, including license information, system health and optimization recommendations. The report can be generated on-demand or scheduled for automated delivery. The report supports PDF, CSV and HTML formats.

• We performed sanitization on HTTP error responses to prevent information disclosure.
• We performed sanitization on the URL Path in HTTP error responses to prevent information disclosure.
• We enforced input sanitization on object name parameters to defend against possible Cross-Site Scripting.

The Microsoft 365 Mailbox sensor now supports the setting Validate Latest Email, like for example, the IMAP sensor. The sensor will use the latest email from the filtered messages. If no filters are configured, all messages are taken into account. You can configure warning or error states based on the Subject, From or Body settings. Additionally, you can set the sensor to Down or Warning status based on age for the latest email.

Various other minor fixes and improvements, updated user manual.

To be consistent with our changes in PRTG version 26.1.118.1380 to display information about sensor usage and licensing in the New UI, we removed the Number of Sensors part under License Information on the PRTG System Status page.

We fixed an issue where the PRTG core service used a large amount of memory in rare cases which caused the system to run out of memory in the end. You could find the error message out of memory in the core log file in such cases.

We fixed an issue where in certain cases an enabled Geo Map could lead to ajax timeout errors or slow performance in the PRTG web interface. You could observe this issue when your PRTG core server was blocked in your firewall for outgoing connections and PRTG would try to reach the geolocation service continuously. A possible workaround was to disable Geo maps.

We fixed an issue for the NetApp SnapMirror v2 sensor which regularly went into an error state and did not return any values for certain channels. The ONTAP API omitted transfer fields for continuously synced relationships and the sensor would handle the missing values as error. The issue happened when you used ONTAP with SnapMirror Active Sync and Consistency Groups.

We fixed an issue for Desktop Client and MultiBoard related API keys that you can create in PRTG via Add API Key for PRTG MultiBoard button. The issue happened when you started the Single Sign-on login flow calling getdesktoptoken.htm. The API key that was returned from the endpoint did not work for Single Sign-on content in those cases.

We fixed an issue where Run Auto-discovery with Templates led to an error (bad request) when you selected device templates via multi edit. Previously, it was only possible to select device templates on the first page of the pop-up window. As soon as you selected a device template on the second page or beyond, an error message appeared stating no device template had been selected.

We currently have an issue where placeholders for credentials in custom sensors are not resolved in this PRTG version, which can lead to authentication failures and cause the sensors to go into an error state. We are working on a fix with the highest priority and will deliver an update soon.

You can verify the authenticity of the PRTG installer with the Secure Hash Algorithms for the following versions and release channels:

Preview 26.1.119.1641

• sha256_exe B12238C40F9963CB04584261A9EA147EE4040F99777819C48AFC8AB15F004C11
• sha256_zip CB4D8FE9A8CF2F68D891FD8DF639F23EB0F104B74F1BAC14C82D46CC89859748

• We fixed an issue when the installation was cancelled in certain cases either manually or due to an error. The PRTG installer will now inform you about the process and the next steps with the message: Roll back of all changes done within this installation finished. Please reboot your system.
• We fixed an issue that occurred if you canceled the installation or rolled back to the previous PRTG version. In that case, the PRTG Administration Tool could no longer be started because the .exe file was no longer present.
• We fixed an issue that occurred in certain cases if you had PRTG installed with a Multi-Platform Probe connected and updated to a PRTG version that includes the PRTG Database. After updating, the NATS service was stopped and could not be started again. Additionally, the NATS server.log file was not created. In the Windows Event Logs you could find the following error: The service did not respond to the start or control request in a timely fashion.

• We fixed an issue for the SIMATIC S7-300/400 CPU Status (BETA) and SIMATIC S7-300/400 CPU Restart Overview (BETA) sensor that did not display any data results in certain cases. The issue happened because the sensor did not finish the scan for some monitored PLCs.
• We fixed an issue for the SIMATIC S7-300/400 CPU Status (BETA) and SIMATIC S7-300/400 CPU Restart Overview (BETA) sensor that reported an error message The buffer supplied is too low to accomplish the operation in certain cases. The issue happened for S7-410-5H controllers when the sensor failed to read the diagnostic buffer.

• We added a new setting Numeric Extraction to the Specific Sensor Settings of the SNMP Custom String v2 (BETA) sensor, which allows you to locate numbers inside a string from the SNMP device by using regular expressions. The sensor then displays the result in an additional channel: Extracted Number.
• We have improved the SNMP Custom String v2 sensor by changing the primary channel from Response Time to String Found. The Response Time channel did not display a meaningful error message if you used too many wildcards in the Search String setting. The primary channel String Found will display The search string contains too many wildcards in this case.


Important: To get the new primary channel String Found, you need to create this sensor again.

We fixed an issue for the SNMP Traffic v2 sensor that wrongly displayed 4 GBit/s as a result for unconnected ports in certain cases. The issue happened mostly for SNMP version v1 or high speed interface connections. The sensor will now display the status Unknown correctly for non-available entries instead of a wrong value.

• We fixed an issue where the api/v2/settings/public endpoint did not return the correct language upon GET request. Previously, only en-US was returned for the language field. The endpoint will now correctly display the language you have configured in the PRTG webinterface settings.
• We have improved the endpoint /experimental/objects/{id}/clone with better documentation in Swagger UI, for example. The deprecated endpoint clone endpoints experimental/devices/{id}/clone was removed.
• We fixed an issue in PRTG API v2 for the endpoint api/v2/channels/{id} where for some channel items the name field was returned with an empty string.
• We fixed an issue for the /experimental/schemas/{id}/get endpoint that did not handle the readonly property correctly for Read Only users that have the right to acknowledge alarms.
• We renamed the PATCH endpoint to /experimental/sensors/{id} to be consistent with other resource endpoints that use the object plural.
• We have updated the endpoints POST /experimental/devices/{id}/sensor and POST /experimental/devices/{id}/metascan in PRTG API v2 to now support all sensor kinds. Previously, only a selected set of fully tested sensors were allowed. With the sensor creation flow working reliably, the whitelist restriction has been removed, making sensor creation available for all supported sensor kinds without limitations.

We fixed an issue for the Device Tree in the New UI that displayed an additional Add Sensor button when you entered a search string in the search field.

We fixed an issue for the object tree under Monitoring where object calculation did not work properly for groups that contained only empty objects (groups or devices) and no sensors.

You are now able to use the following Device Action buttons via context menu: Reorder Tree, Copy and Paste. After you have copied an object, a success message appears. The same applies to the object once you have successfully pasted it. If you do not have the necessary access rights to an object, the buttons in the context menu will appear disabled and display the text no permission.

We fixed an issue where in certain cases an unknown error occurred with the message Something went wrong. Please refresh your browser or try again later. The issue in the new UI happened sporadically and in cases when you closed the browser and opened PRTG again with a page using iframes.

We improved the Home page in wording and display of content to match the user type that is logged in to PRTG.

We fixed an issue for auto-discovery that did not work when you used Credentials for Windows Systems with a configured IP range for your auto-discovery group and when you updated to previous PRTG version 26.1.118.1342. PRTG would initiate the auto-discovery process, however, the WMI sensors were not created afterwards.

Please note that for the new option to use WSMan protocol for WMI connections with Only Kerberos as authentication method, you have to select Use DNS names (default) for Name Resolution when you run an auto-discovery.

You can verify the authenticity of the PRTG installer with the Secure Hash Algorithms for the following versions and release channels:

Preview 26.1.118.1346

• sha256_exe 21F3D9DD7D323C57463F23CC33A4A6B8485DED9D38AC7B38302C212E10924120
• sha256_zip 9BFCA6C871B2397F0A6C8DBD304B5B7A2040F2B543D6F562434342061DF0E066

We improved the authentication implementation of PRTG to defend against potential timing attacks and username enumeration.

To follow up with the NTLM deprecation process from Microsoft and as a first iteration to support Kerberos for WMI sensors, we have implemented a toggle to use WSMan for WMI connections in the PRTG Administration Tool. In the Probe Settings for Monitoring you will see an additional radio button where you can select Use WSMan for WMI connections, however, DCOM is still activated by default. You can set WSMan for WMI connections for each probe.

In the PRTG settings Credentials for Windows Systems you can select the option Only Kerberos as WMI Authentication Method. To use the Only Kerberos setting, please enable the WSMan protocol on the probe system in the PRTG Administration Tool before. You can also select Negotiate (Kerberos, Fallback to NTLM) in the WMI Authentication Method when WSMan protocol is active. In this case, PRTG will establish a connection using Kerberos authentication.

Various other minor fixes and improvements, updated user manual.

We updated the German and Spanish language files.

We updated the German and Spanish language files for certain sensor types.

To give you an improved and accurate view of Maintenance Days Left and Sensors Available, we have removed the widget on the page welcome.htm in PRTG and replaced it with a link to the New UI. The button Need Accurate License Details? links you to the New UI which provides a transparent and consistent overview of sensor usage. In course of this, we have removed the Number of Sensors count on the License Status page in the classic web interface.

We fixed an issue for the SNMP Disk Free v2 sensor that reported a broken error message and could not read the disk when the disk name contained certain language characters. Any non-conforming character in the disk name is now translated into its hexadecimal representation. Please note that you must recreate the sensor for these changes to take effect.

We fixed an issue in the PRTG Administration Tool where strings in buttons e.g. were truncated for certain languages. Affected tabs were, for example, PRTG Application Server and NATS Server when you opened the PRTG Administration Tool in German.

We fixed an issue that occurred in previous PRTG version 26.1.117.1426, where the update would fail in certain special cases if you had a Multi-Platform Probe connected where the NATS server was not installed on the local PRTG core system but on a remote server. The setup error message displayed was: failed to read base configuration.

We fixed an issue for PRTG installation with previous PRTG version 26.1.117.1426 that failed when you have installed PRTG with custom Installation and Data Paths. The update process was initiated, but neither the PRTG Core server service nor the PRTG Database service did start.

We currently have an issue regarding auto-discovery where not all sensors are found and created when you start auto-discovery with specified Credentials for Windows Systems for a certain IP range. The issue occurs when you configure the IPv4 Base, IPv4 Range Start and IPv4 Range End fields for auto-discovery and also enable the Perform auto-discovery for devices/IP addresses already known within PRTG setting.

We currently face an issue in the PRTG API v2 for the new endpoint /api/v2/oas/objects/move/{id} where moving a sensor within a device to a different position led to an error in the response. The response returned was a 400 bad request HTTP error with the message The request could not be processed.

You can verify the authenticity of the PRTG installer with the Secure Hash Algorithms for the following versions and release channels:

Preview 26.1.118.1342

• sha256_exe DC052C134C39AD77A127B19C4E178B8D09E0E5268DB86059E71113DEDE497900
• sha256_zip A4FD79F21B9E03D571B7B28A68312AEF266A5563C77BCB5A747B381F98EA9732

• PRTG will now determine whether there is sufficient disk space available to perform the installation or update with PRTG Database. If there is insufficient disk space available, PRTG will display an error message during installation.
• PRTG will now delete all relevant files in case of a software version rollback. For example, the created files for the NATS manager natsmanager.db under C:\ProgramData\Paessler\PRTG Network Monitor are deleted upon rollback. Please note that the files are only deleted if you rollback to a PRTG version that does not include the PRTG Database, which is PRTG stable version 26.1.116.1532 or prior versions.

We improved the SIMATIC S7-300/400 CPU Status sensor (BETA) which now displays the Maximum OB1 Cycle Time in the Specific Sensors Settings if you have set it before during sensor creation. The Maximum OB1 Cycle Time describes the maximum cycle time for the program cycle organization block (OB1) what PRTG uses to calculate the value of the Cycle Ratio channel.

You can try out the experimental SIMATIC S7-300/400 LED Status sensor (BETA) which displays the status of all physical LEDs on the front panel of a SIMATIC S7-300 or S7-400 controller. The sensor will automatically create one channel per LED that is actually available on that monitored PLC model. Depending on the status of the LED, the sensor displays a message for the respective channel, which is mapped via lookup values. For example, Maintenance Required (MAINT) will show the status OK if the LED has the value OFF.

We improved the search method for the SNMP Custom String v2 sensor for search with wildcards and when you have set Interpret Result As to String (default) in the sensor Settings. The sensor has a new setting Search String Contains with the options Simple string (default), Wildcards and Regular expression. You can replace parts of your substring by wildcards, for example ? matches a single character. You can find the returned value in the channel String Found.

You can try out the experimental Proxmox VE Cluster Health sensor (BETA) that monitors the health status of Proxmox VE clusters. Available channels for this sensor type are Quorum Reached, Active Nodes, Online Nodes and Total Nodes. To use this sensor type, please enter the Credentials for Proxmox in the device settings with API token authentication. Please note that the channel Ceph Status is optional and is only available when you have configured a Ceph file system before.

• We have expanded our endpoint /experimental/devices/[id}sensor in PRTG API v2 with new supported sensors, which are also listed in the endpoint description and which can be created via POST request. For the SNMP Traffic v2 and Windows Network Card sensor you have to perform a Metascan before on the relevant endpoint /experimental/devices/ID/metascan via POST request in order to create the sensor.
• We have improved our endpoints regarding usergroups that only allow certain sensors to be created and when you are logged in to Swagger with a user assigned to such a group. The endpoint /experimental/schemas/{parent} now only returns the selected sensor types from the according group upon GET request. POST request on /experimental/devices/{id}/metascan and /experimental/devices/{id}/sensor with device ID and kind=different sensors will return only the selected sensors in the response.
• We fixed an issue for the endpoint /experimental/devices/{id}/autodiscovery when you executed a POST request for autodiscovery with device ID and a body with wrong or not existing discovery-template. In this case, only a generic error message was returned. You will now receive a correct error message: one or more templates could not be found.
• We have added a new endpoint /objects/{id}/move where you can execute POST requests in order to move the position of any monitoring object within it's siblings or to a new parent. In the Description section you can enter the ID of the object that you want to move. Additionally, you can combine parameters, for example with the position_preset parameter to move objects to a new parent.

With this PRTG version we introduce the new SNMP Windows Service v2 sensor that was rewritten to provide improved reliability and maintainability. This sensor monitors a Windows service via SNMP and uses credentials in Credentials for SNMP Devices that you have to configure in the device settings.

With this PRTG version we support authNoPriv as Authentication Method for SNMP sensors and SNMP version v3. The authNoPriv mode enables you to monitor infrastructures that only allow authentication without encryption. To use this authentication method, you have to select None as Encryption Type in the credentials for SNMP devices to disable encryption.

Various other minor fixes and improvements, updated user manual.

We updated the German and Spanish language files.

We fixed an issue in the device settings for Credentials for Microsoft 365 that occurred when you entered an invalid Tenant ID. In this case, you would receive a bad request error message, however, the changes were saved and you were not able to change any other device settings afterwards.

We fixed an issue for Folder sensors that occurred when you have monitored network shares that contained certain utf-8 special characters in their file names. In the Result of Sensor logfile you could see the following error message: No mapping for the Unicode character exists in the target multi-byte code page.

We fixed an issue for the Ping v2 sensor where the channel Status was not set as primary channel when you had the setting Inverted Error Status enabled.

We fixed an issue for the Microsoft 365 Mailbox sensor when you have selected "...matches regular expression" in the Filter Messages for Subject, Form and Body. The issue occurred in cases when you used an invalid regular expression. The sensor would display an error message that was only partially translated in these cases.

The SSH Disk Free v2 sensor now detects all available filesystems during sensor creation for Linux distributions. Previously, the sensor did not offer and create all available filesystems as channels like its predecessor SSH Disk Free which resulted in missing channels afterwards.

The configuration file of this version is not downwards compatible with previous PRTG versions.

To update to subsequent PRTG versions, you must first install the following PRTG version: 26.1.116.1534 Preview. PRTG 26.1.116.1534 serves as an intermediate version when you want to update from older PRTG versions to subsequent versions. This step is necessary because we had to update our code signing certificates.

PRTG will run into a setup error with the message failed to read base configuration when you update to this PRTG version in certain special cases. This issue happens when you have a Multi-Platform Probe connected where the NATS server is not installed on the local PRTG core system but on a remote server.

We currently face an issue where the update to this PRTG Preview version 26.1.117.1426 fails when you have installed PRTG with custom Installation and Data Paths. The update process is initiated, but neither the PRTG Core server service nor the PRTG Database service start. A possible workaround is to manually copy the content from the default Installation Path C:\Program Files (x86)\PRTG Network Monitor to the custom installation path and restart the services afterwards.

You can verify the authenticity of the PRTG installer with the Secure Hash Algorithms for the following versions and release channels:

Preview 26.1.117.1426

• sha256_exe DB15416A959B4905309569DB9624E4BA65636B1E468FAF5588FA37771EFFC1DE
• sha256_zip A28EF0617907107C5147817C5BA895C60FD72B462183F78FE194A4132C9EA6FA

With this release, version 26.1.117.1437 is also available, as we are currently executing an A/B test. This version will therefore only be displayed for installation if you are in the corresponding group for a PRTG trial installation. Apart from all changes that are included in 26.1.117.1426, this version comes with improvements and new features for our New UI.

Please note that you cannot add a new Multi-Platform Probe version 3.6.1 to this PRTG Preview version 26.1.117.1426. PRTG Preview version 26.1.117.1426 introduces an integrated NATS Server Setup to support the PRTG Database. The integrated NATS server changes the supported NATS authentication to NATS server Access Identifiers using NATS NKeys. Multi-Platform Probe 3.6.1 does not support the creation of NATS server Access Identifiers yet, however, we will add support in a later version.

Your existing Multi-Platform Probes are not affected and will be migrated automatically to the integrated NATS server.

With this PRTG version we introduce PRTG Database, developed for data processing and storage in PRTG as a first Beta release. PRTG Database is designed to increase efficiency and speed, especially in large installations with many sensors and data points. It is an alternative to file system storage and uses PostgreSQL to store raw monitoring and configuration data. The PRTG Database will install files and components automatically when you update to this PRTG version, however, it is currently deactivated by default.

Important:

• You cannot activate PRTG Database on a PRTG installation that runs a Cluster setup in this first iteration.
• Please note that for the Beta release, you cannot install PRTG core server on a system that already has a database (e.g. PostgreSQL) installed. The installation will fail with an error message in the installer informing you that PRTG requires its own database.
• Please note that you have to start the PRTG services manually in certain cases when you run a Cluster setup with PRTG and update to PRTG version 26.x.117. When you have set your PRTG to Automatically download and install in the Auto-Update settings, the installation will run successfully. However, the services remain stopped and must be started manually.

PRTG will create the Database Health (Autonomous) sensor automatically when you update to or install this PRTG version 26.1.117. The sensor is created within the PRTG Core Server group and monitors the PRTG Database service as a first iteration. The sensor will report an error if the PRTG Database service is not running.

You can try out the experimental SSL/TLS Security Check sensor which is the successor to the SSL Security Check sensor. The SSL/TLS Security Check sensor supports modern protocols to ensure secure encrypted connections. Unlike the old sensor, TLS 1.3 is also supported. TLS 1.2 and TLS 1.3 are set as accepted (default) in the sensor settings Security Evaluation, whereas weaker protocols (SSL 3.0, TLS 1.0, TLS 1.1) are set to denied (default). This sensor type can also be created on the Multi-Platform Probe.

You can try out the Proxmox VE Node Performance sensor that monitors performance metrics and status of Proxmox VE host nodes. To use this sensor type, please enter the Credentials for Proxmox in the device settings with API token authentication.

• You are now able to create an SSH Disk Free v2 sensor via POST request on the endpoint /experimental/devices/{id}/sensor with the kind ID paessler.ssh.disk_free_sensor. We have also updated the description for supported sensor types for this endpoint in the Open API Specification.
• We have expanded the experimental/schemas endpoint so that the response shows whether a sensor can be created or not due to missing credentials. For example, if you execute a GET request on /experimental/schemas/{parent} with according parent ID and limit, you will see for the according credential group either creatable:true or creatable:false for a sensor. In case of creatable:false the flag CredentialsMissing is returned in the response as well.

We fixed an issue where certain pages were displayed for a few seconds in the classic web interface. This issue happened sporadically and the new UI was displayed after automatic or manual refresh of the pages. This issue could affect the Maps and Reports pages, among others.

You can now enter and save notes in the new Comments tab which we have implemented for each monitoring object (Probe, Group, Device, Sensor level). You will receive a success message after saving your changes. Please note that the new Comments tab is not yet available on Mobile view. If you have existing comments in the classic web interface for that object, you will see the comments now also in the new UI.

We fixed an issue that occurred on the sensor Channel Overview page where unknown errors would be displayed. The issue happened after a certain page refresh interval, that is, after a page refresh you could observe an unknown error message toast.