We are also facing these issues and I would like to create some exceptions for BO too.
What is the correct way of configuring those? Is it like bccol says? Or like DeanBaker is asking?
I would not like to configure the exceptions to generic and weaken the safety of BO detection.
On Citrix servers Buffer overflow protection should be disable as suggested by McAfee, If its enable than citrix application will not work. I faced same issue with my account and with exclusion also did not help me.
For Client PCs you can try with exclusions.
In our case users report poor web app performance after going to McAfee 8.8 patch 4 on XenApp 6.5. We are using IE8 for compatibility reasons. Disabling BOP and DEP has not helped. The poor performance appears to be related to web apps that use Java in some way. If I disable OnAccess Scanning then the performance improves immediately.
Does anyone have any updates?
I have added all the recommended exclusions but that has not helped. The issue certainly appears to be some process or file needing exclusion. Only Java related web apps appear to be impacted.
I can launch a web app that uses Java in some way and just watch IE spin while it tries to load the content. At the same time the CPU is spiking because the McShield service is consuming most of the resources. If I stop the McShield service or disable OAS then the web apps perform perfectly. If I just let IE run the content eventually loads after 30-40 seconds and IE stabilizes. So to me it appears OAS is doing its job by scanning the process or file(s). Once that scan is done and that process / file(s) is cached then IE is fine for the duration of that session. If I log off and relaunch then the behavior returns.
I've added the **\Sun\ exclusion. However, it still appears all "Sun" folders still aren't being excluded. I confirmed this by looking at the last scanned entry in the console when using a web app. Any recommendations there?
I confirmed this by looking at the last scanned entry in the console when using a web app
That's not an accurate method.
Use the VSE Profiler to tell you what is being scanned.
Also make sure you're not actually facing ScriptScan performance overhead, rather than the On Access Scanner.
I've asked McAfee support and awaiting a reply but you may know the answer. Is it true that ScriptScan isn't actually disabled until you unregister the scriptsn.dll file even if it is disabled in ePO?
I'm seeing better performance after following this workaround:
The DLL will still be loaded in the process that's running VBScript or JScript. It won't be doing scanning if the policy is disabled, but it's still adding as much overhead as it takes for it to receive the instruction and pass it along.
If you want an idea of just how many instructions are being passed through it, turn the feature on, and also enable its debugging capability:
Add a REG_SZ called DebugDumpDirectory, and give it a path, e.g. C:\Test\
Making the change will require disabling Access Protection temporarily, and restarting any process that may have already loaded the ScriptScan DLL.
The feature will write to that folder every single script it sees that is being scanned. And that lets you know how many operations are running by it, even without scanning turned on. So, some overhead will be unavoidable, but it won't be noticeable unless you're dealing with massive volumes of scripts in short space of time.
The workaround you noted takes the DLL out of the picture entirely.
Users are still complaining of slow performance even after unregistering the DLL. I really thought I was onto something. I'll have to go back to McAfee support at this point and will post any updates.