We are deploying Webroot to our clients and have been running into an issue with users unable to login at a certain point. After testing we found it has to do with Webroot being installed on there but we cant figure out what is causing the issue and we've had to remove Webroot. This seems to only be affecting Server 2008 R2 environments.
Page 6 / 8
Has there been any further update on this?
We are still having issues also. The latest version (9.0.13.75 with Shield on the recommended minimum) appears to no longer show the winlogon errors we were previously getting. It also appears (as a rough figure) to have halved the number of times the servers crash, but it's still happening.
Today we moved one of our clients to NOD32 as they could no longer put up with it.
Today we moved one of our clients to NOD32 as they could no longer put up with it.
We run lots of RDS servers for our clients, most are Server 2012R2 but we still have some 2008R2 out there.
I've been following this thread and TechNet for what I perceive to be 2 separate issues:
Despite all the workarounds, new releases, etc. from Webroot, it seems (from reading others posts here) that Issue #1 is still happening. It is highly disruptive to customers. Our company has decided simply to remove Webroot from any 2008R2 RDS servers (which immediately solved the problems on all our 2008R2 RDS servers) until we are convinced that this is permanently fixed.
So far we are not convinced.
Our hope is that Webroot is still actively working on this issue (#1 detailed above) and will resolve it soon. The last update I've seen from Webroot on this was in November, so we'll see I guess.
Anyone from Webroot care to comment?
I've been following this thread and TechNet for what I perceive to be 2 separate issues:
- Server 2008R2 RDS Servers (running in virtualized environments) refuse to allow new logins - this is a Webroot issue AFAIK
- Server 2012R2 RDS Servers exhibit Winlogon error 4005 and display a black screen on login - this is a MICROSOFT issue and I don't think it has anything to do with Webroot. See TechNet thread here for much more information.
Despite all the workarounds, new releases, etc. from Webroot, it seems (from reading others posts here) that Issue #1 is still happening. It is highly disruptive to customers. Our company has decided simply to remove Webroot from any 2008R2 RDS servers (which immediately solved the problems on all our 2008R2 RDS servers) until we are convinced that this is permanently fixed.
So far we are not convinced.
Our hope is that Webroot is still actively working on this issue (#1 detailed above) and will resolve it soon. The last update I've seen from Webroot on this was in November, so we'll see I guess.
Anyone from Webroot care to comment?
Things have gone very quiet on this front. Can we please have an update from a Webroot official? Thanks in advance.
Webroot announced last month that they were releasing a fix in late December or early January. It is now late January and we have heard zilch.
I have requested an update and should be able to share something with you in the next couple of days. Thanks!
Okay. Looking forward to a response.
Hi Webroot, any news to report yet?
I'm thinking to deploy webroot at several customer sites where among some customers RDP is being used.
My customers RDP only on Server 2012 and server 2012 R2.
Reading the history in this forum makes me a little worried.
Solving this issue takes far to long.
Can you please put some overall information here;
- What problems have been solved with latest releases.
- What problems still exist.
Thank you!
I'm thinking to deploy webroot at several customer sites where among some customers RDP is being used.
My customers RDP only on Server 2012 and server 2012 R2.
Reading the history in this forum makes me a little worried.
Solving this issue takes far to long.
Can you please put some overall information here;
- What problems have been solved with latest releases.
- What problems still exist.
Thank you!
I agree. It is taking a long time and with it effecting all Server 2012R2 installs it is a major issue. Speaking form someone who is actually running the software the latest version seems to be okay but we are still running with our potection settings at minimum as there has not yet been any word on if we can put them back. Confusingly we also have another thread https:///t5/Product-Questions/Update-on-Winlogin-4005-amp-Terminal-Servers-November-22-2016/td-p/276406 but I agree - this is taking far too long to resolve. If I was you I would hang fire until we get the all clear.
The issue has been ongoing for about a year now. https://www.reddit.com/r/sysadmin/comments/37btp6/2008_r2sp1_rds_server_winlogon_error_4005/
Any news here? It's been much more than a "couple of days"...
Don't hold your breath. It's a very long running issue that they originally blamed on microsoft, then finally owned up to.
Please see the more recent post here for additional information on this.@ wrote:
Any news here? It's been much more than a "couple of days"...
So, in an attempt to fix the issue, the new agent version started causing BSODs, then in order to fix that, the "improvements" that were previously added to help mitigate this issue were removed?
Sounds like we're going backwards here, and you're no closer to solving the problem.
We'll just keep Webroot off any 2008R2 RDS servers as we have been doing.
Sounds like we're going backwards here, and you're no closer to solving the problem.
We'll just keep Webroot off any 2008R2 RDS servers as we have been doing.
We have had to remove it from most of our 2012r2 RDS servers as well.
Is there any update on this issue? We're working on deploying Webroot to some Terminal Servers for our clients and have started to run into the 4005 login issues and servers hard locking until they needed a reboot.
Removed WR from the affected terminal servers, and the issue ceased. A bit dissapointing, but we can't afford this terminal server hard locking whenever it wants.
Tried using the older 8.x WR version, and it auto-updated despite being setup not to. Went through a couple rounds of troubleshooting with WR support, but finally just settled on removing it entirely.
Tried using the older 8.x WR version, and it auto-updated despite being setup not to. Went through a couple rounds of troubleshooting with WR support, but finally just settled on removing it entirely.
yep. just move along. WR detection rates are in the gutter anyway. What have you guys looked at? We installed Avast Business Free and it found lots of things WR missed on the terminal servers that were having issues.
Yep, basically no progress here after over a year. Very disappointing.
We are just not using WR on 2008R2 terminal servers, period. Seems to work fine elsewhere.
We are just not using WR on 2008R2 terminal servers, period. Seems to work fine elsewhere.
Our Team recommends you run the recommended server default policy which has self-protection at minimum and keep rebooting periodically until a build is released with a fix.
A date has not yet been set by the product team, stay tuned.
A date has not yet been set by the product team, stay tuned.
No offense to you or the Product Team, but that's not a solution.
These are production servers, with real people using them who pay us to provide a service. "Rebooting periodically" doesn't help when the server can basically become unresponsive at any time. When real customers call and ask why they can't access their server to DO THEIR WORK, asking everyone to log off so we can reboot the server for the umpteenth time, then telling them that there's no ETA on resolving the issue just isn't acceptable.
The only solution we've found is to REMOVE Webroot entirely, problem solved. Unfortunately, this issue has ruined our experience with an otherwise good product.
These are production servers, with real people using them who pay us to provide a service. "Rebooting periodically" doesn't help when the server can basically become unresponsive at any time. When real customers call and ask why they can't access their server to DO THEIR WORK, asking everyone to log off so we can reboot the server for the umpteenth time, then telling them that there's no ETA on resolving the issue just isn't acceptable.
The only solution we've found is to REMOVE Webroot entirely, problem solved. Unfortunately, this issue has ruined our experience with an otherwise good product.
Before removing webroot from 30 servers, we had them rebooting every single night as cheap insurance, and it still didn't work. Faith lost. Not looking back.
We understand the concern and frustration and have asked for our product team to comment on the resolution and time to solve. We are posting their message below:
Please accept our apologies for the time it is taking for us to get a full fix into Production. We understand that this is a serious issue for impacted customers, and we have making progress towards its resolution. We have reduced the number of customers seeing this issue, but not all of you, and we are dedicated to fixing that.
There are a handful of steps that we need to take in a specific sequence to address these remaining cases, and we are actively mapping those dependencies and planning the timing for those releases. This work is our engineering team’s top priority. We have been actively working with a small number of customers to test fixes and drops, and the feedback they’ve provided has directly led to the approach we are taking.
Once again, we apologize for the extended time taken to get this right and the inconvenience it has caused.
Please accept our apologies for the time it is taking for us to get a full fix into Production. We understand that this is a serious issue for impacted customers, and we have making progress towards its resolution. We have reduced the number of customers seeing this issue, but not all of you, and we are dedicated to fixing that.
There are a handful of steps that we need to take in a specific sequence to address these remaining cases, and we are actively mapping those dependencies and planning the timing for those releases. This work is our engineering team’s top priority. We have been actively working with a small number of customers to test fixes and drops, and the feedback they’ve provided has directly led to the approach we are taking.
Once again, we apologize for the extended time taken to get this right and the inconvenience it has caused.
As a starting reseller, we are pleased to read this, especially to keep us better informed.
Without information/feedback about this issue we are just "floating" in space.
Knowing that your engineers are committed to come with solid solution we can inform our customers to hold on an wait a little longer.
Thank you!
Without information/feedback about this issue we are just "floating" in space.
Knowing that your engineers are committed to come with solid solution we can inform our customers to hold on an wait a little longer.
Thank you!
Hmm Good luck with that 18 months ! we have had this problem !
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.