We have a server that runs a custom application, with ENS 10.5 or 10.6 it will not start up correctly but as soon as we untick 'enable on access scanning' it works fine...
The trouble is nothing is logged in the ENS console to indicate what McAfee is blocking and we have excluded all the custom application files/folders from scanning in the policy but still the same 😞
Any ideas on what else we can do to resolve as obviously leaving on access scanning turned off long term is a security risk
Thank you for posting your query
I request you to kindly take a look at the OnAccessScan_Activity.log file located at
You may also log a service request with the McAfee Technical support team. Also run the process monitor while the issue is reproduced and share the process monitor logs with them. They will analyze the logs and let you know what is causing the issue
As suggested above, I would recommend logging a Service request with us for this.
The exclusions may not works as expected if you have High risk and Low risk process configured in your On Access Scanning policy.
It is important to investigate if On Access Scanner is making a detection here. If no, then debug logs for On Access Scanner might help us dig in more. A probable involvement of Engineering Team might also be needed for which a Service request with appropriate Debug logs and other logs like Procmon and AmTrace are required.
Also, Kudos to you for your excellent work in isolating component and finding out which component causes the issue!
The log is quite bare unfortunately
29/10/2019 14:48:14 mfetp(5400.3460) <SYSTEM> oasbl.OAS.Activity: Telling OAS compliant status became RED - OAS disabled by user
29/10/2019 14:48:14 mfetp(5400.3460) <SYSTEM> oasbl.OAS.Activity: Added reason to compliance status - REASON_OAS_DISABLED
29/10/2019 14:48:14 mfetp(5400.3464) <SYSTEM> oasbl.OAS.Activity: AMCore content version = 3875.0
29/10/2019 14:50:52 mfetp(4660.8424) <SYSTEM> oasbl.OAS.Activity: Telling OAS compliant status became RED - OAS disabled by user
29/10/2019 14:50:52 mfetp(4660.8424) <SYSTEM> oasbl.OAS.Activity: Added reason to compliance status - REASON_OAS_DISABLED
29/10/2019 14:50:52 mfetp(4660.5284) <SYSTEM> oasbl.OAS.Activity: AMCore content version = 3875.0
However I have got a little closer now we're out of business hours here so I could tweak without upsetting anyone, under 'Standard Process Types' for the Threat Prevention On Access Scan policy we have set in ePO for the server if I simply untick 'On network drives' under What to scan the issue is resolved
Looking in the software it does connect to a UNC path but to itself e.g. the server is called SERVER1 and the path is \\server1\datashare, so I am not sure why McAfee is getting in the way of this connection or if we can exclude a particular UNC path in the policy
We do not have the option to add exclusions to a UNC path in On Access Scan Policy, however you may try to map the folder and try excluding it as shown in the image below
Thank you for your update. Once again very good job in precisely finding out the issue and practically the workaround/solution as well! Kudos to that!
I am afraid the ON Access Scan activity log by default would only log detections and hence we require debug logging enabled.
Regarding the exclusion of UNC path, Can you try it once locally just to be sure it is working as expected? I have attached a screenshot for your kind perusal.
Also Kindly please find below if the best practice recommendations where for performance optimization excluding scan of network drives may be implemented provided you are aware of the impact.
You can also toggle between Scanning only during read or only during write and check where the actual impact is from.
A humble suggestion would be to tighten up the NTFS permission on this folder to ensure it is safe despite the exclusion.
I sincerely hope this helps.