Please click here to see the most recent update.
UPDATE 4/28/17 11:45 a.m. MNT: We have 0 calls in queue on our phone line, and are working through about 80 tickets related to the False Positive repair utility. A good portion of those are simply awaiting customer verification.
Please note, the utility was built to address only this specific false positive issue. It will be deactivated in the future.
If applications are operating normally on your systems, you do not need to implement the utility.
If you haven’t yet submitted a support ticket and you need the repair utility, please do so here. Include your phone number as well with the support ticket.
Best answer by freydrewView original
We've found that if you set the affect computers with an Unmanaged policy, and then have the user "Refresh Configuration" (by right-clicking the green W icon) it will pull the policy from the console. Once that takes effect (usually about ten seconds) you can then enter the UI and restore the items from quarantine.
FWIW, We still were having detections happening this morning, and have had to shutdown protection completely on various companies in order for them to get their production orders out.
We have identified an automated approach to removing files from quarantine. But it will take time to reach all endpoints. A more detailed statement is being emailed to GSM Admins within the next few minutes It will also be posted here. In the meantime you should continue with your own remediation steps (which can be found on Webroot support or at the top of this thread.) I will jump back on here shortly.
We're seeing the exact same problem. Since the Web Console is stuck not doing anything, we tried releasing files locally, only to find that Webroot says it is centrally managed and this cannot be done locally.
Setting the agent to unmanaged seems to work, but this is not a solution. Why can we not seem to change this anywhere in the global policy?
The web dashboard only showed a few of the files affected, but no registry entries. Most had a long list of files and registry settings that were flagged and quarantined shown on the local workstation interface. I had to manually recover all affected files and registry settings using an unmanaged policy.
If you had files quarantined and you have remote access or competent end-users, you might also want to check the local quarantine list for any registry settings that might have been flagged. I know this is late notice, but it might be useful if programs no longer worked, even after quarantine recovery.
Hopefully Webroot will take the registry settings quarantines into consideration in their "fix".
More news shortly. I am working multiple threads so I may not respond instantly.
FYI - Quickbooks is one application that has been damaged for a lot of users.
Thanks for that reply ATechGuy. That "Unmanaged" trick fixed my hosed admin laptop.
Thanks, this worked, although switching them to Unmanaged is not ideal and releasing from quarantine has to be done on a workstation-by-workstation basis. Hopefully Webroot comes up with a better fix. Luckily for us, we JUST started using Webroot and only deployed it to about 70 endpoints. I feel for those with endpoints in the thousands... But not a good first impression.
What does that mean? Has the fix not been deployed? Are we waiting for a fix to be deployed? Do we need to deploy a manual fix?
Can you please comment when the fix is going out and what partners should be doing in the meantime to remediate their situations. Some of us don't have the ability to refresh configuration if we've hidden the tray icon.
This has shown a lot of weakness in the platform. We should not have to go into every site and run manual whitelists and restores for things like this.
This, along with globally removing machines that have not checked in have been a constant request for years now.