Skip to main content
To Customer Support To Customer Support
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.

 
This is not a fix when you're an MSP....
How am I supposed to do this across 3 GSM's with over 3 thousand client sites????? 



NOT GOOD ENOUGH. 
We need a fix for standard windows users who need resolutions now and now ones running it as a endpoint solution. 
This is not a fix, we can only hope that it didn't do too much damage.
What do you do if you manually added an override for specific policies?  How do you undo that?
This is not a fix.  This is a "hey, restore your files manually from the quarantine on all your endpoints".

 

A fix is an automatic rollback.

 

Figure it out.
Also, why can't we display threats found. It's now showing files or MD5's...

 

 
Not working here...can't get any files to restore. I need a drink.
When this is over Webroot better be buying!
Can you confirm thatthe issue causing the false positives has been addressed? I need to know if we have to disable Webroot entirely to avoid further disruptions. 
Please post an actual fix. This is useless as the scans don't show the MD5 of the quarantined files.
I can't get all the md5's. How come I can simply restore from the endpoint machine via the quarantine? Anyway to grant permission for that at least?
I've added the override exceptions for the MD5's that got flagged.  It appears that no other endpoints are getting these alerts for these MD5s, cool.

 

Then I attempted to restore the files for the individual endpoints that ran into issues but that has not worked.  Does this typically take a while to restore or am I perhaps doing something incorrectly?  It has been about an hour since I restored.

 

Thank you for your hard work getting this back to normal.
The md5 I'm trying to restore is invalid. We have a TON of alerts popping up. We've suspended realtime protection. IS there a way to restore these all at once
We need a real fix for this ASAP. I have damaged programs all over the place, at least one of which will require a complete re-install to re-register it. 
Even small businesses need a better solution....doing this over and over is very time consuming.
I get the following error when trying to restore a file via MD5... 

 

The rule that caused this issue was live for 13 minutes before it was caught by our in-built safeguards. The result has been to mark files as trojans false positives. The rule was removed and we are in the process of rolling back all of the false positives that reside in the Webroot Threat Intelligence platform. Once this is achieved, the agent should pick up the re-determinations. Because the rule has stopped, no other endpoints should be affected by this issue. 

 

As you can imagine, we are all working hard at finding the best resolution for this issue. 
FYI for everyone: A reboot may be required to get the restored files to work properly after they have been restored.  We've been white listing as many things as possible, but the list is LONG! 
Thanks freydrew.



However what about restoring files when the listed MD5 method is not working?
Not trying to be rude or inconsiderate, but isn't 13 minutes a long time? Your monitoring must have seen a huge spike in the first few minutes as I am still receiving emails that have been from an hour ago. I would definitely look more into safeguards. Feeling very frustrated here.
When sending the "restore from quarantine" command - the command log is listing "Not yet received" - even though we have refreshed the Webroot configuration multiple times..
I too have had no luck with restores. Even if I refresh the Webroot agent itself. I think I've seen a couple 0KB files show up in place of the ones that were deleted. Maybe the system is just taking a long time to process. 
We are an MSP and this is causing us serious issues.  We have files that appear to be deleted, not quarantined as a result of this issue.  GSM does not show our missing files as quarantined and logs show nothing either.  I think it's quite a coincidence that files mysteriously are deleted. 



We are facing having to restore to previous day and lose entire day's work for multiple clients.  Anyone else seeing a better way to address this problem on a global scale to recover/restore files.

 

This is costing us lots of time and resources to deal with.  Could use some positive fixes.
I really wish we had more control at the endpoint to manage via passcode or what not. The cloud is great and all until something like this happens. If we had full control locally as well this could be resolved very quickly.

Reply


Terms & Conditions