I would say that you need to exclude the process names from the scope of the Access Protection rule that triggers. Examine the relevant entries in the Access Protection log and gather information regarding the process name, the rule name and go to ePO - Policy Catalog - VirusScan product - Access Protection category, edit the policy that applies to the particular clients - select Workstation (or server) - Select the Access Protection category and the rule and edit the rule. Enter the process name from the above log in the exclude process section. Save the policy.
Send wakeup call to the clients or wait until the scheduled ASCI, and next time it should not block your deployment.
Hope this helps.
Thanks for the explanation, however predicting the process name might not be that easy as there is no standard executable name and every deployment will have unique name and getting those name are not practically possible. In fact I am exploring to find out whether anyone has come across this scenario.
As for the process names, these should be WSUS process names, which should be always the same (I strongly suppose so). When a distribution system deploys a software, it does so for example by downloading it in a temp folder and trying to start the installer of that software. This is the phase, when the Access Protection intercepts: in this example it prevents the WSUS process name launch the software installer to be deployed. The offending process names need not be predicted, they are referenced in the Access Protection log.
In other words: no matter what software you want to deploy, it should be a WSUS process (name unchanged) that launches the installer on the client and it may sometimes trigger the Access Protection rule.
Seeing you initially described a complete issue scenario I presume you have access to a client where this deployment originally failed. Could you post the Access Protection log from that client?
Look in the access protection log and let us know which access protection rule is blocking the updates from WSUS..
it will say something to the effect: "Anti-spyware Maximum Protection:Prevent execution of scripts from the Temp folder"
I would suspect you are blocking the execution of files from the temp folder. I am sure you could just "throttle back" a little on your access protections - because your machines need those patches as well.
If this happens on all machines, then setup a test machine and get the machine to exhibit the problem. Check the log, it should tell you which rule is blocking.
If you cannot determine which one, stop the framework service, unlock the console with the admin password, and start unchecking protections on the test machine until you find the one that allows the updates - then research your exposure if leave this one checked vs unchecked.
Perhaps another option.. Once you determine what access-protection policy needs changing, you could setup a a new policy that implements this change and allows patches to be installed. Then during the week of patching, change the on-access policy to the "Allows MS Patches policy" and apply to your machines. When WSUS reports indicate that you are complete, then apply the original policy back to your systems.