I've not received any updates from support regarding my open case about this. With no activity on this forum post I assume it is the same for all. We finally moved all Windows 10 back to 18.104.22.168 and turned off auto updates. It was a very painful and manually process. Our renewal is later this year. I want to stay with Webroot but it really depends on how this issue plays out and what happens after that.
The last update we had from a few weeks ago was that the dev team are working on it but they are having mixed results with the potential fixes. On an effected endpoint we can reboot it 50 times in sucession and it is seeminly random when it faults (on,off,on,on,on,off,on,off,off,on,off,off,off,on etc). I imagine this is probably just as frustrating for the devs as well. All in all though this has been a disaster, especially in our client's confidence in the product.
The worst thing for us though (as you point out) is that there was no easy/scriptable/automatable way to roll back the clients. We had to connect into each one affected and manually uninstall (as the uninstall command from GSM only had a 40% sucess rate!!). Once uninstalled our RMM scripted the WRData cleanup and pushed out the older version. It would have been much nicer if there was a rollback tool from Webroot for this (and any future) version issues. If there was such a tool it would have saved us many days of non-stop work rolling back the endpoints manually
I received the following update from my case with support:
Our development team has already found the underlying cause and working on a solution for this which will be included in the next agent build.
A light at the end of the tunnel!
We have the issue as well, and opened ticket 155126 for the issue.
A problem I mentioned during last April of 2017 (and have re-iterated several times during my feedback with Webroot) is that there is no good method of version control from the GSM console for MSPs or system administrations. We actually need the ability to "roll back", just as others have said here. The method Webroot would describe to help us is currently:
1) Deactivate the antivirus on all clients
2) Wait for a poll command to occur from the clients (and hope the poll command works more than 90% of the time, which is problematic for us)
3) Possible cleanup of Webroot remains (WRData, etc.) once deactivated with an RMM script, because Webroot does not have its own uninstaller/cleanup utility, stated because of the purpose of being secure and not being exploited (I understand this, but we need some method then from the console even if it isn't exposed to us, that is part of the Deactivate process)
4) Manually touch each system to reinstall (or if lucky, use an AD or RMM environment to install, doesn't work in a managed environment of workgroup systems without RMM).
This means relying on a component outside of Webroot to do a job that needs to be done on the inside. It also illustrates that the "poll" command is woefully inadequate, as it requires the client workstations to query back in, as opposed to the GSM console sending a push command out (which could act evenly and at a synchronized time with an entire client's workstations, rather than requiring that people wait around in hopes that something will complete, which isn't always a given). Years ago, when I was running Symantec Endpoint Protection, the server console let me send a command to our agents, and actually reported the progress of that command, and whether it completed successsfully, or timed out (offline system) or had an error. I don't even have that without an adjunct command, and without rollback, no ability to make all of these functions part of this product, a "managed product".
Between this, and the fact that while issues with SMB shares and Netlogon crashing were known in the final week of March but won't see a likely fix until near-end of April (according to Webroot announcement, which I had to search for to find, rather than being notified by e-mail as a partner, leading to a week's worth of our own diagnosis), this is causing us to question the value of the product vs. a competitor's. It's not that we dislike Webroot, but we have a bug, compounded by feeling like we had to hunt for information, and then wait a considerable time for a fix, with little ability to manage it ourselves, which is what we felt like in April of 2017. We provided a lot of suggestions to Webroot on a conference call then, and the ones that might have helped us here haven't happened. If it's a problem for our clients, it's a problem for us. And if it's a problem for us, and we don't get a timely fix, other vendors will be discussed.
To quote the Godfather: "It's not personal, it's business." And it (SMB shares and Netlogon crashes) is affecting ours, not just on Windows 10, but on Windows 7 as well.
We are now experiencing issues where for some clients, despite setting all of our policies (including the default assigned policy) to off for "Automatically download and apply updates", the Webroot client is still updating on brand new systems from 22.214.171.124 to a 126.96.36.199, completely voiding our mitigation attempts.
This is extremely frustrating for us and for our clients; I have spent a fair amount of time creating our own rollback methods so we don't have to touch tens or hundreds of systems, only to be defeated within minutes of performing them. As others have said, technician opinion of the product is at an all-time low at our company. Is there some other magic bullet that ensures that Webroot will obey its own policies?
If the policy changes were made after the last GSM site update, check that the changes you made in the policy are actually taking effect (try changing a setting that you can see on the client like disabling identity shield etc then right click-> refresh on the client). Since the GSM update none of our policy changes are taking effect at all. You look at the policy in GSM and it looks correct but the settings just don't apply. Almost as if the changes have been saved as a draft but not actually promoted to live (like previously).
This just adds to an already long list of issues we are having - we are now testing out alternatives as it does not look like this is going to be fixed before we come up for renewal (its been over 3 months Webroot!!). Webroot pricing is attractive but ultimately useless if it causes more issues than it prevents.
Just wanted to add my voice to the chorus - I signed up to an account here just to post this issue.
We've also got a number of sites experiencing exactly the same broken shares with WR and 1709 or later (FYI, looks like it also occurs with 1803).
I originally opened a support ticket but they wanted access to the machines and days of support time to resolve - I've yet to experience the problem with a customer who can afford days of downtime while WR support diagnose it!
Here's hoping the next release fixes the issue. Like others here I've uninstalled WRSA on the offending units until I'm sure the issue is resolved.
@ilikewebroot, I recommend testing the new 188.8.131.52 release to see if it resolves your issue. I'd upgrade one or two systems you know are/were having the issue, and see how that works out.