What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

Which sensors will you remove from PRTG and what are the alternatives?

Votes:

0

My PRTG installation shows the message that certain sensor types are deprecated as of PRTG 16.x.23 and will be removed completely with PRTG 16.x.25.

  • Why do you reduce the number of available sensor types?
  • Which sensors will be discontinued and how does this affect me?
  • Can I use other approaches to still get this data, so is there an alternative to the deprecated sensors?

cleanup deprecated prtg remove sensor

Created on Feb 5, 2016 2:39:08 PM by  Gerald Schoch [Paessler Support]

Last change on Jun 14, 2022 8:39:28 AM by  Brandy Greger [Paessler Support]



50 Replies

Accepted Answer

Votes:

0


Notice: For a complete and up-to-date list of all deprecated sensors and their successors or alternatives, see Which sensors are deprecated and what are their successors or alternatives?


This article applies as of PRTG 16.x.23

The PRTG sensor cleanup

You know PRTG as a powerful yet easy-to-use network monitoring solution. When we implement new features, we always try to keep complexity as low as possible, so you can do what is important: monitor without configuration hassles. To keep PRTG usage simple for the future, we constantly analyze available features for their benefits and downsides.

We believe you prefer that we focus on features that the majority of PRTG customers use every day. Niche issues that only affect special use cases of PRTG distract this focus and spending our precious energy on such topics does not improve your overall user experience of PRTG. It is also ineffective when niche problems create substantial workload for both our technical support team and developers while other inquiries have to wait.

To be able to focus on important and popular topics, it is necessary that we reduce code complexity and currently available features like, for example, some sensor types. In this context, we recently evaluated the existing sensor types and discussed the following points for each one:

  • Is it useful for many of our users or is the usage rate very low?
  • Is it compatible with current systems or does it only support outdated target systems?
  • Is it easy-to-use and do target systems work flawlessly with it, or does it create disproportional workload for you and our support team?

If a sensor type does not fulfill all of these requisites, then it is a potential candidate for removal from the software. Of course, whenever possible, we do not want to impair your monitoring experience, so we also considered options to provide alternatives for such sensor types.

As a result, starting with PRTG 16.x.23, we deprecated several sensor types (see below) and finally removed them in PRTG 16.x.25. Note that many of the sensors that we removed had already been deprecated in previous versions. However, some of them still existed (but you could not add new instances of them anymore).

Deprecation and removal of sensors

The approach for sensors that are deprecated as of PRTG 16.x.23 is the following:

  • Deprecated sensors will be marked as such in your PRTG installation.
  • You cannot add deprecated sensors to PRTG anymore, neither manually nor via Auto-Discovery.
  • PRTG will additionally inform you about deprecated sensors with tickets.
  • You can still use deprecated sensors that you added in versions previous to PRTG 16.x.23.

In PRTG 16.x.25, the deprecated sensors were removed from PRTG:

  • If you still run deprecated sensors, these sensors will throw an error and show the Down status as of PRTG 16.x.25. They will not provide any monitoring data as of this version!
  • You will get a ticket that notifies you about these removed sensors.
  • Delete these sensors to avoid “false” alarms in your installation or pause them to keep historic monitoring data.
  • Additionally, check if your maps, reports, and libraries include one of these sensor types. Manually delete them where necessary to avoid incorrect data.

Deprecated sensor types and alternatives

After analyzing the current sensor situation, we decided to remove the following sensor types from PRTG. If possible, we also provide an alternative so you can still monitor the desired data.

There are two categories of deprecated sensor types.

  • There are sensors that we deprecated with PRTG 16.x.23. These are sensors that you could add until this version and run until PRTG 16.x.25.
  • There are also older sensor types that were deprecated in previous versions (for example, in PRTG 12) and that you could not add anymore. These were removed from PRTG 16.x.25 as well.

Sensor types deprecated as of PRTG 16.x.23

The following sensor types are deprecated as of PRTG 16.x.23 and were removed with PRTG 16.x.25. See below for translations of deprecated sensor types into your PRTG language version.

Deprecated SensorAlternative
ADO SQLUse the ADO SQL v2 sensor instead.
Note: If you have a great number of these sensors, consider the migration path for deprecated SQL sensors.
AVM FRITZ!Box WAN Interface v2Use the custom FRITZ!Box sensors by PRTG Tools Family instead. You can choose from several sensor types for your FRITZ!Box.
INI File Content CheckUse the custom INIFileValue sensor by PRTG Tools Family instead.
Microsoft SQLUse the Microsoft SQL v2 sensor instead.
Note: If you have a great number of these sensors, consider the migration path for deprecated SQL sensors.
MongoDB System HealthWe cannot provide an alternative for this sensor type. MongoDB deprecated the HTTP interface that the sensor uses to retrieve data.
MySQLUse the MySQL v2 sensor instead.
Note: If you have a great number of these sensors, consider the migration path for deprecated SQL sensors.
Oracle SQLUse the Oracle SQL v2 sensor instead.
Note: If you have a great number of these sensors, consider the migration path for deprecated SQL sensors.
Passive Application PerformanceWe cannot provide an alternative for this sensor type.
PingdomUse the Cloud HTTP sensor instead to ping your device from several locations worldwide.
POP3 Email CountUse the custom EmailCount sensor by PRTG Tools Family instead.
SCVMM HostUse a custom sensor with the PS1 script as described in this article: How can I monitor SCVMM hosts and VMs with PRTG?
SCVMM Virtual MachineUse a custom sensor with the PS1 script as described in this article: How can I monitor SCVMM hosts and VMs with PRTG?
SNMP GSA System HealthAdd a custom sensor as described in this article: How can I monitor my Google Search Appliance with PRTG?
Virtuozzo Container DiskWe cannot provide an alternative for this sensor type.
Virtuozzo Container NetworkWe cannot provide an alternative for this sensor type.
WBEM CustomWe cannot provide an alternative for this sensor type.
Windows Last Update (Remote Registry)Use the Windows Updates Status (PowerShell) sensor instead.
Windows Logged In UsersUse the custom UserLoggedin sensor by PRTG Tools Family instead. For further instructions, see How can I monitor the number of users logged in to Windows?
Windows Physical DiskUse the Windows Physical Disk I/O sensor instead.
Windows RegistryUse a custom sensor as described in this article: How can I monitor the Windows registry with PRTG?
Windows Scheduled TaskUse the custom ScheduledTask2XML sensor by PRTG Tools Family instead.
Note: This sensor type requires Windows 7 or later or Windows Server 2008 or later on the target system. It does not support the outdated operating systems Windows Server 2003, Windows Vista, or Windows XP.
WMI Logical DiskUse the WMI Logical Disk I/O sensor instead.
WMI Volume FragmentationUse the custom VolumeFragXML sensor by PRTG Tools Family instead.
WMI Windows VersionUse the custom WinOSVersion sensor by PRTG Tools Family instead.

Note: We offer a migration path for the deprecated SQL sensors. If possible, they should be replaced with SQL v2 sensors nonetheless. The migration path is intended to give you more time to create corresponding SQL v2 sensors if you use a large number of deprecated SQL sensors. For more detailed information, see I use a large number of SQL sensors, can I continue using the deprecated SQL sensors somehow?

Sensor types deprecated before PRTG 16.x.23

The following sensor types were deprecated in PRTG versions before 16.x.23.

Deprecated sensorDeprecated sinceAlternativeGerman designation
Active Directory Replication Errors (original version)14.1.9Use the newer version of the Active Directory Replication Errors sensor as of PRTG 14.1.9. Add the sensor anew if you get the "deprecated" message for it.Active Directory Replikationsfehler
Amazon CloudWatch15.3.19Use CloudWatch service specific sensors instead: EBS, EC2, ElastiCache, ELB, RDS, SNS, SQS, alarmAmazon CloudWatch
AVM FRITZ!Box WAN Interface14.4.13Use the custom FRITZ!Box sensors by PRTG Tools Family instead.AVM FRITZ!Box WAN Interface
Google Analytics (original version)15.2.17Use the newer version of the Google Analytics sensor (available as of PRTG 15.3.19) instead. Add the sensor anew if you get the "deprecated" message for it.Google Analytics
HDD Health12.3.1Use the WMI HDD Health sensor instead.Laufwerkszustand
HTTP SSL Certificate Expiry15.3.19Use the SSL Certificate sensor instead.Verfall des HTTP Zertifikats
INI File Content Check9.1.4Use the custom INIFileValue sensor by PRTG Tools Family instead.INI-Datei Inhaltsüberprüfung
Logfile Content Checkbefore PRTG 12Use the custom LogfileReader sensor by PRTG Tools Family instead.Datei-Inhalt
Ping with Delayed Upbefore PRTG 12Use the Ping Delay option of the Ping sensor in PRTG. Alternatively, you can use the custom PingDelayedUp sensor by PRTG Tools Family.Ping mit verzögertem OK
RADIUS15.2.16Use the RADIUS v2 sensor instead.RADIUS
SNMP Informant7.1Import the MIB file from SNMP Informant and set up an SNMP Library sensor.SNMP-Informant
SNMP Trap Receiver14.1.8Use the newer SNMP Trap Receiver sensor instead. Add the sensor anew if you get the "deprecated" message for it.SNMP-Trap-Empfänger
SSH VMware ESX(i) Disk (v1 and v2)15.3.19Use the VMware Datastore (SOAP) sensor instead.SSH VMware ESX(i) Laufwerk
Syslog Receiver (original version)14.1.8Use the newer Syslog Receiver sensor instead. Add the sensor anew if you get the "deprecated" message for it.VMWare Hostserver Hardware-Zustand (SOAP)
VMware Host Server (SOAP)PRTG 12Use the VMware Host Performance (SOAP) sensor instead.VMware Hostserver Leistung (SOAP)
VMware Virtual Machine (SOAP)PRTG 12Use the current VMware Virtual Machine (SOAP) sensor instead. Add the sensor anew if you get the "deprecated" message for it.VMware Virtual Machine (SOAP)
WMI Exchange Server 2003 and 20079.1Use the WMI Exchange Server sensor instead.WMI Exchange-Server
Xen Virtual MachinePRTG 12Use the Citrix XenServer Virtual Machine sensor instead.Citrix XenServer Virtuelle Maschine

Translations

Please find translations of the original English names of deprecated sensor types below.

EnglishDeutschPortuguês (Brasil)Čeština
ADO SQLADO SQLSQL ADOADO SQL
AVM FRITZ!Box WAN Interface v2FRITZ!box Internet-Schnittstelle V2Interface de WAN do AVM FRITZ!BoxAVM FRITZ!Box WAN Interface v2
INI File Content CheckINI-Datei InhaltsüberprüfungVerificação do conteúdo do arquivo INIKontrola obsahu INI souboru
Microsoft SQLMicrosoft SQLMicrosoft SQLMicrosoft SQL
MongoDB System HealthMongoDB SystemzustandFuncionamento do sistema do MongoDBMongoDB System Health
MySQLMySQLMySQLMySQL
Oracle SQLOracle SQLOracle SQLOracle SQL
Passive Application PerformancePerformance von AnwendungenDesempenho do aplicativo passivoPasivní aplikační výkon
PingdomPingdomPingdomPingdom
POP3 Email CountPOP3 E-Mail-AnzahlContagem de e-mail POP3POP3 emailový součet
SCVMM HostSCVMM HostHost SCVMMSCVMM Hostitel
SCVMM Virtual MachineSCVMM Virtuelle MaschineMáquina virtual SCVMMSCVMM Virtuální stroj
SNMP GSA System HealthSNMP GSA SystemzustandFuncionamento do sistema GSA SNMPSNMP GSA Zdraví Systému
Virtuozzo Container DiskVirtuozzo Container LaufwerksnutzungDisco do recipiente VirtuozzoDisk Virtuozzo kontejneru
Virtuozzo Container NetworkVirtuozzo Container NetzwerkRede de recipientes VirtuozzoVirtuozzo kontejnerová síť
WBEM CustomWBEM (Benutzerdef.)WBEM customizadoVlastní WBEM
Windows Last Update (Remote Registry)Letztes Windows-Update (Remote-Registrierung)Última atualização do Windows (Registro remoto)Poslední aktualizace Windows (Vzdálený Registr)
Windows Logged In UsersAngemeldete Windows-UserUsuários logados no WindowsWindows přihlášení uživatelé
Windows Physical DiskWindows Physikalischer DatenträgerDisco físico do WindowsWindows fyzický disk
Windows RegistryWindows RegistrierungRegistro do WindowsRegistr Windows
Windows Scheduled TaskWindows: Geplante AufgabeTarefa planejada do WindowsNaplánované úlohy Windows
WMI Logical DiskWMI Logischer DatenträgerDisco lógico de WMIWMI logický disk
WMI Volume FragmentationWMI LaufwerksfragmentierungFragmentação de volume de WMIWMI Hondota Fragmentace
WMI Windows VersionWMI Windows VersionVersão do Windows WMIWMI Windows verze
EnglishNederlandsFrançais日本語 (Japanese)
ADO SQLADO SQLSQL ADOADO SQL
AVM FRITZ!Box WAN Interface v2AVM FRITZ!Box WAN Interface v2Interface WAN Fritz!Box AVM v2AVM FRITZ!Box WAN インターフェース v2
INI File Content CheckINI-Bestand Inhoud ControleVérification du contenu du fichier INIINI ファイルの設定値チェック
Microsoft SQLMicrosoft SQLMicrosoft SQLMicrosoft SQL
MongoDB System HealthMongoDB Systeem StatusÉtat du système MongoDBMongoDB システムヘルス
MySQLMySQLMySQLMySQL
Oracle SQLOracle SQLOracle SQLOracle SQL
Passive Application PerformancePassieve toepassingsprestatiesPerformance des applicationsパッシブアプリケーションパフォーマンス
PingdomPingdomPingdomPingdom
POP3 Email CountPOP3 Email aantalNombre d'e-mail POP3POP3 メール数
SCVMM HostSCVMM HostHôtes SCVMMSCVMM ホスト
SCVMM Virtual MachineSCVMM Virtuele MachineOrdinateur virtuel SCVMMSCVMM 仮想マシン
SNMP GSA System HealthSNMP GSA System HealthÉtat du système SNMP GSASNMP GSA システムヘルス
Virtuozzo Container DiskVirtuozzo Container SchijfUtilisation disque Virtuozzo ContainerVirtuozzoコンテナ ディスク使用状況
Virtuozzo Container NetworkVirtuozzo Container NetwerkRéseau Virtuozzo ContainerVirtuozzoコンテナ ネットワーク
WBEM CustomWBEM AangepastWBEM (personnalisé)WBEMカスタム
Windows Last Update (Remote Registry)Windows Laatste Update (Remote Registry)Dernière mise à jour Windows (Registre à distance)Windows 最新アップデート(Remote Registry)
Windows Logged In UsersWindows Ingelogde GebruikersUtilisateurs Windows enregistrésWindows ログインユーザー数
Windows Physical DiskWMI Fysieke SchijfDisque physique de WindowsWindows 物理ディスク
Windows RegistryWindows RegistryRegistre WindowsWindowsのレジストリ
Windows Scheduled TaskWindows Geplande TakenTâche planifiée WindowsWindows スケジュールタスク
WMI Logical DiskWMI Logische SchijfDisque logique WMIWMI 論理ディスク
WMI Volume FragmentationWMI Volume fragmentatieFragmentation de volume WMIWMI ボリュームフラグメンテーション
WMI Windows VersionWMI Windows VersieVersion Windows WMIWMI Windows バージョン
EnglishEspañolPyсский (Russian)简体中文 (Simplified Chinese)
ADO SQLADO SQLADO SQLADO SQL
AVM FRITZ!Box WAN Interface v2Interfaz AVM FRITZ!Box WAN v2Интерфейс WAN устройства AVM FRITZ!Box v2AVM FRITZ!Box WAN 接口 v2
INI File Content CheckRevisión de contenido de archivo INIПроверка содержимого файла INIINI 文件内容检查
Microsoft SQLMicrosoft SQLMicrosoft SQLMicrosoft SQL
MongoDB System HealthEstado del sistema de MongoDBРаботоспособность системы MongoDBMongoDB 系统健康状况
MySQLMySQLMySQLMySQL
Oracle SQLOracle SQLOracle SQLOracle SQL
Passive Application PerformanceRendimiento de aplicación pasivaПассивная производительность приложений被动的应用程序性能
PingdomPingdomPingdomPingdom
POP3 Email CountCuenta de correo electrónico POP3Количество электронных писем POP3POP3 电子邮件计数
SCVMM HostHost de SCVMMУзел SCVMMSCVMM 主机
SCVMM Virtual MachineEquipo virtual SCVMMВиртуальная машина SCVMMSCVMM 虚拟机
SNMP GSA System HealthSalud del sistema de GSA con SNMPРаботоспособность системы GSA по SNMPSNMP GSA 系统健康状况
Virtuozzo Container DiskUso de disco de contenedor VirtuozzoДиск контейнера VirtuozzoVirtuozzo 容器磁盘
Virtuozzo Container NetworkRed de contenedor VirtuozzoСеть контейнеров VirtuozzoVirtuozzo 容器网络
WBEM CustomWBEM PersonalizadoНестандартный запрос WBEMWBEM 自定义
Windows Last Update (Remote Registry)Última actualización de Windows (Registro remoto)Последнее обновление Windows (удаленный реестр)Windows 上次更新 (远程注册表)
Windows Logged In UsersUsuarios registrados en WindowsВошедшие в Windows пользователи已登录 Windows 用户
Windows Physical DiskWMI disco físicoФизический диск WindowsWindows 物理磁盘
Windows RegistryRegistro del sistema de WindowsРеестр WindowsWindows 注册表
Windows Scheduled TaskTarea programada WindowsЗапланированная задача WindowsWindows 计划任务
WMI Logical DiskWMI disco lógicoЛогический диск WMIWMI 逻辑磁盘
WMI Volume FragmentationFragmentación de volumen WMIФрагментация тома WMIWMI 卷碎片
WMI Windows VersionWMI Version de WindowsВерсия WMI WindowsWMI Windows 版本

Created on Feb 5, 2016 2:46:28 PM by  Gerald Schoch [Paessler Support]

Last change on Jun 14, 2022 8:45:14 AM by  Brandy Greger [Paessler Support]



Votes:

0

Hi,

we have a lot, I mean A LOT of SQL sensors. Will there be an automatic conversion while upgrading the software and will the historic data be available? What happens to the API because all those sensors are part of our CMS and billing solution.

Mario

Created on Apr 5, 2016 11:21:27 AM



Votes:

0

Hello,

You can pause the old SQL sensors indefinitely, this way you can keep the historic data and those sensors are not counting against the license limit.

There is no way to migrate existing SQL sensors to the new version. If you are using just one query for all SQL servers, you only need to create one SQL query file. If you have several different queries, I am sorry, that will be some work.

To get a list of all SQL sensors, you can use this API call:

/api/table.csv?content=sensors&columns=objid,name&count=*&filter_tags=@tag(sqlsensor)

If you iterate over the objectids, you can read out the according SQL statement. If you have an SQL sensor with the objectid 2123, the API call looks like

/api/getobjectproperty.htm?id=2123&name=sql

The result also contains the PRTG version number, you need to cut that part from the result.

The new SQL sensor type allows up to 10 channels.

Created on Apr 7, 2016 11:02:47 AM by  [email protected]



Votes:

0

I have run into a problem which might hopefully lead you to change your plans regarding retiring the "Windows Scheduled Task" sensor.

The alternative sensor you're pointing people to (ScheduledTask2XML.exe) doesn't seem to be able to be used to monitor scheduled tasks on the same server where the probe is running. Said another way, each probe is unable to monitor it's own scheduled tasks with this sensor.

Please keep the "Windows Scheduled Task" sensor in the product. Surely anyone with PRTG and scheduled tasks would use PRTG to monitor whether they're working or not.

When the ScheduledTask2XML.exe sensor tries to connect to the local server's registry to read the task information it is denied access.

Another problem with this sensor is that it seems to me that it forces people into 1 of 3 choices:

  1. stop using PRTG to monitor Windows scheduled tasks
  2. save account password information in the sensor configuration
  3. use the PRTG Tools Family PassHash Tool to generate a password hash and store that in the sensor configuration. This is a security risk since it's not clear what that tool might do with the password. In theory, it could be a password fishing tool.
14.3.1.1
Check if Remote Registry Service is running.
Remote Registry Service is running.
<?xml version="1.0" encoding="utf-8"?><prtg><error>1</error><text>Access is denied. (Exception from HRESULT:  x80070005 (E_ACCESSDENIED))</text></prtg>

Created on Apr 8, 2016 7:39:10 PM

Last change on Apr 18, 2016 7:27:06 AM by  Luciano Lingnau [Paessler]



Votes:

0

Hi, Why are you removing "Windows Logged In Users" sensor ?? We are really going to mis it. Whole day im trying to replace it but still no result. I tried UsersLoggedinXML sensor from PTF but is does not give the result that i want..... The logged on usernames are displayed as a channel. I want the username as a message like it was before. We are presenting the usernames on a map and with 'channel' this is not possible.

Created on Apr 13, 2016 1:44:43 PM



Votes:

0

"Windows Logged In Users" is one of our most used sensors where we are monitoring over 60 RDS-Servers in different domains. I also tried the UsersLoggedinXML-Sensor (where configuration is a pain in the a... when using different domains) and the WMI terminalserver sensor but neither result is in any way satisfying. So maybe you/Passler could rethink, removing the sensor.

Best wishes anyway!

Created on Apr 14, 2016 6:22:03 PM



Votes:

0

Hi,

Any reason why MongoDB System Health is being removed? We are using this sensor quite extensively.

Thanks

Created on Apr 15, 2016 5:38:03 AM



Votes:

0

The new MYSQL v2 sensors are not very user friendly. Old sensor capability was EPIC ie. Do a count(*) on a table, if the result set is above x, then WARN - if above Y then DOWN Current new way of doing it, I don't even know where to start !!!

Created on Apr 15, 2016 9:52:13 AM



Votes:

0

The new sensor is not that much more complicated:

  1. Modify the query:
    SELECT COUNT(*) AS count FROM users;
  2. Save it as count_users.sql in the corresponding database folder under Custom Sensors
  3. Create a new MySQL v2 sensor
  4. Enable Process Data Table
    - Select Channel Value by: Column Name
    - Sensor Channel #1 Name: Count
    - Sensor Channel #1 Column Name: count

Sure, not as simple as with the old one, but you have much more possibilities and evalution options. Additionally, it has another layer of security by not making it possible to change queries without access to the actual file system.

Created on Apr 15, 2016 11:58:44 AM by  Stephan Linke [Paessler Support]

Last change on May 25, 2016 11:57:19 AM by  Johannes Herrmann [Paessler Support] (1,360) 2 2



Votes:

0

Dear tswanepoel

The MongoDB sensor was deprecated because the usage rate is very low. I am sorry that your installation is affected.

Created on Apr 15, 2016 5:00:44 PM by  Arne Seifert [Paessler Support]



Votes:

0

rschminke, I'm very much afraid, due to the very low usage rate, there are no plans to keep the "Windows Logged In Users" - Sensor. Please consider to get in touch with PRTGToolsfamily with requests to the backup sensor, and any improvement that you'd like to see on it

Created on Apr 18, 2016 10:55:59 AM by  Torsten Lindner [Paessler Support]



Votes:

0

I fully understand that supporting unpopular sensor types may not be commercially viable. I therefore have no real issue with you deprecating and removing sensor types. However I'm not impressed by you providing your customers with 2 months between deprecation and removal. I have some ADO SQL sensors, for which "We plan a new version of the ADO SQL sensor as alternative." is this new version going to be ready before you remove the current ones? I'm also surprised that the Windows Logged in users sensor is being withdrawn. I have nearly 50 instances of this sensor.

This means that I have 2 months to write alternatives for three sensors that are currently working perfectly.

Created on Apr 18, 2016 1:42:22 PM



Votes:

0

I understand it is necessary to remove some sensors that are not used by many people or are hard to support in further versions - but don't you think it is way to complicated to add some MySQL-sensors now? I read about the security layer you want to put in there but I got about 60 MySQL-sensors to change to the new type of sensors now? I mean no one with the user permissions to edit sensors can edit them - that's enough security for some smaller instances like mine (about 200 sensors in total). I also can't damage anything on my database because the user for the monitoring doesn't have the permissions to update or create anything..

So I have to create a sql-file for every single sensor instead of just writing the statements directly in the sensor settings - much faster editing and creating.. I have to struggle with the credentials - if I got it correctly, I am only able to specify them for the whole device and not for the different sensors anymore (under the same device)? I can't see an option to specify the port on which the database is listening - especially not for different sensors under the same device?

If it is not really necessary to update and if the "new" sensors does not fully support anything I can do with the old ones, I think I won't update first...

edit: Now I found out I have to specify the port in the same option as the credentials, for the whole device. Did you ever think about servers with more than one database-instances running? It doesn't have to be several mysql-server-instances but I am using proxies to seperate some layers of accessing the database(s) and so I have to specify different ports and credentials for different sensors for the same device. Will there be any reasonable solution for that? I don't want to add a device twice or more times.

I hope you got my point - it is not very customer friendly to change that so hard.

Created on Apr 19, 2016 6:33:28 AM

Last change on Apr 19, 2016 9:15:11 AM by  Torsten Lindner [Paessler Support]



Votes:

0

I have created a .vbs script for reading the username. I placed the script in the C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXE folder. In PRTG i created a new EXE/Script sensor.

Set objWMIService = GetObject( "winmgmts:
.\root\cimv2" )
Set colItems = objWMIService.ExecQuery( "Select * from Win32_NetworkConnection" ) For Each objItem in colItems strUserName = Mid(objItem.UserName,9) Next

WScript.Echo "User Name: " & strUserName

It works when i locally run the script. I then get the correct username from the user who is logged on. But when the PRTG-sensor runs it it always shows the PRTG server username = \administrator

Does anyone know how to get the username from the device in PRTG????

Created on Apr 19, 2016 12:07:22 PM

Last change on Apr 20, 2016 5:41:19 AM by  Felix Saure [Paessler Support]



Votes:

0

The SQL Sensors appear to be quite a bit of work to change to their V2 equivalents.

The existing sensors allow the SQL to be entered in the SQL Expression edit box on the core server UI. The new V2 sensor has an SQL Query File selector, so we have to save the SQL to files, copy the correct files to each device where the probe is installed & select each one individually on the new sensor.

We have just under 200 SQL sensors currently, this is going to be very time consuming to migrate them all over. I think this new design is worse than the current one, each prove runs different SQL, so we will have to copy the scripts to each corresponding probe server.

Is there a better way of migrating them ?

Created on Apr 19, 2016 12:28:40 PM



Votes:

0

Old sensors probably won't have to be migrated, they'll continue to run. You'll just won't be able to create them anew.

Created on Apr 19, 2016 2:59:23 PM by  Stephan Linke [Paessler Support]



Votes:

0

Thank you Stephen, can we be sure they will run? The word "probably" is worrying me.

Created on Apr 19, 2016 3:41:32 PM



Votes:

0

Furthermore, the "Best Answer" from Paessler says "In version 16.x.25, the deprecated sensor will be removed from PRTG: If you still run deprecated sensors, these sensors will show an error and be in down status as of version 16.x.25. They will not provide any monitoring data as of this version!" - so I think they will NOT run. I'm a bit concerned that 2 answers from Paessler seem to be contradictory, unless I'm not understanding them both.

Created on Apr 19, 2016 3:46:35 PM



Votes:

0

Originally we planned to remove all deprecated sensors. Considering the work which is necessary to migrate SQL sensors manually, we decided to explore another option. What we intent is this:

Old SQL sensor will still run with 16.2.25 and later versions. They will be converted to "SQL deprecated" which is no longer covered by technical support, but they continue to function. All deprecated non-SQL sensors however will be completely removed.

Some technical details about our new solution are not clear yet, this is why a definitive answer has to wait until we release 16.2.24 stable.

Created on Apr 19, 2016 7:12:31 PM by  Arne Seifert [Paessler Support]

Last change on Apr 19, 2016 7:14:22 PM by  Arne Seifert [Paessler Support]



Votes:

0

This is a good beginning but some questions are still not answered..

How can I specify different credentials and ports to some sensors for the same device? I tried it with the MySQL-V2-sensors only - but here I have to specify credentials and ports in the settings of the device - that is not applicable!

The point is, the "old" sensors will continue running in further versions. But I am sure I have to add some sensors in future - the IT is growing forever and the "problem" with the new sensor(s) is not away, it's just moved to the future!

Should I open a new case/topic?

Created on Apr 20, 2016 6:06:53 AM



Votes:

0

Thank you Arne. :)

Created on Apr 20, 2016 9:19:15 AM



Votes:

1

Dear jdehn

You are right, the 'problem' is moved into the future. SQL v2 sensors get their credentials and the port from the device. This is consistent with the PRTG object hierarchy. As an upside, an SQL v2 sensor offers up to 10 channels.

More details about the planned "SQL deprecated" sensor type should be available when the 16.2.24 version is stable.

Created on Apr 20, 2016 10:43:11 AM by  Arne Seifert [Paessler Support]



Votes:

0

I have to put in a plug for the "Last Windows Update" sensor. I understand the replacement sensor is much more informational, but it's also really quite resource intensive as it's based on a powershell execution. Honestly, the detailed data reported by the newer Windows Update Status sensor is much more than we would ever need, and all of those metrics are available in the WSUS console anyway. The simplicity of a basic registry query showing the last windows update date is much more appropriate to a monitoring platform. I actually had gone to the trouble of removing all of the Windows Update Status sensors and replacing them with Last Windows Update because the powershell backed nature of the new sensor made returns inconsistent at best and led to delays on the whole probe server. I'd be curious to know if others had similar feelings and whether there was any chance of keeping the old sensor around, though I know that's not at all likely based on my post here. It's just very disheartening as the powershell probes are woefully inconsistent and reliable.

Created on Apr 20, 2016 1:53:31 PM



Votes:

0

"Windows Scheduled Task" sensor was one of the reasons why we decided to use PRTG Please if possible let the sensor supported

Created on Apr 21, 2016 6:35:39 AM



Votes:

0

Hello,

I am afraid that at the moment there are no plans for 'revival' of "Windows Last Update (Remote Registry)" and "Windows Scheduled Task" sensors, sorry.

Best regards

Created on Apr 21, 2016 12:58:36 PM by  Isidora Jeremic [Paessler Support]



Votes:

1

Hi,

Just to add support for not removing the SQL sensor and replacing it with one where you are forced to maintain a separate set of script files.

In almost all of our SQL sensors we utilise stored procedures which are all in a utility DB, meaning our script files would just be another level of maintenance.

Please reconsider the removal of the SQL sensor.

Kind regards, Calum.

PS. I'll add another vote for keeping the Windows Scheduled Task sensor, but we only use one, so it's not a big issue.

Created on Apr 21, 2016 1:37:19 PM



Votes:

0

Thank you Calum - I didn't think of that! You are right, we are just using stored procedures too and the script files I would need for the new, great sensors, would just contain the call for the stored procedure..

I don't know how that will improve security.. It's really just another (way to complicated) step at managing the sensors.

Do you really want to remove them?

Best regards, jdehn

Created on Apr 22, 2016 8:02:53 AM

Last change on Apr 22, 2016 9:18:11 AM by  Torsten Lindner [Paessler Support]



Votes:

0

Yep, no chance. The SQL sensors probably won't be removed in the sense of deleted, but you'll be unable to create them anew. You probably will be able to configure existing ones entirely and clone them, though. At least, that's the current plan for now.

Created on Apr 22, 2016 11:46:24 AM by  Stephan Linke [Paessler Support]

Last change on Apr 22, 2016 11:46:54 AM by  Stephan Linke [Paessler Support]



Votes:

0

What I like about the v1 SQL Sensors, because we have a lot of them created by different engineers, is the ability to quickly see what underlying SQL code is by looking at the sensor settings. The v2 SQL sensors just give the name of the script file they are in - which can be misleading.

Created on Apr 22, 2016 1:12:30 PM



Votes:

0

First I want to state that understand the reason of the necessity to deprecate sensors. There is always a fight between amount of features and cost to support them all.

To deprecate a old one and create a new, is most of the time reasonable, but loosing statistics and baseline information, changing reports and maps is an unexpected nightmare.

But at the end, one reason I've decided to use and promote Passler for more than 5 years is the very large number of sensors and features Passler offered. The ratio of Cost and Feature was fantastic.

Probably is reasonable to let all the deprecated sensors to function for longer period (even without support). But I also don't agree on short the time we have to migrate.

The way SQL V2 sensor is planned to use queries is a nightmare. What do we increase in security by adding the need to access the Sensor File System? With the profiles we have in the system is more that enough to protect the query. If you need to protect the query encrypt them (when stored).

One question: How do you know who is using a specific sensor or not do make a decision to deprecate him or not?

Created on Apr 22, 2016 6:41:50 PM



Votes:

0

Thanks for promoting PRTG for such a long time, we really appreciate this :)

The SQL sensors probably won't be removed (like, not deleted), but you'll be unable to create them anew. You probably will be able to configure existing ones entirely and clone them, though. At least, that's the current plan for now for the SQL sensors.

Every PRTG installation sends anonymized statistical data, so we have an overview of how PRTG behaves "in the field" and what sensor types are used and how many of them. However, removing the SQL sensors hurt more people than we originally thought, hence we've decided to go a slightly different way :)

Created on Apr 25, 2016 9:35:51 AM by  Stephan Linke [Paessler Support]



Votes:

0

One of the significant reasons that we chose PRTG for our enterprise-wide monitoring system was that it included so many sensor types and that we did not need to devote resources to develop and manage custom sensor configurations. I do not know how you determine if a sensor has low usage but, from our viewpoint, shifting development and management costs to the customer diminishes the value that helped PRTG win out over other monitoring tools.

I can understand sensor removal if there are security issues or if the sensor has a design flaw but removing sensors just because you don't want to support them anymore is not a good marketing or technical decision.

Created on Apr 25, 2016 4:35:06 PM



Votes:

0

Another point just got in my mind, maybe someone else mentioned it already..:

You want to increase security by adding the needed access to the file system of the probe. How does that increase security? Let's say I have about 5 colleagues adding sensors. I added a user for each of them und gave them the rights to adding sensors to some groups or devices.

But now I have to give them access to the filesystem? I don't know how you think about that, but I don't think that is very secure to give everyone access to the filesystem who have to create MySQL-sensors..

Do you get my point?

I switched the automatic update off, just in case...

Thank you and best regards, jdehn

Created on Apr 26, 2016 6:45:57 AM



Votes:

0

Tom, with the usage statistics on PRTG, we only remove sensors that already have a replacement, or have usage rates below 0.1% of all PRTG installations worldwide. We also know that removing some old sensor types puts some burden on our customers. We are sorry for that, but it is for a good cause: It allows us to remove very old, hard-to-maintain code and some outdated libraries/dlls from PRTG’s code base, which will result in less load on our developers for maintaining this old stuff. Less distraction by old stuff (which is only used by <0.1% of our customers) means that we can invest the freed-up-time on things that many more customers will profit from, including you.

We always try to look at this from a bird’s eye view and we try to balance between the needs of all customers and our team’s resources. This time we needed you and a few other customers to help the PRTG community in this process.

Created on Apr 26, 2016 11:42:47 AM by  Torsten Lindner [Paessler Support]



Votes:

0

jdehn, the security with the script files has to be on the access level to the machine of course, so the human factor is indeed involved. We want this to be a conscious decision, who has access to the machine running PRTG. Even if that means you may have to build a process here, where only certain persons (and not each DB-Admin, with general access to PRTG) have full access to the PRTG host.

Created on Apr 26, 2016 11:45:27 AM by  Torsten Lindner [Paessler Support]



Votes:

0

Hi,

I am wondering why it was nessesary to deprecate the SQL-Sensors - they are not below the 0.1% for sure, and this is the reason they got replaced I guess. I'd really like to understand the reasons for getting a new created sensor. I see the benefits it brings, with better possibilities regarding data processing.

What I do not understand is storing the query outside of the product. Using the file system for this is a bad decision in my eyes, as it makes working with the sensor more complicated. Here we have clearly seperate responsibilities for the servers hosting the software and maintaining the software itself - I guess this will be in most IT depts with more than a few people. Also it is much more complicate to change or even check a query of course, even when having access. It also results in problems when all persons resposible for SOME of the sql sensors have full access to the folder that contains ALL querys. What is your viewpoint doing this ?! What was wrong with the input box and saving it as a part of the configuration and let the permission model do its job?

Another thing that annoyes me: I am not able to change the used sql query file afterwards, and also not able to change sensor channels. What is the reason for that ?!? Why should I be forced to create a new sensor, resulting in lost of my historical data?

So you see, also from all the other posts: I guess you are working in another way with your product than some of your CUSTOMERS do, and I think you could get more satisfied customers when you (at least) let them UNDERSTAND your decision, and get a valuable dialogue on this topics.

Regards Dominic

Created on May 10, 2016 9:37:27 AM



Votes:

0

Dear Dominic

Thank you for your input. Even though we don't respond to any posting, we read every posting as we are happy that a user took the time to provide his perspective.

The SQL v2 could have been done differently, with a different set of advantages and disadvantages.

This is something we are aware of: Some users will not like the philosophy of our new sensors. However the new SQL v2 sensors follow our tried-and-true Exe/Script philosophy: Executing commands requires physical access to the according computers. This is an extra layer of security we deem more important than offering the convenience of the deprecated SQL sensors.

We are still listening to PRTG users and are working on SQL v2 improvements to make the sensor easier to use. We re-introduced the rowcount option in 16.2.24 and allow @-variables because of the feedback we got. However we no longer want to support sensors in which a PRTG user enters his custom query and possibly accesses data he is not supposed to see.

We consider the PRTG administrator, who also has physical access to the PRTG server, the right person to enter and review SQL statements. If you need to split the access rights to SQL file, please use remote probes. (The SQL v2 sensor only can use files present on the according probe.)

Channel management poses some special issues for this sensor type.

Deprecating the old SQL sensors is part of a greater good: We are getting rid of very old sensors which are hard to bugfix and hard to keep up-to-date. The new SQL v2 is much more robust and compatible.

Created on May 10, 2016 12:57:11 PM by  Arne Seifert [Paessler Support]

Last change on May 10, 2016 4:11:22 PM by  Arne Seifert [Paessler Support]



Votes:

0

Hi,

It looks like with the new Microsoft SQL v2 Sensor the Database User/Passwort is only possible to set in the Device, not anymore on the Sensor. This is a bit unhappy for us, as we run on some server many Database with different users/passwords, and not really want to intruduce a monitor DB-User.

Any Idea, how i can use the MSSQL v2 Sensor with more than one DB-User on a device?

Cheers Oliver

Created on May 18, 2016 6:16:31 AM



Votes:

0

Dear Oliver

The new sensor always uses the credentials from the device. If you have different users, you need multiple devices.

The old sensors were introduced when a device had no database credential setting. The new sensor follows the PRTG philosophy that device address and credentials are inherited from the device.

Created on May 18, 2016 12:02:43 PM by  Arne Seifert [Paessler Support]



Votes:

0

Hi there,

In all honesty, i'm not sure i can agree with the argument that if a feature is little used, it should be removed from the supported list of monitored tools, since the main selling point of prtg is that it supports a wide range of sensors. This decision seems a bit absurd to me. You wouldn't burn the little read books in a library neither or demolish roads to villages where "only a few people live" ;-)

We rely on the mongodb and sql sensors for some critical services, and if they get removed we will simply be forced to look at alternate monitoring tools, implicitly raising the question whether we should stay with PRTG at all or not. Not to mention the risk of staying with PRTG: what if further crucial tools are deemed unpopular by a decision maker at paessler in the future? Should we invest in something that is volatile?

Please reconsider the retirement of the mongodb sensors (i see some folks already made noise about sql, just consider me a +1 there). Or at least, consider opensourcing the retirees in one way or another, so we can carry on maintaining them ourselves, somewhat reducing our risk.

cheers, Laszlo

Created on May 30, 2016 11:01:55 PM



Votes:

0

Dear Laszlo

With the right provider, MongoDB can be accessed via ADO and hence be used with the ADO SQL v2 Sensor.

Explaining development decisions can be complicated as the full picture is quite large. Implementing / testing / documenting the MongoDB sensor was a bit of work, even though it shares a lot with our general SQL v2 sensor engine and existing general SQL v2 documentation. Still, it was not easy to decide to cut the sensor, as we put some effort in. We saw overall very little use of the dedicated MongoDB sensor. In a book library, you can just keep the existing books. In PRTG, every part of the software needs to be maintained and sometimes revised. The usage rate of this sensor did not justify that.

This was a learning process for us as well. We are now more careful when we introduce new sensors.

In case of MongoDB, there were outside effects as well: Beginning with version 3.2, MongoDB deprecates the HTTP interface. That is the interface which we used for the sensor.

Created on May 31, 2016 8:10:49 AM by  Arne Seifert [Paessler Support]

Last change on Jun 1, 2016 11:08:07 AM by  Arne Seifert [Paessler Support]



Votes:

0

Thanks for the explanation Arne, knowing more about the decision making process and the context helps, I was not aware that mongoDB is deprecating the HTTP interface. We will look at ADO SQL v2 and see if that works for our needs.

Created on May 31, 2016 5:31:02 PM



Votes:

0

Hello, we have more than 500 "Windows Last Update" (Remote registry) sensors installed in our environment. One per monitored server and we use this sensor to plan Windows Update We could use the new sensor (powershell) for our new servers but replacing the existing sensors will be a huge stuff and painful. Is it possible to only depreciate this sensor and not removed it in next version of PRTG ?

By advance thanks

Created on Jun 8, 2016 7:34:03 PM



Votes:

0

Dear ecucchietti

I am sorry, with the exception of SQL v1 sensors, deprecated sensors will not work with the upcoming 16.2.25 version.

You can setup a Windows Updates Status (Powershell) Sensor and create a device template which includes only this one sensor (either use an otherwise empty device or exclude the other sensors when saving the device template.)

You can now multi-select devices (either by Devices / Device List, or via the management tab where you see the combined settings of the selected devices on the right-hand pane) and enable the auto-discovery and select the template you just created.

Created on Jun 9, 2016 11:39:29 AM by  Arne Seifert [Paessler Support]



Votes:

0

For those of us who, unfortunately, still have 2003 servers (due to old software that we can't move), what options do we have for monitoring Scheduled Tasks in 16.2.x and up?

Created on Jun 22, 2016 8:48:02 PM



Votes:

0

Dear Peter

We really don't support 2003 anymore. Maybe you are able to monitor scheduled tasks on 2003 servers with a custom script, but we offer no technical support in this regard, I am sorry. We understand that some networks still operate 2003-based servers and we try to keep backward compatibility if we can. Sometimes we have to cut support for outdated devices (another example is old ESX versions.)

Created on Jun 23, 2016 9:29:52 AM by  Arne Seifert [Paessler Support]



Votes:

0

Have you considered adding an option to the new Powershell-based Windows Update sensor to instead just pull the date out of the registry instead of enumerating update counts?

I’ve seen the same performance issues with the Powershell-based Windows Update sensors that have been mentioned by others above. Given that Server 2012 R2 makes monitoring Remote Registry much more unreliable, I can understand why the sensor was deprecated but the Powershell sensor doesn’t really replace the functionality it provides.

I know that in many of the PRTG installs I’m responsible for I’ve gone through the effort of intentionally replacing any auto-discovered Powershell-based sensors with the simpler Remote Registry sensors.

Going forward I will likely need to remove these sensors from my deployments wholesale as the resource strain it places on both the probe and the monitored machines isn’t acceptable. Having the option to “dumb down” the data the sensors collect would likely resolve this problem.

Created on Jul 20, 2016 1:05:04 PM



Votes:

0

Dear jsanders

We are aware of performance issues, but these are caused by Windows or WSUS, taking too long to respond. Dumbing down the sensor is not as easy, we would need to introduce a new sensor type for Windows updates. This is not something we have on our radar right now as we are currently focusing on other sensors and features.

As we constantly look on all parts of PRTG, we will have a decision about the Windows Update Status sensor at a later time.

Created on Jul 20, 2016 3:13:58 PM by  Arne Seifert [Paessler Support]



Votes:

0

Hello

"ScheduledTask2XML sensor"

manual.html is empty, got two files .ovl and .exe no idea what to do with.

Created on Jan 11, 2018 9:10:55 AM



Votes:

0

Hello Yann,

the sensors comes from PRTG Tools Family. I just checked the downloadable files and they appear to be functional. The manual, which describes the necessary steps in regards to the ovl files, can also be found here.

Best regards,
Sebastian

Created on Jan 11, 2018 3:50:50 PM by  Sebastian Kniege [Paessler Support]




Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.