As soon as possible option of scheduler (continued)

[AGH1965 12]

In December I started a topic about the as soon as possible option of the scheduler. Unfortunately that topic has been closed. So I can't add any new comments. You can find the original topic here: link

Apparently ESET modified the as soon as option of the scheduler of EIS version 12.2.23.0, but unfortunately the problem hasn't been fixed. Here are my findings:

If consecutive scheduled daily scans can't run at the scheduled time, then the scan will only be done as soon as possible if the previous scan was at least 24 hours ago. If that is not the case yet, then EIS will wait until it is. (In previous versions the threshold was 23 hours.)

If consecutive scheduled weekly scans can't run at the scheduled time, then the scan will only be done as soon as possible if the previous scan was at least 7 whole days ago, i.e. 7 times 24 hours. If that is not the case yet, then EIS will wait until it is. (In previous versions the threshold was still 6 days and 23 hours.)

So ESET clearly made changes to the as soon as possible option of the scheduler, but unfortunately the problem hasn't been fixed. As soon as possible still isn't as soon as possible for the scheduler of EIS version 12.2.23.0. In fact, it became worse. Users now have to wait an additional hour before a missed scan is finaly executed.

ESET, please try again!

 

[Marcos 5,074]

Please contact your local distributor. There are plans to overhaul the Scheduler, however, since it's a daunting task I assume that it won't happen before v14 at earliest.

[itman 1,659]

My own recommendation is just use Eset's command line utility noted here: http://support.eset.com/kb3417/?viewlocale=en_US and create the scan using Windows Task Scheduler.

[AGH1965 12]

3 hours ago, Marcos said:

There are plans to overhaul the Scheduler, however, since it's a daunting task I assume that it won't happen before v14 at earliest.

Thanks for your reply, but it doesn't make sense. If someone is able to increase the threshold for daily scans from 23 to 24 hours, then that person must also be able to reduce it to (almost) 0 hours. So what is the problem?

 

53 minutes ago, itman said:

My own recommendation is just use Eset's command line utility noted

You suggested that already in the other topic. Personally I don't like the command line scanner. I would prefer triggering the normal scanner from the command line, but that is a missing feature.

[AGH1965 12]

@Marcos It's a pity that you didn't reply. Please explain me why the scheduler of v12.2.23.0 was modified in such manner that the already existing problem became larger instead of smaller.

I do understand why the scheduler may not be fixed before v14, but if that is the case, then please undo its modification of v12.2.23.0.

However, an acceptable compromise could be making a similar modification as made in v12.2.23.0 but then in the opposite direction. For example: Reduce the threshold for missed daily scans, which was 23 hours and is 24 hours now, down to 4 hours. That still will not fix the scheduler completely, but it will make it much better than it is now.

[Marcos 5,074]

I'm not aware of any changes in Scheduler in v12.2.23. I'd recommend contacting your local customer care and opening a support ticket so that the issue is properly tracked and examined by developers, if necessary.

[AGH1965 12]

@Marcos, why if necessary? I'm not the only person who reported scheduler problems. Also a very much appreciated forum member named @itman did.

Why do I have to do something to make ESET fix a problem that was reported by several people at this forum? So ESET simply ignores the information received from customers at this forum?

[Marcos 5,074]

As already mentioned several times here, this forum is not meant to be a substitute of contacting customer care. Issues that need further troubleshooting, reproduction, further diagnostic logs, etc. require that the case is tracked properly in the ticketing system also for further interaction with developers. Forums in general do not have the capability of tracking cases, hence raising a support ticket is needed.

[itman 1,659]

2 hours ago, AGH1965 said:

Also a very much appreciated forum member named @itman did.

I solved the problem by simply not having any scheduled scans.

Personally, I believe many using Eset are "scan crazy." Since Eset's real-time protection scans files upon creation and again at execution time, additional off-line scanning really is not necessary.

For those that insist on daily scanning of all drives, a good alternative is to use the "Idle time" scan option. This will result in files being continuously scanned when the device is in an idle state.

[AGH1965 12]

4 hours ago, itman said:

Since Eset's real-time protection scans files upon creation and again at execution time, additional off-line scanning really is not necessary.

Using the scheduler for scans wasn't my own idea. Please see the note at the bottom of this support page. So ESET advices to scan at least once a month and the link in the note shows how to configure the scheduler for a weekly scan with "as soon as possible" option activated. That is exactly what I did when I discovered the scheduler problems. (Only for testing the scheduler I switched to daily scheduled scans.)

[AGH1965 12]

7 hours ago, Marcos said:

As already mentioned several times here, this forum is not meant to be a substitute of contacting customer care.

It would be much more logical if ESET customer care employees would watch this forum thoroughly and create support tickets themselves for everything more serious than an assumption.

[itman 1,659]

2 hours ago, AGH1965 said:

It would be much more logical if ESET customer care employees would watch this forum thoroughly and create support tickets themselves for everything more serious than an assumption.

The forum's primary purpose is to help Eset users with installation or operational issues. As far as bugs and the like, it is very much a hit or miss issue if they ever get fixed. It all depends on if the Eset moderator responding will forward the issue to Eset development for further analysis. On the other hand, opening a support ticket is a "mixed bag," I have had excellent assistance and I have had otherwise.

As far as product problem resolution, what I have observed is Eset has the following priority; security vulnerabilities, severe operational issues, and everything else. Some requests although being hinted at multiple times in the forum as to be implemented in the near future, never get implemented.

Bottom line - if whatever issue is bugging someone to the point where it becomes intolerable, they are better served by using a different security product.

Edited August 14, 2019 by itman

[Marcos 5,074]

Quote

Some requests although being hinted at multiple time in the forum as to be implemented in the near future, never get implemented.

Could you please provide some examples? We actually listen to the feedback from users and do our best to tailor the products to their needs. We implement desired features if they are reasonable and are not "expensive" in terms of resources and (or) time. Features that cost resources and time need to be planned longer time ahead and have to be approved internally at several levels.

For instance, ESMC is basically all based on users' requests and demands that were collected during personal meetings of product managers and other staff responsible for product development with big customers before the development of ESMC started as well as during the development of future versions.

[itman 1,659]

2 minutes ago, Marcos said:

Could you please provide some examples?

HIPS file wildcard support!!!

[Marcos 5,074]

6 minutes ago, itman said:

HIPS file wildcard support!!!

This improvement is not an easy task and the devs have been working on high priority tasks related to ML and Behavior monitor. As I already mentioned, it's on the wish list and should be implemented as soon as there are resources available for this. Also given that not many users use custom rules and it's not anything critical, the improvement has lower priority.

[itman 1,659]

6 minutes ago, Marcos said:

This improvement is not an easy task

Personally, I don't buy this. There are multiple free HIPS like products on the market that have extensive wildcard support. This capability is far from "rocket science."

[AGH1965 12]

19 hours ago, Marcos said:

We implement desired features if they are reasonable and are not "expensive" in terms of resources and (or) time. Features that cost resources and time need to be planned longer time ahead and have to be approved internally at several levels.

If you can do this for features, then why not do it for bugs as well?

Reducing the time thresholds that the as soon as possible option of the scheduler uses when scheduled scans are missed consecutively, is very simple to do and therefore cheap. It would not fix the as soon as possible option, but it would make it much easier to accept.

So I suggest you treat this proposal as a feature request and then it can be implemented soon.