Why does a daily scheduled scan kick off more than 1 time per day?
Symptoms Scheduled scan adheres to original schedule--starts and completes at the correct time--but also goes off a few extra times through out the day.
Missed events are disabled.
The Symantec scheduled scan logic is misinterpreting a change in system time as grounds for triggering a scan, particularly when the time is set backwards. RTVScan checks for scheduled scans every 60 seconds--sample vpdebug log entry below:
CheckScanForSchedule: checking [Scan_GUID]\Schedule against Sun May 09 xx:xx:xx 2010 -> Sun May 09 yy:yy:yy 2010.
RTVScan passes the timestamp of the last time it checked (xx:xx:xx)—usually a minute ago—and the current time (yy:yy:yy). If the time has been set backwards on the machine, the next time CheckScanForSchedule runs, xx:xx:xx will be greater than yy:yy:yy. This triggers a special case where the window for CheckScanForSchedule spans midnight, and the check is reversed which usually triggers a scan (even if missed events is not enabled). Here is an example. A scheduled scan is set to run at 2:00 pm daily: 1:30 – checking for scheduled scans between 1:29 and 1:30 1:31 – checking for scheduled scans between 1:30 and 1:31 User changes the time back to 1:21 1:22 – checking for scheduled scans between 1:31 and 1:22 – looks like scan did not run since 1:31 yesterday – and it should have run at 2:00 yesterday – run the scan. Here is another possible scenario: The client machine is part of a domain that provides an authoritative time reference for member computers - the Windows Time service keeps client computers in synch. The user (or an application?) may be regularly setting the time on the client backward using some other unauthorized reference, propagating the issue.
The customer should be careful about time synchronization. Normal time synchronization of a domain computer should not produce "jumps" in time, forward or backward. The Windows Time service will normally speed or slow your clock unobtrusively so that your time gradually becomes in-sync with the domain time. This avoids even small jumps which can cause problems with time-sensitive systems.
To determine what may be changing time on a computer, enable Windows Auditing of "Privilege Use" and "System Events". Look for Event ID pairs 577/520 in Windows Security log. Note that not all 577 events indicate a time change, only the ones that note "SeSystemtimePrivilege" in event properites. Event ID 520 describes the actual time change, including old and new time. As described above, normal Windows Time service operations should not be producing these events. Also note that Event ID 577 in XP/2003 and before corresponds to Event ID 4673 and Event ID 520 in XP/2003 and before corresponds to Event ID 4616 in Windows Server 2008, Windows Vista, Windows Server 2008 R2 and Windows 7.