Issue with SMB shares on 1709 and 19.0.19.43


Hi.  We have recently seen a number of individuals running W10 build 1709 and WSA 19.0.19.43.  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.  

19 replies

I have submitted a ticket.  That article is interesting, and I can check some of those on a future case should one come up.  In our instances, we had 2 computers that were installed from scratch with 1709 and WRSA 9.0.19.43 exhibited the issue.  One other was working on 1709/9.0.18.44 without any issues until upgrading to 9.0.19.43.  All three required no further changes beyond uninstall WR/reboot.
For our systems, the Windows features already were set as shown in number 2 from the article.    This explains whey we didn't have the SMB issue.   It had no effect on the issues with netlogon and fall out from that.   9.0.18.44 is the current fix for that problem.
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 😞
Userlevel 5
Badge +24
@, I recommend testing the new 9.0.20.31 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.
I am not the only one, from the looks of it.
 
http://partnersupport.microsoft.com/en-us/par_clientsol/forum/par_win/windows-10-public-file-folder-sharing-error/78fab29a-f4f3-488f-ba30-e6c47478a7b1
We are having the same issue with Windows 10 in general.    It broke netlogon which had a ripple effect on how we handle internet access for end users.    It took a while to narrow the issue down to Webroot.  Working with support we determined that version 9.0.18.44 is the last version that does not cause the issues.   i had previously uninstalled Webroot then put 9.0.18.44 on all Windows 10 and in a policy where auto update doesn't occur.   Everything is working fine this way and I'm just waiting for a new build that resolves it permanently.
Userlevel 2
I'm not sure if we're seeing the same issue or not -- we're using that same Webroot version in the original post, and for several weeks now we cannot access UNC paths by name but can by IP.  We get this error: "the target account name is incorrect".  The issue remained after I uninstalled Webroot so I'm not sure if we're experiencing the same issues or not.
Just in case, did you restart the host after uninstalling WR?  We initially did not restart and had only sent the uninstall command to the host.  I have now seen that the issue stays until after the restart.  
 
This is in contrast to how quickly the appdata/programdata issue was fixed once you uninstalled WR.  
I'm thinking there are several issues happening.    We didn't have the issue with UNC paths.   Instead, we could not remotely navigate PC drives, check on logged on user, query software, remotely reboot, etc.   This crippled our support.    Once I removed Webroot the problem went away after a reboot which was done interactively through our PC shadowing system.    We had removed Webroot completely from all Windows 10 until we narrowed down 9.0.18.44 works.    In between the PC's would get a reboot command nightly from PDQ.    After adding back 9.0.18.44 everything is back and working and we didn't reboot after that install.    We didn't have an issue navigating shares from a Windows 10 system but to a Windows 10 system would not work.  
Userlevel 7
Badge +35
Our product team is investigating this issue. It would be helpful if you all could please submit a support ticket so that they can gather more information. 
 
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/
We have had this issue since version 9.0.19.36 and reported it in January. Uninstalling, cleaning then reinstalling 9.0.19.36 seemed to fixed the issue for a while. Version 9.0.19.43 started rolling out first week of February and we then had a lot of upset clients affected again by this issue (approx 24% of all endpoints now). Currently we have had to disable auto updating on the policies then roll back to 9.0.18.44 to get things working again.
 
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 9.0.18.44 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 9.0.19.43 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 9.0.18.44 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 :(
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 9.0.18.44 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.
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!
Userlevel 5
Badge +24
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.
Userlevel 5
Badge +24
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 9.0.18.44 to a 9.0.19.43, 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.
It looks like 9.0.20.24 BETA addresses the NETLOGON issue.   I'm hoping a production release is coming soon. 
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. 
How do we get the 9.0.20.31 release?   It isn't showing on our site yet.

Reply