As I understand it, Webroot used a hash instead of using filenames or folders to bypass or override files. That hash can present a problem as file hashes change with some products, causing us to constantly keep adding more overrides to the list.
Has this issue been resolved or is there a workaround?
Has Webroot come up with a way to work with Spector 360 or other user activity monitors?
Hi there Scandoc,
I work on the enterprise support team and thought I'd answer this directly. Unfortunately, at this time, you are correct. The only way to get Webroot and Spector to work together is to set up individual overrides on a per file basis. I know firsthand how tedious and frustrating this approach is. However there is light at the end of the tunnel. Our dev team is working on getting file path exclusions put into the software, so you will be able to exclude entire Spector folders. It's currently in QA, but unfortunately I don't have any exact info on an ETA.
With that said, in the meantime we do have some best practices that you can try with the software. To start, your best option is to put Webroot into the unmanaged or silent audit policy. This will prevent the SecureAnywhere from pulling Spector off the machine. Once done, run a scan. The scan will come back red with all the active pieces of Spector being flagged as malicious. At this point you can save a scan log locally somewhere. It opens as a text file in chronological order, with the newest information being on the bottom. Scroll down, and you will see a list of "Infection Detected" results with file paths and MD5's. This is what you'll need to build your Overrides off of within the console. You may have to repeat this a few times to get all the Spector processes overridden.
If you can, the best option for now is to suppress Spector updates. Once you know of an update, move a single machine into the unmanaged or silent audit policy, let Spector update on that machine, then repeat the steps above.
I know this is an incredibly laborious and time consuming process, and I do apologize. We are working on a more permanent solution, however the above steps should help in the interim.
-Waymon B.
Enterprise Tech Support.
I work on the enterprise support team and thought I'd answer this directly. Unfortunately, at this time, you are correct. The only way to get Webroot and Spector to work together is to set up individual overrides on a per file basis. I know firsthand how tedious and frustrating this approach is. However there is light at the end of the tunnel. Our dev team is working on getting file path exclusions put into the software, so you will be able to exclude entire Spector folders. It's currently in QA, but unfortunately I don't have any exact info on an ETA.
With that said, in the meantime we do have some best practices that you can try with the software. To start, your best option is to put Webroot into the unmanaged or silent audit policy. This will prevent the SecureAnywhere from pulling Spector off the machine. Once done, run a scan. The scan will come back red with all the active pieces of Spector being flagged as malicious. At this point you can save a scan log locally somewhere. It opens as a text file in chronological order, with the newest information being on the bottom. Scroll down, and you will see a list of "Infection Detected" results with file paths and MD5's. This is what you'll need to build your Overrides off of within the console. You may have to repeat this a few times to get all the Spector processes overridden.
If you can, the best option for now is to suppress Spector updates. Once you know of an update, move a single machine into the unmanaged or silent audit policy, let Spector update on that machine, then repeat the steps above.
I know this is an incredibly laborious and time consuming process, and I do apologize. We are working on a more permanent solution, however the above steps should help in the interim.
-Waymon B.
Enterprise Tech Support.
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.