Folder Excluding

I have two applications that are older and use FoxPro. These applications are Sage Abra and Galaxy Timestar. These applications collect time punches and produce the payroll information used for paychecks. The contractor the installed and supports the application says we have to exclude two folders.

We have done that for 5 years and everything was fine.

When we installed WebRoot it 'killed' the applications.

It would be nice if we could designate a folder to watch and report but not act on anything it finds that would be very helpful.

104 replies

Hello,
We corrected a false positive after reviewing detections under your keycode which should correct this issue. As long as the application that is writing these new files is marked as good, the files it writes should be allowed.
If you continue to have troubles with this issue please let me know and we may have to gather logs and create a whitelist rule on the backend for that application.

Rather than having to identify all the programs in a directory, it would be helpful to just designate the directory. This is needed with the way that identify shield works, since it doesn't identity what programs in the scan log nor the admin console.

This is a great idea as an End Point Solution to be able to exclude folders and put the excluded folder or folders in Monitor mode and also just in case an infection does enter that exclude folder it will be detected! IMO

We went about this a little differently than suggested, but we believe we have put in place a feature that will allow you to accomplish essentially the same thing. You now have the ability to perform multiple overrides at once in the console. Administrators who would like to whitelist the contents of an entire folder should scan that folder and review the unknown programs via the "Endpoints with undetermined software on last scan" report. Select all of the files you wish to whitelist and hit "Create Override."

I'm a new customer, and would like to echo this request. While the batch overrides are helpful, they aren't a realistic solution. We've got a number of apps that have thousands of files, and our performance has taken a significant hit since deploying your product. My report for undetermined software is something like 2500+ files. Having to review 50 at a time, and pick and choose within that list is ridiculous. Not only should I be able to display more than 50 at a time, but you need to fix the sort by folder - at least then I could pick ALL the files within an application.

Srstuart, thanks for bringing this up. I can see how that would still be an issue for you. We will address this with product management and see if a different solution can be implemented for cases like this.

I hope that this will be moving forward quickly, was considering using this product, but found that I cannot exclude a folder which killed our demo right as it was starting. One of my clients has a line of business application with hundreds of exe files that change on a weekly basis. It would be impossible to "override" each file and modify rules weekly. Additionally, Watchguard reporting REQUIRES the logging function to not be scanned or it will kill the DB, which has happened too many times to me to count.

We're a software development company (SQL database and .NET dlls & executables) and as a result we modify programs, push them to various test servers (several dozen), test for awhile then mod again, etc.
The issue I'm having is that some of these EXE's are getting blocked by the "Realtime Shield".
I've tried turning off all sorts of combinations of other shields and the only way I can get these EXE's to run is to turn the Reatime Shield off - NOT what I want to do!!!
These programs are NOT always picked up as threats - at least they're usually not "Seen" as threats on the endpoints section of the management webpage.

So... what I tried first was to create a global override for the programs that were found as threats - and that worked for those few.
But now that I've got programs being blocked that aren't picked up as threats it's harder to get their MD5 values.
Beyond that, there are 300 to 400 of these EXEs that are being constantly modified - hence their MD5 values are changing...

What I REALLY need to do is create an override for any file found in a specific location on a server.
Something like "Allow" any file run from the location: \Fileserver1AppBIN
*** The ability to WHITELIST A FOLDER would be a tremendous addition to this application's capabilities! ***

Is there any way at all to do this in SecureAnywhere?

Honestly, if there isn't an easier way to do this than add a global override manually for every new version of every EXE as they're released from development then I've got to rethink whether we're going to be able to use SecureAnywhere.

Webroot seems like a good product which is deficient in an important feature "folder exclusion". I understand the reasons stated for not including this feature but there are several cases where it is most definitely required

1) Database files - in this case antivirus files interfere with the database by placing locks on the file while scanning. This causes symptoms such as poor performance, random application failures when the database programs cannot access the file when it needs or as it expects to. These files can be very large and are accessed/updated very frequently especially for multiuser database applications.

2) Network mapped drives

– in this case the files on the server have already been scanned by the server antivirus and re-scanning is waste of time. It also negatively effects performance and can cause intermittent locked file issues.

3) Applications loaded from a server – here the application files are copied from the server to the PC over the network as required and then run locally. Scanning can cause problems such as performance issue, false positives causing application failures etc. As in 2) above the server antivirus should be monitoring the files and rescanning represents waste of time and resources.

These are not theoretical issues. We have seen these for real in customers systems over the years and also with one customer recently who has started using Webroot with out software. Their “fix” was to exclude on a pattern but that is, to put bluntly, crude and imprecise.

If Webroot could exclude based on folders (for the database files) and network drives or UNC mappings (for applications loaded from the server) then it would be a big plus. Yes, it has to be used correctly and judiciously but that is true of any application.

Webroot may have this feature but I couldn’t find it in quick read of the manual.

I have encountered a similar issue with Microsoft's WSUS solution - the WSUS repository folder does need to be whitelisted, since otherwise the update files are often held in quarantine. This prevents the deployment of some Microsoft updates until the file or files have been marked as good and released from quarantine

Webroot is working hard on a number of improvements to Webroot SecureAnywhere Business Endpoint Protection, and although this idea has merit, other issues that apply to a larger percentage of our customer base are going to need to take priority in the near future. As such, we are going to need to move this idea to On Hold so we can focus our resources on other more-commonly requested features. While we will revisit this idea again in the future, this request will need to be deferred at this time.

We're a software development company with multiple development servers.
We MUST be able to "whitelist" network shares on these development servers as it is completely unmanageable to manually create overrides for each of the >300 EXE's in each of the shares on >40 servers on a daily basis.

Until this feature is available - and I have seen quite a lot of discussion on it so I'm surprised the entire concept is "ON HOLD" - I am going to have to find another antimalware solution to implement company-wide.

I cannot continue to manage a split-implementation of SpySweeper & Webroot - and my SpySweeper server is due to be retired...

So, in spite of being VERY HAPPY with the operation of the Webroot applicaiton, I'm going to have to go somewhere else for a workable solution...

Also wanted to chime in on this -- I also am very happy with the overall operation of webroot, but am unfortunately unable to use it for the same reasons as mentioned above by ghopper02 -- we do software development and have an entire tree of executables that change on a daily basis, so maintaining MD5 exclusion lists is completely impractical for us.

This IMHO is a huge requirement/deficiency in the product and one that certainly needs attention, having this in an 'on-hold' state causes us a problem with other vendor solutions that publish KB' detailing endpoint AV configuration. Approaching these vendors with a 'we use Webroot and cannot exclude a folder' simply gets the response 'well you need to use a.n.other AV solution then.

Surely this is has to be something you guys@Webroot wish to address one way or another as a priority!?

Hi All,
I think it is not an isseu of who using what kind of development tools etc.
A lot of our customers who had their apps custom build, or still get their updates from external sources.
So a "simple" folder exclusion on a drive or UNC path would in most cases do.

Most of our several dozen build tools are either totally custom or modified versions of open source build tools, and they change over time. Naturally, the many hundreds of executables (both exe and dll) that are produced by the compiler are also custom and change over time.
We had to go with ESET for now since they support folder exclusion, but we can reconsider WSA again once/if folder exclusion is added..

I concure that there MUST be an exclusion for directories. I am a computer security expert and I have directories that can NOT be touched by Webroot. This directory has dozens of subdirectories which in itself has hundress of more subdirectories with thousands of files. Webroot has made it extreemly diffiuclt to condut business with SecureAnywhere lacking the ability to exclude a directory or drive letter.

Knowing this now, I have pulled Webroot off of our inventory and are placing the security solution on a Do Not Purchase until this is resolved. If Webroot has an alternative solution, please have an AE contact me.

Cookie policy

Cookie settings

We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.