since tonight we have several systems which are reporting back Timeouts in Scan Operations (OAS). This is nothing I´m worried about but the amount of Systems is wondering me. Normally there are two or three systems with this message in a week but since yesterday, 10 o'clock in the evening, the amount of Systems is growing. There are no similarities in system configurations, nor are these at the same domain or subnet, nor have all the Systems the same policys. Server luike Workstations, like Notebooks.
No new product was checked in, no policy change, only the normal DAT Update and some patch deployments via WSUS at the afternoon.
No LogFile shows strange entrys, Server and Clientlogs were checked, and I`m just puzzled why this is happening from one day to another under the given circumstances?!!? Any idea or does someone else has had the same experince in the past and maybe a clue? Log Files can be provided of course but as mentioned - there are no entrys beside the ususal one's.Nachricht geändert durch Don_Martin on 23.05.13 10:05:50 CDT
do you mean on-access scanning timeouts occur in increasing number? That should appear in either %DEFLOGDIR%\onaccesscanlog.txt or in Windows Application event log (or in both).
Is not there any of such event?
and yes. The OAS-Log shows the specific File/-s on which the Timeout occurs and there is nothing non-normal within these Files (doublechecked meanwhile).
I`m just wondering why the amount of Systems is still above normal. From yesterday to now there are 30 new Systems on which the oas had has a timeout so that there is a total of 60+ machines by now in two days. 60 machines is what we have normally in a month or two with oas timeout but not in two days...
Do the type/names of files causing the timeouts vary or not? Sometimes by filenames you can tell what operation they belong to and you could tie them with other individual actions (such as patching, software distribution, etc.) in your network.
Even these files could be McAfee 's own. So some typical examples of such events might be useful to be attached here.
Otherwise if you can decide that those files are harmless, you can exclude them from scanning.
it is not the question wether or not those Files or Folders are infected with anything (indeed they aren´t) but why we are getting this non-normal behaviour of 1.5% of our machines in this manner? From one day to antoher and without changing anything?!
But here you go, a few examples:
C:\Dokumente und Einstellungen\[USERID]\Lokale Einstellungen\Temp\5kxgw9-w.cmdline
C:\Dokumente und Einstellungen\[USERID]\Lokale Einstellungen\Anwendungsdaten\Microsoft\Internet Explorer\brndlog.bak
C:\Dokumente und Einstellungen\TEMP\Lokale Einstellungen\Anwendungsdaten\Microsoft\Internet Explorer\Custom Settings.tmp\Custom1\seczones.inf
C:\Dokumente und Einstellungen\[USERID]\Anwendungsdaten\Philips Speech\SpeechExec\ConfigCache\PSP.SpeechExec.DictationPropConfiguration.xml
C:\Dokumente und Einstellungen\All Users\Startmenü\Programme\Autostart\Program Neighborhood Agent.lnk
C:\Dokumente und Einstellungen\[USERID]\Lokale Einstellungen\Anwendungsdaten\Microsoft\Internet Explorer\Custom Settings.tmp\Custom0\inetcorp.inf
Some Files were in use I presume, some other files I can not explain why they are not scanned to the end. Nevertheless the most common and explainable extension not scannend ist C:\Windows\Prefetch\*.pf (common used programs) which is fine for me in this matter (but maybe something to think about in an other context). All OAS-Timeouts were scaned with ODS just to be sure and there were no findings at all.
No changes at all (Domainpolicys, McAfeepolicys, none of the systems got any malware finding in the past few weeks (not even Blackole or any JS/* detection))...
on 24.05.13 05:36:57 CDT
Some of these files can belong to Internet Explorer group policy enforcement action so some gpo enforcement might be underway.
Could you reboot just one of the problematic host so to exclude stuck file handles due to which OAS might fail on these files?
/If your hosts are ePO managed: As far as I remember scan timed out errors appear as "detections" in ePO reports (unless you filter them). I would by all means make a query on this condition and compare if file displayed on various hosts are similar or not, just to see if I can spot a pattern./
the query you mentioned exists and if it would not be existing it would have been added on thursday
I really appreciate your replies but as you can see there are for sure some identical files but never or near anything with which I would call "There is obviously a relation" *sigh*
EDIT: There are indeed some Files which are identical on different Systems but not within a nearby timestamp . Manual Scans are without a finding.Nachricht geändert durch Don_Martin on 24.05.13 08:01:58 CDT
sorry for the pause I was out of office.
Well, my best tip would be to exclude the .inf and .pf files, just as well as .lnk files from scanning. Apparently these are most likely not to be containing harmful content. You can identify the processes that uses these types of files and set up a low-risk process exclusion list with these files.
As for why timeouts occur in increasing number I have no convincing explanation, and I'd say we might just ignore them by doing the above.
timeouts are meanwhile occuring in normal manner but this isn´t comprehensiible at all...*sigh*...maybe something within a DAT that hits our Landscape...or maybe not...or maybe Murphy thought "Okay, then we will take some actions here, some actions there and then...we will look how Don is doing"...I don´t know but this is not exactly a kind of situation I like - having an unnormal behaving without a conceivable explanation.
Thank you for your efforts and suggestions
Download the new ePolicy Orchestrator (ePO) Support Center Extension which simplifies ePO management and provides support resources directly in the console. Learn more about ePO Support Center