Thx for pointing this out, I'm new here.
And yes it turns out in VSE forum somebody else recently posted the exact same problem.
I too have tried a similar bock and have the same exclusion list issue which i logged ( mine is **\*AppData*\**\*.exe )
As some ive seen have ended up in appdata local
I have even spoken to mcafee on the phone who fobbed me off with some excuse that it need a high and low scanning exception, I tried it anyway but didnt work
Also noticed in the built in anit spyware max protection, the prevent programs from running from temp have built in exclusions which are also ignored
Im sure this is a bug, are you running VSE 8.8 ?
Im yet to find a answer, even tried going back to VSE 8.7 just to check
The level of protection this offers us is too good to turn off but this is also stopping users getting onto citrix and webex conferences
We are on VSE 220.127.116.118 | Agent 18.104.22.1681
I'm with you, this appears to be a bug. I've tried all iterations of paths, wildcards, exclusions, even tried device path's that I had to look up with Sysinternals winobj.
That exclusion field is dead.
Hopefully the virus library write-up of this has been corrected by now (haven't checked at time of this posting but I know folks internally were looking into it a couple weeks ago).
You can't include paths to process objects, only the process names.
If you try to exclude paths your mileage will vary - it's because the product has no guarantee that path information will be available to it at the time of processing the rule. So, sometimes it may work, sometimes not.
Our expectation is that it won't work since there's no way for us to guarantee it will work.
Ive tried the process name down matching down to case and it still doesnt allow it
There is a out of the box rule under anti spyware to block exes running from temp areas, this includes exclusions set by mcafee
Turning that on also ignores any of the built in exclusions
I too have run into limitations in the exclusion wildcarding, and it's a shame. If I had a specific example like this, I'd raise it with support, get it escalated up through the chain until they give up and engineering accepts it as a bug with a BZ number, or says its working as designed...at which point your would turn it into a product enhancement request, harrangue your sales folks to hook you up with the product manager and find out the likelihood of the issue getting fixed. Make sure also that there's not a newer patch level available on your product as I have vague memories that there were bugs in older patch levels on this issue.
McAfee Application Control (solidcore) may be where sales will steer you. It flips the rather broken antivirus model on its head and allows only the apps and publishers you specify to run and does this sort of granularity much better than access control can. You can whitelist by md5sum, by publisher, by paths with regular expressions that usually work, and things of that nature. That said, boy is it a pain in the butt to get up and going on workstations and the admin overhead is nothing to take too lightly. It can be done, I'm told, but it's tough sledding. I'll let you know when I get there to declare victory.
I agree with you, access protection is pretty powerful and not something I like to turn off either. We do however manage to get webex working fine, but you do have to let it fail through to where webex lets you download a standalone executable to run, and users have to get used to saving such executables out to directories without the name "temp" in them to run them.
My latest hilarity with access protection: when upgrading 8.7 p3/p4 systems, guess what it prevents happening if say you're migrating hosts to a new ePO? Yeah, that whole "prevent modification of McAfee files" thing is unfortunately VERY effective against Agent 4.8 pushes and VSE 8.8 installations (*face palm*). That's right, it's so effective you can't manage to upgrade the software without first turning off AP. But luckily agent to server communication is always perfect and it's extraordinarily hard to run into things like duplicate GUID issues should some enterprising help desk person decide to ghost an image with an agent on it, so your agents always communicate policy changes perfectly and it's alsway super easy to turn off access protection. ;-)