Scanning Woes

I waited on hold 47 minutes this morning . Usually my wait is around 25 minutes. Daniel was a nice guy as usual (didn't fix my issue), but I really don't have the time to wait on hold everyday so hopefully you guys can help me solve this.



My company has 1 scan task, it's set for Wednesday at noon. Target is "Hard Drives". My first issue is I had the weekly scan setup to run on first chance it gets if it fails. Every time someone reboots a computer in the company a full scan starts. If you look under Scheduler, you'll see that for some reason a full scan is never shown as completed, although it does, every week, for the couple hundred pcs around here. As a result every machine runs a new scan on boot, so I changed it to "Run on next scheduled time".

This morning I got a new fun issue, every computer in the company had two simultaneous scans running side by side. Both scanning the same files, both doing the exact same thing. Only things that have changed is the 424 client being pushed out, and me setting it to run on next scheduled time.

Are these related, is the scan failing so it's waiting till the next one, then kicking on a second one next to the one already scheduled?

 

The problem lies in the nature of ERAS Policies (inflexible enforcement) versus the configuration data stored by the task scheduler (self-modifying).

In this case there is a line in the XML data in the <TASK> section for that scan that, when saved from ESET Configuration Editor, looks like this:

FFFFFFFF is -1, which is never. Even when the task runs and the LastExec value is rewritten, the policy is changing this value back to -1 as soon as the client checks in with ERAS.

The reason it only seems to happen at reboot is because the data is only parsed when the ESET service starts or when a task actually executes. In reality, however, it is constantly being rewritten every time the client connects to ERAS.

A workaround to this is to save the XML data from ESET Configuration Editor, open it with a text editor, and delete the LastExec line from the file. Then you can load the file as policy and LastExec will not be a managed variable.

An alternative is to not use Policy Manager to manage scheduled tasks at all, and instead keep them in your installation packages or in single-use configuration tasks. If you do that, however, make sure you use a consistent TaskID value to avoid creating duplicate tasks.

 

I'm having the exact same problem. Do you know if this is being addressed for policy enforcement?