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

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.

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>

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.

"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!

Hi,

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

Thanks

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 !!!

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.

Dear tswanepoel

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

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

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.

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.

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????

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 ?

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.

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

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.

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.

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?

Thank you Arne. :)

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.

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.

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

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

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.

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

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.

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.

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?

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 :)

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.

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

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.

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.

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

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.

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

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.

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

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.

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.

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

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.

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?

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.)

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.

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.

Hello

"ScheduledTask2XML sensor"

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

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