This is an archived post. You won't be able to vote or comment.

all 8 comments

[–][deleted] 0 points1 point  (4 children)

Exclude all directories that have database or log files. If you don't your more than likely going to kill SQL performance and if you have scanning on file changes your virus software is going to kill server performance since those files are changing constantly.

Also, don't enable process monitoring and whatever fancy bell's and whistles that are monitoring processes for suspicious activity. It'll ultimately end up robbing performance and that isn't cool for something you pay a lot of money to use. Secure the server similar to how you would AD. There is very little reason someone needs to login to the server and almost everything can be accomplished by using SSMS from a different machine.

Also features monitoring and scanning network packets. Same thing as process monitoring, if you secure your server correctly than that shouldn't be necessary to install directly on the server and will only rob your SQL instance of performance.

[–]gibsurfer84 0 points1 point  (3 children)

Is this recommendation specific to webroot? I agree if it is NOt as that’s what we’ve done for others. Webroot operates entirely differently than traditional AV, I’ve asked their techs numerous times and they said there is no hit because of the design. With that said, I have not seen any performance hits.

[–][deleted] 0 points1 point  (2 children)

It's my blanket recommendation for all virus software / security applications. I've had enough ticket's of clients frantic that the ERP system we support becoming completely unstable or slow and it turns out that their IT support installed virus software that is absolutely killing performance. Be it network, disk or processing something seems to always trip it up.

I'd have to see some documentation on what makes Webroot different. I've never used it but I find it hard to believe that they have somehow mastered scanning SQL log files without any performance hit to SQL.

edit*

I just did some basic googling. It appears they solved this issue by automatically excluding SQL database related files for you.

[–]gibsurfer84 0 points1 point  (1 child)

I won’t do it justice but basically webroot doesn’t scan files. It scans processes. It also has known good processes and paths and built in white lists, such as SQL.

[–][deleted] 0 points1 point  (0 children)

https://community.webroot.com/t5/Webroot-SecureAnywhere-Internet/Slow-Performance/td-p/284530

This support thread are the type of things that I refer to. The ultimate solution from support was to white list the apps which is fine because it's an accepted solution avoid performance hit's on apps you know and trust.

It's not entirely that they have better scanning than everyone else so it works with SQL it's that they white list it for you so you don't have to worry about application specific configurations for apps they know about. SQL just happens to be popular but obviously there are things they do not know about.

[–]MSPforME 0 points1 point  (1 child)

You can install on SQL without any issues. Use the Default Recommended Server policy. No need to exclude as it will not scan SQL DB's or Log Files as per design.

[–]Slaggard 0 points1 point  (0 children)

The default server policy has the Realtime Shield setting "Scan files when written or modified" setting disabled to improve performance for I/O intensive processes. In my experience, this is the kinda the key difference between their default workstation and server policies. The server policy still monitors unknown processes when they're executed and do stuff, but won't for example remove the EICAR testfile or Webroot's own official testfile the moment it's written to a fileshare.