There are known issues with McAfee, SCCM 2012 and DISM.
See also the article:
But disabling Access Protection ois not a solution for us since it is against the security rules we have.
How can be solve this or how can this be solved ?
There is no other workaround.
Others have already explored potentially feasible options, without success.
We cannot say why the Microsoft app decides to fail, all we can be confident in is that we're not causing it to fail - it somehow reached that conclusion by us simply being present.
I am having the exact same problem,I am using SCCM 2012 SP1 and in my SCCM server there was McAfee Virus Scan Enterprise 8.8 installed due to which the boot images present in SCCM where not getting updated,i then disabled the Access protection and everything worked fine.
But we need to have a solution for this as it's causing problem where McAfee is centrally managed & we don't have rights to disable Access Protection.
as i have added the folder exclusion in On access scan ,Full Scan & on demand scan but it's of no use.
Is there any option to exclude folders in Access protection.
If there was something the McAfee code was actively 'doing' to the operation, then there would be opportunity for us to make product enhancements somewhere in our code. But for situations where failures occur simply from our code being present, we cannot solve that within our code (since our code will obviously still be present).
Related to this, I have seen product enhancement requests (PER) submitted before (and repetition doesn't hurt) seeking for a way to allow users a temporary "visa" - allowing them some short-lived access to protected areas of the system.
i.e. an alternate to disabling the feature, and enabling it again.
I cannot say if a feature such as this has been committed for future releases in the roadmap, but having the PER submissions ensures the product management staff are aware of the need.
One of my colleagues is now seeing this behavior. We have talked with Microsoft and they confirm that the only current work around is to disable Access Protection. What I don't understand is the following line from the reply above:
"all we can be confident in is that we're not causing it to fail - it somehow reached that conclusion by us simply being present."
If the scenario fails simply by Access Protection being present, then why does disabling this feature - yet leaving it installed on the system, thus the code still simply being present on the machine - have any effect at all?
Have you reached out to Microsoft to work directly with them to try and better understand what is happening?
Apologies for the confusion. I meant has McAfee reached out to Microsoft to work directly with them to better understand what is happening.
It seems that this needs to be resolved between McAfee and Microsoft. Since this would specifically benefit McAfee customers I think they should be the ones to reach out and work with Microsoft on a more complete solution.