3 Replies Latest reply on Jul 31, 2014 10:49 AM by cwinning

    Why didn't scheduled scan from run on time?

    dharmatma Rookie

      Hello again.

      I have a scheduled scan of our network set for 10:30 am. The scan didn't run until 12:47pm. I have confirmed its start time in the log, and also confirmed the schedule time on the job. What might have prevented the scan from running on time (besides the obvious, e.g., Shavlik computer offline)? This is for Shavlik 9.x non-agent scans.

      I can make a support request as needed, but thought I would check in via post first. Thanks.

        • 1. Re: Why didn't scheduled scan from run on time?
          cwinning CommunityTeam



          I would suggest archiving all the logs for Protect so they are not over-written.  They are located in C:\ProgramData\LANDesk\Shavlik Protect\Logs on the Protect server.


          The following is assuming the logging level is set to All, the logs haven't been over-written or rolled over due to size.


          • What version of Protect are you running? 9.0 or 9.1? (big changes between the versions)
          • How are you scanning these machines?  Machine Name?  IP Range? Domain Name?
          • How many machines or possible machines were in the scan?
          • Are these machine on a LAN or a WAN?


          Scheduled scans tend to either run on time or fail completely.  It's possible the machine resolution took a long time, the logging for this would be in the log that starts with ST.Protect.managed.  A search for AddressTesterInternal disposed would indicate when the machine resolution completed.  The log that tracks the actual scan would record after the machine resolution is finished.  So it's possible the scan process started on time, the machine resolution (or some other task) took a long time and delayed the scan engine to run at a later time.  This is difficult to pinpoint without logs.


          You could look at the scheduler.log located in the C:\Windows\ProPatches\Scheduler folder on the Protect server.  Search for SchedulerEx.cpp:303 ScheduleJob, this will indicate a job starting.  For instance, the scheduled scan I ran this morning looked like this:


          2014-07-31T13:49:59.8405063Z 1550 I SchedulerEx.cpp:303 ScheduleJob: C:\Program Files\LANDesk\Shavlik Protect\ST.TaskHost.exe, -scantemplateid 1 -patchscanfile "C:\ProgramData\LANDESK\Shavlik Protect\Console\SecurityScans\patchscanfile-85f595ab-cb57-4777-adfc-4d7da5b3aae7.patchscanfile" -scanname "My Machine" -trace, C:\Program Files\LANDesk\Shavlik Protect, run as: 3, run type: 8, run time: 2014/07/31 08:50:00


          run time: 2014/07/31 08:50:00 indicates when I scheduled it for.  The time stamp on the trace line 2014-07-31T13:49:59.8405063Z indicates when it actually ran.  The time stamp is in UTC so I subtract 5 hours from the time stamp to get the real time. (I'm in CST)


          And just to verify.

          Go to View > Results

          What is the time stamp of the scan in the left hand pane?

          Click on the scan and look at the Scan Summary pane to the immediate right.  What is the time stamp?


          Thank you,


          • 2. Re: Why didn't scheduled scan from run on time?
            dharmatma Rookie


            Dear Charles,


            Thank you for this detailed reply! I have checked everything you cited, and there is no question the 10:30am scheduled job kicked off at 12:44pm and completed about 1 hour later. I have Shavlik Protect v9.1.0. Scans are by machine name (from a machine group). It's not more than 60 machines on a LAN.



            So, I will make a new version of that job and check it again next week. If it still kicks off late, then I will submit a support request. I might add that the reason I need the job to run in the AM is to grab the part-timers' machines. They shut down after lunch...


            I will add to this post next week with results.



            • 3. Re: Why didn't scheduled scan from run on time?
              cwinning CommunityTeam

              Hello Dharmatma,


              Thank you for the update.  I agree a case would be the logical next step since we will need logs to pinpoint the root cause of this issue.   You can mention my name in the case and I will be the escalation point for you.


              Best regards,