Don't schedule On-Demand Scans with Policy

Discussion in 'Other ESET Home Products' started by SmackyTheFrog, Jan 27, 2009.

Thread Status:
Not open for further replies.
  1. SmackyTheFrog

    SmackyTheFrog Registered Member

    Joined:
    Nov 5, 2007
    Posts:
    767
    Location:
    Lansing, Michigan
    Just a warning to other admins using the policy features in 3.0.39, using the policy manager to schedule on-demand scans will result in multiple scans launching concurrently each time the client reports back in to the RAS until around 6-8 of the things are all scanning at once. It absolutely destroys system performance, so I would recommend not using policy for that one specific task until the issue gets sorted out.
     
  2. Geosoft

    Geosoft Registered Member

    Joined:
    Jan 7, 2009
    Posts:
    270
    Location:
    Toronto, Ontario, Canada
    Can you not specify a Scheduling ID code? that way it would just overwrite that particular scheduled task instead of making a new one.
     
  3. SmackyTheFrog

    SmackyTheFrog Registered Member

    Joined:
    Nov 5, 2007
    Posts:
    767
    Location:
    Lansing, Michigan
    I do specify the event id to match the one that was previously set in the cfg.xml file. The behavior you see is the exact same scan job being launched every five minutes each time a client reports back in to the RAS until you have around a half dozen of the things all going at the same time at which point it stops launching them.

    screwed_up_scans.png

    That's what it ends up looking like when you see the behavior on a RAS. There is a bug report in with Eset on this one, but for the time being I've just disabled scheduled scans through policy and create a manual task each week to do the scan which does not exhibit the same behavior.
     
  4. chcp

    chcp Registered Member

    Joined:
    Dec 14, 2008
    Posts:
    6
    Location:
    France
    Hi,
    We have the same bug, multiple scan when using scan policies with era. Our version of era is 3.0.105. Same behavior with 3.0.672 or 2.x clients
     
  5. SmackyTheFrog

    SmackyTheFrog Registered Member

    Joined:
    Nov 5, 2007
    Posts:
    767
    Location:
    Lansing, Michigan
    I ended up testing a v4.0 client at this issue was resolved there. My workaround for the time being is to manually schedule delayed scan tasks on a weekly basis until the new version is out and we migrate.
     
Thread Status:
Not open for further replies.