We are setting up Exchange 2016 on win 2016 servers. I will be installing MSME as as well, but right now I am trying to figure out how to map Running Windows antivirus software on Exchange 2016 servers to VSE exclusions.
I see many conflicting documents on McAfee site when it comes to low and high rick exclusions. I logged a couple of calls with McAfee in the past and I haired different explanation each time. I must say there is a confusion when it comes to low and high exceptions.
I put processes in low risk (no scan on write, no scan or read) and the directories exceptions are in Default policy. Would that work in case of Exchange 2016 exception? What about Access Protection exceptions?
I will appropriate any help.
When you add a process in the Low Risk policy's process list, it then will obey the exclusions (or in your case, scan items,) set in that same policy. Since you have scan on read and write disabled, that means that anything that low risk processes touch does not get scanned.
So, the way that high and low risk policies should be used can be derived from the following example.
Say we have the following:
C:\test\eicar.txt - This is a file with the eicar test string, an industry standard "test malware" file used to determine if an anti-virus is active
Explorer.exe - When you double click a file in windows, that action is taken by explorer.exe
notepad.exe - Standard notepad program
Winword.exe - Microsoft Word
If you put notepad.exe and explorer.exe in your low risk policy, and tried to open the Eicar test file (So C:\test\eicar.txt,) Windows would utilize explorer.exe to open notepad.exe, which would then be used to open eicar.txt. In this scenario, if we had scan on read/write disabled, the eicar test file would not be detected. If we went and enabled scan on read and write, then added C:\test\eicar.txt to your low risk exclusion list, it would have the same effect, but just more secure.
However, if you did this same test but opened the eicar.txt file with winword.exe, which for the sake of example is not in your high or low risk policy, therefore considered a "default" risk policy," it would not obey the C:\test\eicar.txt exclusion because this exclusion is not in your default risk policy exclusion list, so when it gets accessed, it will be detected as the eicar test file.
You should be able to use this logic to help understand how this transfers to exclusions recommendations made by other vendors.
So if we want to add exclusions to help the performance of your exchange server, we'd add the exchange processes to the low risk process list, then add the locations that those processes access to the low risk exclusion list. This way, McShield won't scan those file locations when they are accessed by the processes in the low risk process list, therefore saving the machine the stress of having to monitor what the exchange processes are doing.
See the below for reference:
In hindsight, it might have been easier to just link these two articles...
Thank you for taking your time. This is a very good explanation however I am not sure if I understand the last part: "So if we want to add exclusions to help the performance of your exchange server, we'd add the exchange processes to the low risk process list, then add the locations that those processes access to the low risk exclusion list. This way, McShield won't scan those file locations when they are accessed by the processes in the low risk process list, therefore saving the machine the stress of having to monitor what the exchange processes are doing".
For example MS KB says:
Many antivirus programs support the scanning of processes, which can adversely affect Microsoft Exchange if the incorrect processes are scanned. Therefore, you should exclude the following Exchange or related processes from process scanning.
Microsoft Exchange Compliance Audit service (MSComplianceAudit)
Should I put ComplianceAuditService.exe in low risk and
%ExchangeInstallPath%Bin under exclusions paths?