Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

SEP 12.1 scan retry resets scan schedule

Created: 28 Nov 2011 • Updated: 15 Aug 2013 | 17 comments
Serengeti's picture
3 Agree
1 Disagree
+2 4 Votes
Login to vote
Status: Implemented

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.

Comments 17 CommentsJump to latest comment

Serengeti's picture

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.

Thanks

0
Login to vote
kratzy1's picture

This scan behavior is one reason we will switching to another AV vendor, we have several systems that need to available during peak times.

0
Login to vote
John Cooperfield's picture

Until there is a patch, can you ameliorate by unchecking "retry missed scans?"  

Is this a "known issue?"  

Thanks

0
Login to vote
Serengeti's picture

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.

0
Login to vote
Sander Siemonsma's picture

I've also made this request a year ago to have more control over the retry windows. To do a scan at system startup for example. You've got my vote.

0
Login to vote
Serengeti's picture

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 : )

0
Login to vote
mon_raralio's picture

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.

“Your most unhappy customers are your greatest source of learning.”

0
Login to vote
Srikanth_Subra's picture

reallly if it retrys saves lot of time..

Thanks & Regards,

 Srikanth.S

"Defeat the Defeat before the Defeat Defeats you"
(Swami Vivekananda)

0
Login to vote
Serengeti's picture

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.

0
Login to vote
Elisha's picture

Thanks for your feedback.  I have brought this up to the development team.

0
Login to vote
Serengeti's picture

Hi Elisha, any news? I currently have a thread going on our internal company blog about SEP scheduled scans so would like to know more about the behaviour with retries and any rethinks.... Thanks.

0
Login to vote
Elisha's picture

We are looking to address this in a future version.  However we have no ETA yet.

0
Login to vote
Elisha's picture

This issue has been addressed in SEP 12.1 RU2.

0
Login to vote
Serengeti's picture

Hi Elisha, could you let us know which fixID this is so we can check it in the release/fix notes.

http://www.symantec.com/business/support/index?page=content&id=DOC6155

0
Login to vote
Elisha's picture

The fix ID is 3093104 and it was not listed in the release notes.  The release notes only lists a subset of what was fixed.

0
Login to vote
Serengeti's picture

Thanks Elisha, could you elaborate what has changed so I understand this please. I can then add this to the justifications for upgrading our SEP clients from RU1.

0
Login to vote
Elisha's picture

There was another issue related to this.  That issue was defect 2681132.  Both issues were fixed with the same fix.

The issue is that SEP would update the LastStart time registry key causing it to equal the last complete time.  Therefore we changed SEP so that it would correctly set the LastStart time.

0
Login to vote