SEP 12.1 scan retry resets scan schedule

If a scheduled scan uses the missed scan option to start a scan within x hours or days after the scheduled time, then if it starts within thi sretry range, all future scans of this job will start at the time of the last successful retry. This negates the planning done to schedule scans such that they run at acceptable hours and means that there is no way to know on an enterprise level when scans will start. Scheduled scans can be highly sensitive a sthey have potential to disrupt business process and require control. There should be an option to prevent this behaviour.

not sure why this got a thumbs down - how can providing customers options to control the scan behaviour be a bad idea? Especially when it is to handle a significant change in scan behaviour. Unless there are users out there who enjoy scans kicking off at random time sduring business hours - I guess they cant be doing anything that might be disrupted by this behaviour. It would help if the thumbs down was accompanied by a reason for this opinion.

yes, one can remove "retry missed scans", but that would have the effect of reducing the number of scheduled scans that run in the estate. The changed scan retry behaviour has put customers, who cannot afford to have scans kicking off at unpredictable times during the business day, in a worse position than before. What I do not know is whether this affects just the SEP 12.1 client or SEP 11 as well.

I am still wondering why this got a thumbs down with no explanation. Perhaps there is a tendency to vote other peoples' new ideas down so that other ideas get more attention? Hope that is not the case, but I do feel any vote without an explanation carries no weight. This isnt a secret ballot, but a tech forum; we share ideas and thoughts openly : )

If an end user has the ability to run and postpone a scheduled scan, he or she can postpone it indefinitely and the SEP client scheduling would almost be non-existent. And for randomizing or postponing a scan at another random schedule could mean that the scan would start at your most undesired time to slow down the server.

I'm sure that older versions of AVs regardless of name-brand has a definite scan time and admins get around that problem by discussing the perfect time of the week to run a full scan. And while not taking into account the leniency of today's AVs on scheduling, it should be the admin's responsibility to know when that ideal time should be and changing scedules is straightforward. Moreover, there are scan options that would prioritize either the AV or other running processes.

the issue is that the design of the scan retry appears to be flawed and we as admins have no way to change this new behaviour introduced by SEP 12 in admin policy. The result is that scans may run less frequently than expected.

For example - a client runs a daily administrator-scheduled scan on 10 Feb at 23:00, even though the scheduled time is 02:00 - this is because SEP12 remembers the last successful scan and uses that as its new target scan start time. Scan retry is 8 hours in my test case. At 23:00 on 11th Feb the machine is switched off. Using retry of 8 hours, a scan would be retried if the machine were to be turned on up to 07:00 on 12th. However, the machine is turned off between 23:00 and 07:00 so no scan runs on 11th or 12th. Next target daily active scan reverts back to the policy setting of 02:00. Result: active scan does not run on 2 consecutive days - and this is by product design - surely this cannot be intentional. From my perspective a design flaw that needs to be addressed - at least give admins the power to choose scan behaviour, as requested when I initiated this post.