Update April 28, 11:45 a.m. MDT:
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.
Thank you.
Page 2 / 12
Where should my company send the bill for all the time we've lost fixing this issue for our clients? Multiple core processors taken down across multiple banks and financial institutions is a very big deal.
manual restores are not processing, is there an ETA to the fix being pushed on your end?
Hello Drew,
Respectfully, circutbreakers are not adequate safeguards.
A safeguard is having a client that can authenticode verify files as being from Microsoft and whitelisting them. It's completely, utterly unacceptable that in 2017 you could quarantine a file signed by Microsoft's root authority. This is a glaring issue.
In fact, I submitted product feedback about this omission last year, warning that this would happen without enforced system file whitelisting. I was seemingly ignored.
You can read that feedback here: https:///t5/Webroot-SecureAnywhere-Antivirus/Product-defect-Critical-oversight-in-file-signing-via-catalog/m-p/259299#M26248
(EDIT for clarification: Note this specific recommendation would have only prevented the issues with Windows 10 Insider Preview)
Webroot's product team needs to go back to the basics of the product and review fundemental protections other vendors implement.
I tell people in my professional circles that I mostly approve of your product and quality control. This is not okay. And this isn't one person's fault, or just human error. Humans make mistakes. I make stupid mistakes and have bad judgement. But systems are supposed to be designed so those mistakes are mitigated.
Regards,
explanoit
Respectfully, circutbreakers are not adequate safeguards.
A safeguard is having a client that can authenticode verify files as being from Microsoft and whitelisting them. It's completely, utterly unacceptable that in 2017 you could quarantine a file signed by Microsoft's root authority. This is a glaring issue.
In fact, I submitted product feedback about this omission last year, warning that this would happen without enforced system file whitelisting. I was seemingly ignored.
You can read that feedback here: https:///t5/Webroot-SecureAnywhere-Antivirus/Product-defect-Critical-oversight-in-file-signing-via-catalog/m-p/259299#M26248
(EDIT for clarification: Note this specific recommendation would have only prevented the issues with Windows 10 Insider Preview)
Webroot's product team needs to go back to the basics of the product and review fundemental protections other vendors implement.
I tell people in my professional circles that I mostly approve of your product and quality control. This is not okay. And this isn't one person's fault, or just human error. Humans make mistakes. I make stupid mistakes and have bad judgement. But systems are supposed to be designed so those mistakes are mitigated.
Regards,
explanoit
Now the quarantines in the cloud console are empty so I have to restore everything manually. Webroot is now on its way out of all my client machines. Last **bleep**ing straw.
How are you guys restoring the files from quarantine manually? I don't have that option it says that it's "SecureAnywhere is currently managed by the Web Console...." when I try manually restore a file from the quarantine on a system
Is there a way to restore the files from the command prompt on the users computer? It would be awesome if we could quickly write a script in our RMM and push it down tot he clients to restore the files.
Ok the fixes are not working or not restoring the files quick enough. Is there anyother solutions? Can someone please send the instructions on how to find the MD5 file or how to get it into the restore?
I work for an MSP. This is greatly hurting over all of my users. I've run the reverification but it's reporting as not yet received. Is there a way that I can throw all of these end points to a new policy where I can just release the items from the quarantine besides doing it through the console? I can switch the policies without issue but I can't get any of the commands to work.
Is there a solution to manually restore the files locally and how do you do that?
So far, we have found that uninstalling Webroot and then restoring the files from the backup solution and then re adding Webroot....they haven't seem to requarantined
Haven't gotten a release from quarantine or restore file via MD5 to work at all .
I sure hope the Webroot general restore from quaratine back to clients fixes the multiple of other clients we are seeing.
Haven't gotten a release from quarantine or restore file via MD5 to work at all .
I sure hope the Webroot general restore from quaratine back to clients fixes the multiple of other clients we are seeing.
Yeah, you may be able to restore from quarantine in the cloud, otherwise you need to change the policy of the agent(s) to something like unmanaged (that's the only one we have that allows for client-side changes via captcha). Cloud process:
- Click on the Site that "Needs Attention" (never understood why it still needs attention if the files have been quarantined).
- Click on the left "x Endpoints need attention" hyperlink to the endpoint.
- Click on the endpoint in the popup window.
- Select the files you need restored from quarantine.
- Click Restore from Quarantine.
When I try to go to AntiMalware Tools and Restore File, if I put in the MD5 hash it tells me the hash is invalid.
We have word that the console is overloaded and not processing the backlog of requests as quickly as we’d like so the most affective way to restore these files is locally via the agent but the agent must first be put into an unmanaged policy, the agent must poll to change its policy, then the user/admin can restore the files from quarantine. We recommend starting with the most critical first.
We already tried putting the agent into an unmanaged policy and although it did alow us try attempt to restore the files, the files never were restored, and then shortly after the quarantine list went blank. We are now restoring to reinstalling all of the applications manually :-( Hoping we are going to see a credit on this month's Webroot invoice!
I'd like to file a complaint.
Tell your agents to pick up the phone. 1 hour 11 minutes on hold so far.
edit1: 1 hour 1:53 minutes.
edit2: 2 hours 19 minutes
edit1: 1 hour 1:53 minutes.
edit2: 2 hours 19 minutes
glad you got through, all i get is busy signals.
And how do you recommend that we put the clients into an unmanaged policy if the commands from the console are not being processed?
Our agent is set to a 15 minute polling time but commands from the console are not being executed for well over 2 hours now.
Our agent is set to a 15 minute polling time but commands from the console are not being executed for well over 2 hours now.
We spent an hour on hold and spoke to an agent. Same answer - follow this process. The console is getting hammered, thus restore commands are not processing. There is no local restore option if the agent is cloud managed.
The agent suggested uninstalling Webroot and then restoring or reinstalling the affected program. This was a laughable suggestion to be sure - except we didn't find it very humorous.
Seems like we found a major flaw in the underlying program. If the cloud console is having issues - then nothing can be done on the local agent in case of emergency. This is definitely something that will need to be reviewed and addressed moving forward.
We have found that sometimes you can refresh the agent, reboot the endpoint, and it will get the restore done.
The agent suggested uninstalling Webroot and then restoring or reinstalling the affected program. This was a laughable suggestion to be sure - except we didn't find it very humorous.
Seems like we found a major flaw in the underlying program. If the cloud console is having issues - then nothing can be done on the local agent in case of emergency. This is definitely something that will need to be reviewed and addressed moving forward.
We have found that sometimes you can refresh the agent, reboot the endpoint, and it will get the restore done.
I attempted to restore files from quarantine 3 hours ago and they're still not restored. Same with MD5.
.
UPDATE: We've got an update on the initial post in this thread. Wanted to make sure that all of our subscribers got the message.
Go to grop policy managment , select the device and "apply policy to endpoints"@ wrote:
How are you guys restoring the files from quarantine manually? I don't have that option it says that it's "SecureAnywhere is currently managed by the Web Console...." when I try manually restore a file from the quarantine on a system
pick unmnaged
then on the client rigth click the taskbar icon and refresh the config , click ok on pop up then open locally
Thanks. I eventually figured that out, but oddly enough the files wouldn't actually restore this way either. It let me restore the files but they never appeared on the system. Couldn't wait any longer so ended up reinstalling the application.
Reply
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.