This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Some clients not reporting back the status of scheduled scan

Hi,

In our environment we have scheduled scans (full scan) every week, but in one group we have 3 servers. One of those servers is reporting when it has finished it scheduled scan, the other 2 do not.

So I checked the policy just in case, but it says it scheduled. Also on the machines, Windows added a scheduled scan task. When I run the task manually, it runs and is successfully. But it still reports that the last successful (scheduled) scan was about 2 months ago.

I tried to reinstall the client on those two servers, but no luck :|

Anyone know why just these two servers or not reporting the scheduled scan back? "The last message received from computer" is also very current, reported an hour ago, so no issues there..

:48646


This thread was automatically locked due to age.
  • Hello Rheden,

    there should be a log of the scan in the same directory a SAV.txt (filename is the scan's name) - does this show that the scan has completed (start and completion should also be reported in SAV.txt)?

    Christian

    :48654
  • For both servers the log file containts the following:


    20140328 075126 Scan 'Scheduled virus scan' started.



    The one that does work has a complete log file. When I start the windows task I can see that the job is running and is scanning, but completion takes a while, almost 24 hours (big file server).

    What could the problem be? It cannot be the task, because it starts with the credentials it is supplied with..

    :48678
  • Hello Rheden,

    you findings suggest that the status in SEC is correct - apparently the scans haven't finished (at least not in an expected way). AFAIK the actual scan is performed by one or more threads in SavService.exe. The local GUI shows a running scan on the left (a small pane labeled Activity appears) - dunno if the information survives the "recycling" if the SavService due to an update (Note: This is not the same as restarting the service from service control in which case the scan is silently aborted) although the scan normally runs to completion.

    As it is not a reporting issue but the scans apparently don't complete (or internal communication breaks), and furthermore we can rule out the the service is manually restarted or the servers rebooted, I can only suggest that you contact Support - guess it is possible to monitor the scan. Please follow up if you have more information.

    Christian

    :48690
  • I've been trying to test this during today and what I have observed is:

    • Manually ending the scan on the endpoint reports the fact to the SAV.txt log as well as the individual scan log named after the name of the scheduled scan.  You also get an error to the console.
    • Restarting the SAV service quits the scan and nothing is logged reported.
    • Forcing an update/reinstall causes the scan to pause and pick up again.

    Demo: http://www.screencast.com/t/GyhCZe774

    I'd say that size and amount of files that are being scanned (i.e., the long scan length) is a factor.  According to my observations above the most like is that the SAV service is being restarted or there is a similar like event occurring.

    I'd suggest breaking the scan down a bit and scanning a part of the drive.  Maybe Mondays some folders, Tuesdays other, etc.

    If you decide to raise a ticket ensure you include a link to this thread to save time and post back what you find out.

    :48710

  • ruckus wrote:

    I'd suggest breaking the scan down a bit 


    Unfortunately this can only be configured locally - you can't manage them from SEC and, if I'm not mistaken, consequently their completion is not reported to SEC.

    Christian

    :48718
  • I'm thinking exclusions to limit the scanner's scope.
    :48726
  • Hello ruckus,

    I'm thinking exclusions

    sly - but not even close, so definitely no cigar :smileywink:. First of all, even the local GUI does not allow individual exclusions for a scan (but as you can select the items to scan you don't need them). In order to use it from the console you'd have to reconfigure the exclusions after one scan has finished and before the next one starts.

    While one could limit the scope this way I don't recommend advise against it. The exclusion settings are global (the configuration page in local GUI even gives an explicit Warning). The On-Demand exclusions can be pretty dangerous. Unfortunately the console GUI is rather vague (one might even say, misleading) about this topic. Not only is Extensions and Exclusions ... somewhat inappropriately placed in the Scheduled scanning frame, the explaining text isn't prefixed with a Warning: and unobtrusively states: [...] also affect the "Full system-scan" and default on-demand scans [...]. If you are unsure what this means, try it out. Actually it affects all scans (i.e. also the ones created locally, and did I mention right-click scan?). Of course, the exclusions can be overridden locally - but you are caught between a rock and a hard place.

    I'm opposed to "lightheaded" use of exclusions because of their global scope and their potential unwanted effects - especially as their presence is not obvious.

    [@ruckus: That's no criticism - BTW: you're doing an excellent job, you're very committed and your "multimedia guides" are great.]

    Christian

    :48746
  • All true.  I was typing that on a phone so the response was shorter than it should have been - excuses, excuses. :smileyembarrassed:  To clarify...

    I'm thinking that you can add some temporary exclusions to the central scan configuration for the purposes of testing just to see if the scan does then complete and returns a date and time entry to the Computer Details screen.  That would confirm it's not a reporting issue.

    Better? :smileywink:

    :48750
  • Much better (but then, I wouldn't have had the opportunity to lecture :smileywink:). May I emphasize that the temporary exclusions are only for confirm[ing] it's not a reporting issue (which is a good idea even though it doesn't look like one). 

    Christian

    :48756
  • Thanx for all the replied guys..

    Before I tested any further, I cloned one of the servers in our test environment where I can replicate all of the problems that I can see until now.

    So I investigated further and tried to break up the scan in to little pieces. Both servers do not pass the "Master Boot record. drive PHYSICALDRIVE1" section, it always hangs on 2% completed.

    So I uninstalled the Sophos client and reinstalled (with policies etc.), but no luck, still the same problem.

    After that I installed the stand alone version, same thing.

    There were a few things that I know changed after the last succesfull scan on both servers, that is Windows Search and previous versions. So I uninstalled Windows Search, did a reboot but no go.

    After that I did a full offline scan (Sophos boot cd) but no problems are detected.

    Then I booted with the Windows recovery disk to start a commandprompt and start bootrec to fix the mbr, but also no go.

    Then I disconnected on of the disks (d: drive (data)) and added that to another server in my test environment to scan the disk, so I can determine if it's a server or disk issue. But the manual scan gives the same results:

    Items being scanned: Master boot record, drive PHYSICALDRIVE2

    So I am at a loss now, what can I test next to find out where the problem is? Or how can I fix this error?

    :48864