Scan performed every login after moving to new ERAS isntall

I've just run into an interesting problem. We're still running NOD32 v2.7. I just moved from RAS 1.0.x to ERAS 3.0.105. It was not an upgrade - it was installed on another server, all new configuration files were created, tied to policies, etc. When we were ready to move the clients, we created a new configuration task on the old server that removed scheduled events, and pointed it at the new ERAS for remote administration, where they picked up the new configurations.

I set our laptops to scan every Sunday, and if missed, scan as soon as possible. That, and a dual-profile update are all that I scheduled. Now, a scan is performed every time a user logs on. Anyone run into this before or have any pointers? I've checked the schedule a number of times, and everything appears correct.

 

If you change the scheduled scan to not scan if it was missed, does this keep the scan from starting each login?

 

It's not actually the logon that's kicking off the scan, it's start/restart that is doing it. That's an error on my part. I was working on a few laptops, I guess I wasn't waiting long enough, and didn't see the scan kick in without logging in.

I changed the schedule to not scan if the scheduled time is missed, and the scan at startup doesn't present itself now. That's not good. I need that working. Has anyone else run into issues with this before?

 

Have you tried letting the scan finish without cancelling it and then restarting to see if it kicks off again? The software may see the scheduled scan created but not run yet and so it's running it now because it thinks it missed the last scan.

 

Yes, I have. Most of the laptops are in the hands of users who don't have sufficient privileges to cancel a scan. I'm showing some laptops with 3-4 completed scans in a day.

I need to re-visit the logon/startup issue as well. It seems that some machines, like the one I had yesterday, only initiated a scan during startup, while others perform a scan at logon.

 

If you compare the locally viewable schedule on the workstation to the schedule in the "view merged" client policy, are they identical?

I recommend exporting the configuration from the client, saving the configuration from configuration editor, and comparing them using the DOS 'fc' command. Things like different hexadecimal TaskID numbers for scans will cause task duplication, and the 'obvious' way to remove them just causes even more duplication.

You need to aggregate all of the hexadecimal TaskID numbers for all of the scans currently scheduled on your workstations, then build a new policy that contains placeholder tasks with the same TaskIDs marked for deletion.

Then create one new scan, give it a meaningful, manually-assigned TaskID (so you can edit it later without causing duplication) and apply that.

 

I've already done this. Actually, I've recently started using the same ID in all of my config files for scheduled scans to avoid exactly this. If a new configuration is applied with a different scan schedule, it should overwrite the old scheduled scan instead of creating a new one, and leaving the old one behind.

Even so, I'm experiencing this issue on one machine that was freshly reloaded - a clean Windows XP install, with a clean NOD32 install. It can't be "leftover" settings causing the issue as there were none there to start with.

 

Here is a thread with a very similar issue if not the same. Problem with scans on start-up. Issue reguarding Policy Manager. Hopefully this will help.

https://www.wilderssecurity.com/showthread.php?p=1467420

 

Thanks ThomasC. That looks like exactly what I'm running into.