Adobe apepars to have changed something about its download manager that makes it impossible for users with VSE and the "Common Standard Protection:Prevent common programs from running files from the Temp folder" enabled to install their own flash updates/plugin even if they have the Windows rights to do so.
And furthermore, no manner of exception in that policy element in VirusScan Enterprise appears to make it work because VirusScan's exceptions appear to be insufficiently robust. They don't appear to have any way to allow just a subset of programs that iexplorer.exe might try to fork.
Has anyone tamed this shrew, or noticed this recently change from Adobe? I ask because Adobe download manager used to work for us, and now no longer does. We haven't changed this element of our ePO policy in many moons. My network has a mix of VSE 8.7p3 p4 and p5. p5 is what I verified this problem on on two workstations.
Details/How to Reproduce
In IE, I accessed the flash install page
The install silently just … fails. The V shield gets red and angry. From Virusscan Console and doing View Log on the Access Protection Log, we see why:
5/13/2011 8:40:50 AM Blocked by Access Protection rule DOMAIN\myuserid
C:\Program Files\Internet Explorer\iexplore.exe C:\DOCUME~1\myuserid\LOCALS~1\Temp\ICD1.tmp\getPlusPlus_Adobe_reg.exe Common Standard Protection:Prevent common programs from running files from the Temp folder Action blocked : Execute
Policy Exceptions attempted, none of which is workable
Workaround attempt 1 (failed): Attempting to add getPlusPlus_Adobe_reg.exe to my local exceptions for Common Standard Protection access protection temp directory access provides no help… since apparently the matching filename is actually Internet exploder:
C:\Program Files\Internet Explorer\iexplore.exe C:\DOCUME~1\myuserid\LOCALS~1\Temp\ICD1.tmp\getPlusPlus_Adobe_reg.exe Common Standard Protection:Prevent
Workaround attempt 2 (success, but very ill advised): Adding iexplore.exe to the exceptions list… allowed the update to be installed with Adobe DLM. Naturally we wouldn’t want to employ this exception because it’d also allow ie to execute any manner of nastiness downloaded to temp. We have been spared non-detected infection vectors by virtue of this feature on many occasions.
Workaround attempt 3 (failed): Adding iexplore.exe*getPlusPlus_Adobe_reg.exe as an exception. Mcafee doesn’t support this construct unfortunately. I remember talking to them about it on a support call months back when we were fighting another similar issue for another program we wanted to allow IE to run.
Workaround attempt 4 (failed) Adding C:\Program Files\Internet Explorer\iexplore.exe C:\DOCUME~1\*\LOCALS~1\Temp\ICD1.tmp\getPlusPlus_Adobe_reg.exe as an exception
Workaround attempt 5 (failed) Adding C:\Program Files\Internet Explorer\iexplore.exe C:\DOCUME~1\myuserid\LOCALS~1\Temp\ICD1.tmp\getPlusPlus_Adobe_reg.exe Even being completely matching on both program and argument with a full path and no wildcards wouldn’t work.
Anyone else have any good workarounds?
Does VSE 8.8 perhaps address this shortcoming in VSE's exceptions for this rule/protection?
Finally got a chunk of time to get on the phone and ask support. Sadly, the answer appears to be "can't get there from here." No workarounds available other than turning off this protection, or allowing iexplore.exe to run whatever it wants to. And a mention that "this protection is not turned on by default."
Grrrrreat. This is a shame, because this is actually one protection mcafee provides that has saved our butts on many occasions.
I've been sent the URL for product enhancement requests.Message was edited by: Regis on 5/16/11 2:57:48 PM CDT
I have a similar issue that installing Mozilla Firefox always triggers this rule (I have it set to warn only) and would love a work-around for that issue.
If you are open to installing Flash via Group Policy or your own MSI based script, the MSI's are available from Adobe via their free licensing program at http://www.adobe.com/products/players/fpsh_distribution1.html . If I recall correctly, the MSI based install didn't seem to trigger the warning.