I have EPO 4.5 with VSE 8.7 throughout my network of server 2k3 and xp machines. By and large I have no problems apart from one set of linked html documents which open so slow with 'on access scanning' enabled that they are unuseable. They take roughly 30-45 seconds to open a page from a hyperlink in the previous page.
I have added the network share where the files are located to the exclusion list, but that doesnt help at all. I removed iexplore.exe from the high risk process list but again that did nothing either. I also turned off script scanning, but again that achieved nothing.
If I allow users the option to turn off 'on access scanning' then all works well and the files open promptly. Suprisingly if they turn it off before they open the main menu page, even when EPO turns 'on access scanning' back on again after 5 minutes or so everything continues to work perfectly for all pages opened after that from hyperlinks within the first page. However if they turn off 'on access scanning' after the first menu page is opened then pages are unusably slow even if the scanning stays off permanently.
Is there any way I can get around this, by adding exclusions for example, without giving users the necessary privileges to turn off the scanning. Which, because I cant find any other way, means me giving them local workstation admin or power user rights?
Solved! Go to Solution.
Very good to hear! So we know it's ScriptScan - boy that feature has taken a pounding since it came to be
And probably explains why the other vendor AV solution doesn't have issues - not many folks have a feature that scans scripts before the scripting host renders them.
You may not be aware but ScriptScan is capable of excluding URLs, not only processes. Meaning, you don't have to exclude IExplore.exe, instead you can specify the URL of where these scripts are coming from... and expect the same performance gain of when you excluded IExplore.exe. That would be ideal.
Sometimes identifying the URL isn't intuitive; case sensitivity, cannonical DNS records... it can be troublesome. I would suggest working with Support if you run into trouble with it.
Info on how to add URLs to the exclusion list can be found here, KB65382.
If you have really slow performance with certain HTML files, you should open a support call with McAfee, and provide samples of the files to them per their instructions.
Sometimes the optimisation of dat drivers can be improved when McAfee Labs are able to see files that take a long time to be scanned and analyse which driver is causing the issue.
There are a couple of possiblities that have worked for others.
1. If you haven't already, make sure you have the current 5400 scan engine installed.. It fixes some of the HTML and Cookies scanning issues.
2. Most importantly, very few users need to have "Network scanning" enabled in the "On Access Scan" settings.. Since the file in question appear to be on a network share, UNCHECK the "Network" box and it should help your particular problem.
Hope this helps.
Thanks for the replies but no solution as yet I am afraid.
Unfortunately due to the nature of the files and the network they are located on I cannot and will never be able to provide Mcafee, or anyone else either for that matter, copies of them to try and find the reason for the poor performance.
Also I already have the 5400 engine installed and have 'network scanning' turned off.
The files open very very slow even when opened directly from the server on which they reside. The fact that they still open very slowly even when I exlude the entire share on which they sit from 'on access scanning' leads me to think that it is not necesarily the files themselves but some other file or service which they call on opening.
The changes in behavior you described in this paragraph are intriguing:
Suprisingly if they turn it off before they open the main menu page, even when EPO turns 'on access scanning' back on again after 5 minutes or so everything continues to work perfectly for all pages opened after that from hyperlinks within the first page. However if they turn off 'on access scanning' after the first menu page is opened then pages are unusably slow even if the scanning stays off permanently.
It suggests to me a potential interoperability issue with a 3rd party driver.
And this comment from your last post suggests the way forward:
The files open very very slow even when opened directly from the server on which they reside
I recommend collecting ProcMon data on the latter, and evaluating from the capture whether there is an undue level of file or registry activity.
When you disable OAS, you disable Access Protection and Buffer Overflow Protection also. This can be narrowed down further, but you'll need Patch 2 (or Patch 1 with HF 464768) to make it easier to narrow down.
I am running Patch 2 at the moment so should be no problem to try turn off AP and BOP individually and see what happens.
I will also have a play around with procmon and see if anything looks particularly busy.
You don't always need the *exact file* that causes the issue to submit. As long as you can provide a file which causes the issue it should be able to be escalated.
So confidential data in the HTML can be changed - as long as the error still occurs.
I also agree that there seems to be something else going on that may not be related to McAfee.
I take your point regarding possible files for submission to mcafee. Unfortunately there is a lot of confidential info embedded into every page and which would cause an awful lot of work to try and remove whilst keeping the symptoms.
As an extra bit of information. I just received a reply back from the developers of the webpages in question. They fully acknowledge the problems when used in conjunction with Mcafee but refuse to do anything about it. This is because the primary(and only other) customer who uses it has a different AV solution on their networks(I dont know what) which has no issues opening the files.
Also when I said earlier that the files opened slow on the server on which they were hosted. I shuold have mentioned that if I turn of OAS then they open just fine as well.
"Also when I said earlier that the files opened slow on the server on which they were hosted. I shuold have mentioned that if I turn of OAS then they open just fine as well."
I might suggest that some basic performance tuning is in order. Consider turning Off 'When reading from Disk' and consider whether .jar files should be excluded in the list of extensions as this 'may' cause significant slow down while each is extracted.
Let us know if this is helpful.
Did some additional testing by turning off BOP on its own but was no change in symptoms.
I already had exclusions for .jar files and a few others so there was no problem there.
I then ran some Procmon traces as suggested by William Warren. They showed a huge amount of both File activity as well as registry activity with OAS on compared to turned off. Apart from the fact that the Mcshield service was the cause of most of the activity it was hard to pin down exactly why it should be so.
I then re-tested again but this time with script scanning turned off. I had done this before, or thought i had, but obviously messed something up previously as with script scanning turned off the problem disapears. I then turned script scanning on again but put a specific script scan exclusion of iexplore.exe which was also fine.
Out of interest the difference between mcshield activity with script scanning turned off compared to on is quite amazing. For example to open one link with scanning on took mcshield.exe 60k+ file events (about 4MB/s IO throughput and 1000 file I/O events per second for 50 secs) and 9k registry events with roughly 90% CPU being used for 50 seconds before the link opened. With it turned off (or on with the exclusion) mcshield took 755 file events and only 3 registry events over less than 2 seconds to open the exact same link.
Having iexplorer.exe exluded from script scanning is not the best solution but its better than turning off OAS or script scanning completely. Unless anyone else has any ideas to narrow the problem down further I think I am going to have to leave it as it is now.