Post edited by Moderator for clarity. Header should be short and I put the message in the body of the discussion.
But don't you want this in VSE? I can move it if you like.
1 of 1 people found this helpful
Thanks Actually I am new to community and all lost, hence kindly move this to the VSE discussion room
Moved to VSE, good luck.
I have been hearing about ODS performance complaints specific to Patch 6. They do sound intriguing, but as yet none have amounted to more than configuration issues (such as have always existed, like scanning archives or not setting the performance slider to "below normal" or "low").
In saying that though, my team is looking into a couple of reports received recently that may have promising data and actually demonstrate an issue; that remains to be seen but I'm optimistic.
If you want to see whether yours is a configuration issue or something new please engage our Support team.
I'm surprised you didn't plug your blog post, but the blog post (Controlling the performance impact of a scheduled scan) and the reply to my post (Controlling the performance impact of a scheduled scan) in October helped us tremendously. I know you don't advocate this, and I'm not advocating this without serious thought, consideration, and testing, but we found that lowering the scan threads made a huge difference for us.
Even if you choose to go this route, there are decisions you have to make about deploying the change since Access Protection will block all the typical paths by default.
Prior to Patch 3, however, we also experienced performance issues during scans that you may still find relevant. In that case, we found a couple other sources: 1) Many of our SSD drives couldn't handle sequential requests very well. There was a clear correlation of SSD model among our most affected users. Lesson learned: try to find the similarities, thinking of all possible bottlenecks - not just CPU. 2) If you have any product that has a filter driver (fltmc.exe will show you these), determine if it is at fault. In our case, running Process Monitor and looking at the threads in the System process identified an issue in our file encryption software. A simple upgrade made a huge difference. 3) Even if you can't help the performance completely, you can make the scan run shorter if you get rid of files you don't need. The WinSXS folder can be making these scans run a lot longer than they need to. Clean it up (http://blogs.technet.com/b/askpfeplat/archive/2013/10/08/breaking-news-reduce-th e-size-of-the-winsxs-directory-and-free-up-disk-space-with-a-new-update-for-wind ows-7-sp1-clients.aspx)
I have observed a new issue with my users this time, some of the users who reported system freezing showed me there was default full scan task running along with Managed full scan task on their machines. This is strange as the default full scan task which comes with VSE is not supposed to run as I have deployed a managed full scan task from the ePO. any idea why this is happening ?
The scheduling of tasks is all maintained by the McAfee Agent.
It is open to receiving task information via ePO, and from the local console. It is no respecter of where the input comes from, it just translates the input into a task to run... and because of that, you can end up with local tasks + ePO tasks, or multiple ePO tasks, or multiple local tasks, all running at the same time. Some care is definitely needed with planning of tasks.
Tasks can also be "carried forward" when a product upgrade has occurred. This could definitely be a "gotcha", and has caused us issues in the past; e.g. an extant 8.7i local ODS task was migrated to be an 8.8 ODS task on upgrade, and then additional tasks added via ePO.
ePO only has the capability to override local Update tasks at the moment. You can disable the local update task and ensure your Agent runs an update task instead, but you can't manage or squelch local ODS tasks via ePO.
If there is some cleanup needed of local tasks, it was a simple matter in 4.x series Agent versions (just delete the *.ini files from the Task folder, and any ePO tasks will get recreated); more assistance may be required for a 5.x series Agent version due to the changes in architecture and added security.
After 2 months of troubleshooting with McAfee tier 3 engineering team we are finally getting somewhere, we have found multiple instances of schedule scan trigger on most of our users system during schedule scan day. we found 2 or even 3 scan64.exe running in task manager causing the systems to freeze on weekly ODS Scan.
Issue seems to caused by upgrading of McAfee agent from 4.8 to 5.0 , there are lot of issues reported with McAfee agent 5.0 one of which is it does not clean up the old scheduled tasks from the clients and hence invokes them as well McAfee support has provided us with the hotfix and i will keep you posted after the analysis.
Logs from one of the system TIMSW42L0089, it does show that there were infact 3 ODS scans started but no indication ePO managed ODS scan was triggered as per logs.
15-01-2016 13:56:57 Engine version = 5700.7163
15-01-2016 13:56:57 AntiVirus DAT version = 8044.0
15-01-2016 13:56:57 Number of detection signatures in EXTRA.DAT = None
15-01-2016 13:56:57 Names of detection signatures in EXTRA.DAT = None
15-01-2016 13:56:57 Scan Started IND\TIMSW42L0089$ On-Demand Scan
15-01-2016 14:00:10 Engine version = 5700.7163
15-01-2016 14:00:10 AntiVirus DAT version = 8044.0
15-01-2016 14:00:10 Number of detection signatures in EXTRA.DAT = None
15-01-2016 14:00:10 Names of detection signatures in EXTRA.DAT = None
15-01-2016 14:00:10 Scan Started IND\TIMSW42L0089$ On-Demand Scan
15-01-2016 14:50:07 Engine version = 5700.7163
15-01-2016 14:50:07 AntiVirus DAT version = 8044.0
15-01-2016 14:50:07 Number of detection signatures in EXTRA.DAT = None
15-01-2016 14:50:07 Names of detection signatures in EXTRA.DAT = None
15-01-2016 14:50:07 Scan Started IND\TIMSW42L0089$ On-Demand Scan
15-01-2016 15:36:22 Not scanned (The file is encrypted) e:\Data Backup_30-09-2014\Desktop\Professional 2013\packages\Win81_SDK\dc3acb184552e9eeac50269425274d3c.cab
From MA logs,
2016-01-15 13:56:54.015 masvc(1844.1936) scheduler.Info: Scheduler: Invoking task [ODS Workstation UTC 2PM]...
2016-01-15 13:57:06.376 masvc(1844.1936) scheduler.Info: Next time(local) of task ODS Workstation UTC 2PM: 2016-01-15 14:00:00
2016-01-15 14:00:00.401 masvc(1844.1936) scheduler.Info: Scheduler: Invoking task [ODS Workstation UTC 2PM]...
2016-01-15 14:00:06.391 masvc(1844.1936) scheduler.Info: Next time(local) of task ODS Workstation UTC 2PM: 2016-01-22 14:00:00
Looking at the running processes we can see that there is only one instance of ODS is running, which from the MA logs looks like named as “New Task”
2016-01-15 14:41:23.493 masvc(1628.2020) scheduler.Info: Next time(local) of task New Task: 2016-01-15 14:50:00
2016-01-15 14:50:00.503 masvc(1628.2020) scheduler.Info: Scheduler: Invoking task [New Task]...
2016-01-15 14:50:28.399 masvc(1628.2020) scheduler.Info: Next time(local) of task New Task: 2016-01-22 14:50:00
Name Path Process_ID Priority Min_Working_Set Max_Working_Set Start_Time Version Size File_Date
scan64.exe c:\program files (x86)\mcafee\virusscan enterprise\x64\scan64.exe 5832 8 200 1380 15-01-2016 14:50 184.108.40.2065 55.36 KB (56,688 bytes) 20-08-2015 20:08
Above analysis it seems that this is an issue with scheduler
There are a few MA scheduler issues reported (KB86360)