Hi. We have recently seen a number of individuals running W10 build 1709 and WSA 184.108.40.206. File shares have become unusable, resulting in a "folder path not found" error in other W10 clients and even from the host PC itself. In all cases, we have found that the host PC can see its own shares, but gets that error when opening them. Other clients get that message when trying to connect to the host, before listing the shares. All of the affected were being managed by the workstation policy with Identity Shield enabled.
We have found that after uninstalling the WR client from the portal, and restarting the host PC, that all sharing/access issues are resolved. As yet, we have not reinstalled WRSA on any of the affected machines and all of the affected are being managed by an alternative AV until we can identify what is causing this.
Already have an account? Login
Login to the community
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
This is in contrast to how quickly the appdata/programdata issue was fixed once you uninstalled WR.
Also, it looks like SMB isuses with 1709 of Windows 10 are fairly common, and there are suggestions online for steps to try: https://appuals.com/fix-cannot-access-network-shares-after-update-1709/
On affected Win10 1709 systems just having Webroot installed casues the issues (even if you disable all protection modules/sheilds & restart). Uninstalling and restarting immediately fixes the issue and after removing the WRData folder rolling back to 220.127.116.11 continues to work.
Symptoms are network related services failing to start or register correctly - particularly netlogon in domain environments and SMB (both workgroup and domain). It causes file shares to stop working and other services such as Cisco Anyconnect and even MYOB AddOn connector to crash. If in a domain it can cripple anything requiring Netlogon including Group Policies and logon scripts.
If anyone is seeing any of these issues with Win10 Build 1709 and Webroot 18.104.22.168 please log tickets with Webroot support so as to put some pressure on the development team to get this issue fixed as it has been an outstanding issue for far too long already.
You can also request the link to the older working 22.214.171.124 version from support but it is unfortunately a manual roll back required on every affected endpoint and you have to disable the auto update in your policies :(
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 😞
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!
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.
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?
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.
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.