Scheduled On-Demand Scan Exceeds Timeout Threshold

[waynediesel]

Hello All -

I have a scheduled full disk On-Demand Scan that seems to exceed the timeout threshold set forth in the policy for that particular scan. Here is my assigned client task settings for that scan in ePO:

However here is the ODS log entry that exceeds the 6 hours and 1 minute threshold:

10/7/2012    1:46:01 PM        Engine version                          =    5400.1158
10/7/2012    1:46:01 PM        AntiVirus   DAT version                 =    6857.0
10/7/2012    1:46:01 PM        Number of detection signatures in EXTRA.DAT =    None
10/7/2012    1:46:01 PM        Names of detection signatures in EXTRA.DAT  =    None
10/7/2012    1:46:01 PM    Scan Started    <servername>\SYSTEM    (managed) VSE 8.8 ODS
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Scan Summary
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Processes scanned    : 120
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Processes detected   : 0
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Processes cleaned    : 0
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Boot sectors scanned : 4
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Boot sectors detected: 0
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Boot sectors cleaned : 0
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Files scanned        : 138405
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Files with detections: 0
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    File detections      : 0
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Files cleaned        : 0
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Files deleted        : 0
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Files not scanned    : 196
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Scan Summary (Registry Scanning)
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Keys scanned         : 84235
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Keys detected        : 0
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Keys cleaned         : 0
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Keys deleted         : 0
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Scan Summary (Cookie Scanning)
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Cookies scanned      : 98
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Cookies detected     : 0
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Cookies cleaned      : 0
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Cookies deleted      : 0
10/7/2012    10:41:01 PM    Scan Summary    <servername>\SYSTEM    Run time             : 8:55:00
10/7/2012    10:41:01 PM    Scan Terminated    <servername>\SYSTEM    (managed) VSE 8.8 ODS

Has anyone experienced this before? Does anyone know why this would occur?

Thanks!

[petersimmons]

9 hours is an extremely long time for a mere 138K files. Are you running this at Low (1 thread) or Below Normal (2 threads per core)? And are you scanning inside archives?

My laptop processes 3X that number of files in 1/4 that time. There's something else at work here causing this.

[pato]

Does that pc makes local backups? I have a similar problem on my machine. I make a backup of my c: drive to the d: drive with windows 7 own backup engine. This causes my weekly scan to take over 10 hours (I usualy terminate it before that).

pato

[waynediesel]

Hi Peter -

I agree that it is a very long time to scan that few files. I am attempting to use this particular ODS as a full disk scan. Here are my scan locations:

Scan Items:

Exclusions are set to none so that I can scan the items that are excluded from the OAS policy setting.

Performance Settings:

For this particular server, it is a Hyper-V Host server that hosts and managed 50-70 hyper-v machines. Some of the Hyper-V files for those other machiens (.VHD) could be upwards from 20 GB in size. I am beginning to think that these options are not ideal for a server like this, or may not be ideal for any server.

Message was edited by: waynediesel on 10/9/12 7:04:37 AM CDT

[petersimmons]

Try a scan with the "scan inside archives" off. With that off you should be seeing a scan in under an hour. If it is a Hyper V server then we may want to add an exclusion to the ODS for the VHD files. ODS exclusions are rare but this may be a case where we want to do this. Try the archives first and the exclusion second. And please let us know the results.

[waynediesel]

Peter -

I ended up opening a ticket with Platinum support, but before I did I spoke to my Platinum rep about the issue and got his take. Given the background of these servers, and how they are host 50-90 server virtual machines, I beleive that it is possible that the on-demand scanner got hung up scanning a very large file. In this case I beleive it could have been a 20-40 GB VHD file that represents one of the virtual machines residing on that host.

Per my Platinum support rep, ODS does not have scanning timeouts on individual files the way the On-Access Scan does. Maybe the ODS was so busy scanning a file that it was not able to tell itself that it had exceeded the timeout threshold setforth in the client task.

My platinum support rep also echoed a lot of the same things you did, specifically:

• Exclude .VHD files from the ODS (I thought this was a taboo, but he assures me that some cases warrant exclusions even here)
• Turn off "Scan Inside Archives"
• Add an exclusion for files that have not been modified on over 60 days since this scheduled scan in only for servers, and servers do not change as often as desktops/laptops

I will be testing these modifications out in the neare future to see how they take.

Appreciate all the help so far!

[petersimmons]

I am glad you are on the right track.

Generally it is taboo to add exclusions to ODS. However, there are cases (you have one) that it makes some sense. The whole idea of ODS is to catch the stuff that OAS missed. If you exclude stuff there then you have no backup.

>> I beleive that it is possible that the on-demand scanner got hung up scanning a very large file. In this case I beleive it could have been a 20-40 GB VHD file that represents one of the virtual machines residing on that host.

If ODS is scanning a giant archive it can take forever to 'cancel' that event. That's probably why it seemed to 'ignore' your end-of-scan event.

[alexn]

I agreed, there must be HVD file in scanning process.

[akl71]

Peter Simmons schrieb:
The whole idea of ODS is to catch the stuff that OAS missed. If you exclude stuff there then you have no backup.

But how can i get sure that ODS is really scanning all files? Many users just restarting their client short after the ODS-task is starting  ... and there is no way to continue a canceled scan.

It is no big problem for servers but for workstations ODS is pretty useless because it is too easy to avoid these annoying scans.