Multiple scans start when scheduled via ERAS

I've got another problem with ERAS now. Since updating ERAS to v3.1.11, all of my NOD32 v2.7 clients perform scheduled scans 2 times. My v3.0 clients perform scheduled scans 5 times. That sure bogs a system down fast.

Has anyone run into this? Know any fixes? I've checked the clients and they do not have duplicate scheduled scans.

 

This is a known bug that I reported a few months back. v4 does not exhibit that behavior and I will be upgrading shortly to get around this problem. The workaround has been to schedule scans every week manually for the clients, unfortunately. I didn't get an impression from them that they would be fixing this in v3.

 

This is getting ridiculous. Upgrading to ERAS 3 has been a nightmare. It's broken my v2.7 clients, it's broken the few clients I've moved to v3, and from what I've read about v4, I want to stay away from that for a good while.

 

The issue has been investigated and the cause found. A temporary workaround is to remove LastExec entries belonging to scan tasks from the configuration xml before applying it to clients. The problem shouldn't affect ERA2 as it didn't support policies.

 

This issue DOES affect v4.

We upgraded from v2.7 to v3 some weeks ago and found intermittently our clients were performing 10 on demand scans instead of 1. This hit the machine hard in regards performance and our users were pretty peeved off since scans were taking 4 hours instead of 20mins and during that time the machines were soooooooooo slow!!

I reported to Eset Support and they advised to upgrade to v4.

I have done this - and although the issue does not happen as often - i still find some clients running 2 or 3 scans instead of 1 - so I don't think v4 is completly fixed - although it is much better than v3.

 

Since the LastExec entry is the source of the problem in the policy, you may be able to get it working by directly editing the policy files located in C:\Documents and Settings\All Users\Application Data\ESET\ESET Remote Administrator\Server\cache\policy\
The .tmp files are just renamed .xml files and the filenames are useless so you have to do some text parsing to figure out where you need to be (hopefully you don't have too many policies), but I have had to similar things to get around a config editor GUI bug and it worked out alright. Just make sure you stop the RA service before you save the edited xml and then restart so the config change is parsed.

 

This is probably not the right place to ask this - but even though we have been using NOD for years - we have never used policies.

So - is a policies just like a config file but that is enforced? Is that the general gist of them?