Any input/clarification woudl be appreciated. In our environment, we are only using the OnAccess Scanner and only the All Process Policy and have that set to only scan on Writes. According to Microsoft Guidance for Anti-Virus exclusions, they have a section titled Processes to Exclude from Virus Scanning and have the following listed.
%ProgramFiles%\Microsoft SQL Server\<Instance_ID>.<Instance Name>\MSSQL\Binn\SQLServr.exe
We run multiple instances and versions on our server, and I'm being asked to provide the full path to the SQLServer.exe for all instances. Although I can get the list pretty easily, I'm questioning if doing this will have any impact as I think they are mis-interpreting the guidance.
My belief is that because we are usiing the all-processes policy, then the SQLServer.exe is included by default and does not need to be listed as an exclusion. Plus the policy is to only Scan on Writes, and we won't ever write the SQLServer.exe. They are reluctant to enable the Low-Risk and High-Risk profiles, but if then did, then SQLServer.exe should be added to the Low-Risk. Yet that is still different then adding it to the exclusion list.
I know providing them with the full path that they are asking for is the easy thing to do, yet I think it is just cluttering up the exclusion list and confusing people on what they think might or might not be happening.
Another reason for not adding it is that they already have the full path to the instance defined with exclude all subfolders...
%ProgramFiles%\Microsoft SQL Server\<Instance_ID>.<Instance Name>\MSSQL\
Which again I believe would be enough to ignore a scan on the SQLServer.exe
Rich topic that is prone to misunderstandings.
There is a slew of KB's becuase of this on the topic.
I'd recomend this one, as it has a video
If your using "All Process Policy" that means All Procceses are scanned with One profile.
With that said, only Scanning on Write, is a touchy topic 🙂
See full reason here from William Warren blog here:
Attempting to give a short answer i'll quote an Except from a post by rmetzger
Quoting William Warren's Blog:
William Warren speaks at greater length on this in his blogs and I would highly recommend reading his info.
If performance is the issue you wish to address, there are many means available that can improve performance while leaving Scan on Read Enabled.
Enable use of High and Low
Turn off read and write scanning for low Risk
And add the Process name SQLServr.exe as a Low risk Process
(look at turning back on Read scanning for Default and leave on for sure in High Risk.)
Add path\patern exclusions to High and default.
Look at a migration plan to ENS where a trust model is used for scan avoidance.
dmcgeary thanks for the through reply. I have now watched that video 3 times. It is the reason I'm questioning the way we are implementing exclusions. I'm not in control of the way we implement the virus scan, but I have suggested the use of Low and High risk profiles. The group responsible has said this is a new feature that they are not familiar with and they will review the use in the future, but right now they are confident the exclusions they have are working as desired.
Can I ask a simpilier follow up question... The guidance from Microsoft where it says Processes to exclude from virus scanning... It lists the full path to the 3 SQL exe's. The team here is assuming that by putting the full path to the exe in the exclusion list that they are meeting the guidance from Microsoft and that it will be treated as a 'process' versus simply a file exclusion when the the .exe is read and written. Does putting in the full path to the .exe in the exclusions mean that VirusScan will treat the process as a Process and exclude any read or writes that exe does from scanning?
Download the new ePolicy Orchestrator (ePO) Support Center Extension which simplifies ePO management and provides support resources directly in the console. Learn more about ePO Support Center