Users unable to login to terminal server with Webroot installed.


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. 

198 replies

Userlevel 2
I posted the settings in this thread. I believe that they are on the first page.
Userlevel 2
We have tried the modified policy settings and they don't appear to have helped, we have also tried an alpha agent that webroot support gave us to try on the terminal servers and it didn't help. WR support has stopped updating us on our support ticket so we are quite stuck with many terminal servers just having no AV at all.
Userlevel 6
Badge +26
? - doubling up here from another post, but for those others on this forum, the latest agent build that went out this week, 9.0.13.x has the TS fix. It was a tough one and difficult to find, but development finally sorted it out. If you haven't updated your TS servers, go fot it now... FYI.. if you're running Server 2012R2 and TS - there's a MS KB fix for that one,
 
 
Userlevel 2
I did happen to see that just shortly after my post earlier that this was mentioned in the release notes for that build and I am very hopeful. I'm switching out the test agents to the latest prod now to test that and was waiting til I could confirm it was fixed before posting. I'll post back when I have confirmation, it may take a few days since we are waiting for it not to break.
 
Either way, thanks for working on the issue and updating us!
Userlevel 1
We have an RDS server where this issue happened 3 times yesterday, and many times over the past 6 months or so.
 
Webroot 9.0.13.58 installed.  So, not sure it's solved just yet.
 
We have removed Webroot as of today, we'll see what happens.  And no, we can't provide logs or work with Webroot support, this is a production server (where 50+ people were kicked out 3 times yesterday) - customer is not happy.
Userlevel 6
Badge +26
? - Environment? Windows OS? ESX? EVT error? Patches and the like would help. PM me directly or email me: scooper@webroot.com and I'll get the appropriate team involved.
Userlevel 1
Environment: Hyper-V cluster
WIndows OS: Server 2008 R2 
ESX: No
EVT error: 4005 as others have reported
Patches: Fully patched per windows update
 
As I mentioned, we're just trying to keep the server running for our customer right now, so we're not in a position to work with Webroot support.  If and when that changes, I will email you.
 
Just wanted to let you/others know that the issue may not be solved after all.  I guess we'll see what others report here over the next few days/weeks.
Userlevel 2
So far I haven't had issues with the terminal servers on 9.13.58 but getting the alpha client off and the prod client on was a challenge on many of them and they had to be done manually so I just finished the last one yesterday, still waiting to make a final judgement.
 
We never did have users kicked off of the servers though, existing sessions worked fine they just wouldn't let new users connect so maybe this is a new/different issue? If that were to happen I'll definitely be in here 😉
Userlevel 1
Same here, i.e. users not kicked off but no new sessions can login.  Also difficult because even we can't login to see what users are logged in and ask them to log out.  We literally have to "turn off" the server at the Hyper-V level because it won't even respond to a Hyper-V shut down request when it gets into this state.
 
People are literally working on the server and all of a sudden the server is rebooted.  It's a bad situation all the way around.
 
I'm hopeful that removing Webroot fixes this one for now.  We will continue to monitor this thread to see if things get better.
Userlevel 6
Badge +26
Thanks for clearing the environmentals up as the issue is very different depending on how the systems were set up. It's not an "All Terminal Server or RDS issue", rather it's isolated to JUST virtualized TS/RDS setups/configurations. Physical servers are NOT affected.
 
So, that does explain one variable we may have to address, MS Hypervisor. All of our field reports were around ESX as the virtual environment, not MS Hypervisor.  I know personally our internal tests were all done on ESX as that's our primary test setup as it is more prolific in the field than MS's Hypervisor.
 
I'll get this over to escalation and test teams post haste to see if we tested both and/or if we have focused on MS Hypervisor.
Userlevel 2
wanted to note that yes all of my environments are esx so it is possible that is the issue
Userlevel 6
Badge +26
All - we're re-setting up a Hyper-v test environment. Several have privately shot me a note with versions and specific EVT errors etc... (logs will help, but not necessary) post any specifics about your setup that you believe will help in our testing efforts.
 
Thanks - Shane
Userlevel 1
Thanks, that's good news.  I'll continue to monitor the thread to see what progress is made.
We are seeing these same symptoms across several of our customer's (we are an MSP).
 
The terminal servers are not exclusivly virtualized, but we are seeing this issue (with winlogon crashing) on multiple different terminal servers running multiple versions of Windows server with different configurations. The only commonality we found so far is this possible Webroot issue.
 
Looking forward to seeing the conclusion of this thread. Thanks for looking into this.
? - in my case, I'm able to run Remote Desktop Services Manager and connect to the affected server, which allows me to send a message to the users who are still logged in - not great but still better than shutting it off with no warning. I could also log them off from there, although I don't know how helpful that really is.
 
? - you stated you're all ESX, however it seems that most everyone else here is reporting Hyper-V (myself included) - I guess that tells me that this is hypervisor independant.
 
We started fighting this almost a year ago - I can't believe I spent as many months banging my head on it as I did and somehow didn't even suspect the AV we'd just rolled out. We actually went mostly from mid-March-ish or so till pretty much last week without an issue though, so I guess I kind of thought the goose-chasing patch/hotfix install/removal Microsoft had me must have finally done the trick. Although I've also scheduled daily reboots of all the RDS servers as well.
 
Anyway, we just had another ocurrence near the end of the day today on one of our customer servers before I found this thread. I was super hopeful to see that a fix was recently released, however I logged into our Webroot console to find the affected server is already running 9.0.13.58 - unfortunately it doesn't look like this is the solution in all cases - much like the previously suggested policy change, which I haven't tried. The reason I haven't tried it is the last line where it says, "Real-time Shield - Scan files when written or modified - OFF" - correct me if I'm wrong, but if that prevents files that are newly downloaded from being scanned then it seams like it's kind of defeating the purpose. I guess if it still scans on execution then that's better than nothing, but a fix to the application itself would still obviously be far more desireable.
 
Our Environment:
Windows Server 2012 R2 Hyper-V
RDS VM's running Server 2008 R2
Everything fully patched
4005 Windows Logon process terminating unexpectedly (like everyone else)
 
Looking forward to an actual resolution to this - I like everything about Webroot except the fact that it occassionally takes my customers completely out of commission.
Userlevel 2
? I think you missed the webroot employee post directly above my post of having all ESX in which ? said
 
"So, that does explain one variable we may have to address, MS Hypervisor. All of our field reports were around ESX as the virtual environment, not MS Hypervisor.  I know personally our internal tests were all done on ESX as that's our primary test setup as it is more prolific in the field than MS's Hypervisor."
 
I was just trying to clear the water since I so far am seeing the issue as fixed, that it wasn't confused as a statement of being fixed on hyperv, by stating that I'm all ESX. 
 
The sudden influx of hyperv users to this thread after the 9.0.13.50 patch was released that was supposed to fix this on esx hosted terminal servers actually may have caused it to start happening on hyperv servers again. In any case they are setting up a hyperv lab for testing now so hopefully can find a fix that works for both.
? - yeah I see what you're saying now. I guess it's encouraging that they may have fixed it on one platform - hopefully they can fix it on the other next. I guess we're luckier than some of the other people having the problem in that we're only seeing it about 1-2 times per week across maybe 12-15 customer servers over the last two weeks or so. So that's only three servers but when it was going on about 9 months ago I had it happen on about 6-7 total at about the same frequency of 1-2 per week.
Userlevel 6
Badge +26
? - We've been focusing on TS running in virtualized environments. If you're having issues on physical boxes, you may want to look at microsofts kbs regarding TS, as that's unusual from what we've learend. They did patch 2012r2 due to deadlocks at the kernel level and it's focused on viruatlized machines as well.
 
If you have a Windows 2012 R2 Terminal Server environment running virtually, we suggest performing the Microsoft updates.
 
 
Userlevel 6
Badge +26
? - just curious, have you applied this specific patch for server 2012r? I know you said all patches applied, but this was more of a KB and I'm not sure if it's part of the auto patch or not.
 
KB3179574 (https://support.microsoft.com/en-us/kb/3179574)
Hi Shane -
 
I do see it installed on the one 2012r2 server that we've had this problem on, but obviously not on any of the rest since they're running 2008r2. That's a pretty long list of fixes associated with that roll-up so I hate to uninstall it, but obviously I guess that's got to be balanced against this problem.
 
Thanks for the follow up and looking forward to any news about this being resolved for Hyper-V based RDS servers.
 
Hi All,
 
We are having same issues here and been ongoing now for past month or two.
I have just had 2 days in a row, whereas sometimes it may be a week or more.

Windows 2008 R2 Server. We have approx 30 staff logging in via RDP Connection.
Webroot version 9.0.13.58 installed.
.
We do have patches KB2621440 & KB2667402 installed and have been installed for long period with no issues previously.

All of a sudden users are unable to RDP to Terminal Server. Seems to be more of an issue first thing in the morning, and hasnt occurred so much in working hours. Thats why I was looking at backups/snapshots  and other processes which may have been causing at that time until I found this post.
 
You can connect however via Hyper V but it does lock up loading policies screen. It connects but fails the login process.
 
The only way I have been able to resolve this issue for an immediate emergency fix, is to instruct Hyper V to Turn Off the virtual server in question. I have tried shutdown command but it fails.
 
Any info on issue would be greatly appreciated. 5:00am phone calls are becoming a bit too much to restart server.
 
 
Joined up specifically to add to the list.
 
We are experiencing issues with our RDS servers accross multiple sites since around mid-September. The server's are all running on Windows 2008 R2 and have Webroot installed (they are up to date, with the latest version v9.0.13.58).
 
The issue we run into is the users are unable to connect to the RDS Server, on reveiwing the Event Logs, we see a heap of Winlogon events, with Event ID 4005. The only fix we have found is to reboot the server. On some sites, we are performing this reboot daily, and on occasion twice a day. There doesn't seem to be a defined trigger for the problem that I can find.
 
The servers are running on a mixture of either physical hardware, and also ESX 6.0. Some of the servers have the patches KB2621440 and KB2667402 installed, and some do not. On 1 particular server I have removed the patches, and re-installed them to test the result.
 
I'll keep an eye on this thread to try out any potential fixes and report back as we go.
 
Same issues for us.We have 5 terminal servers across a few clients with the same issues. All of them are running the most recent version of WR; the MS updates removed if they were installed. However, I just modified the policy to see if the changes described on the first page of this thread are helpful for us.
We've had this problem happening more frequently this week - affecting 3 clients yesterday and today. Virtualized server 2008 r2 RDS hosted on hyper-v, some have 2008 r2 hosts some 2012 r2 hosts - running 9.0.13.58, 9.0.12.52, with the policy changes from start of thread applied. the 90.13.58 update I believe possibly may have made it worse considering we had 3 alone yesterday?
I have been chasing this issue for some time. We have 2 clients, one in Hyper-v w/2008 Terminal servers, and one in esxi5.5 w/2008 terminal servers...Both client are running into the exact same issue in this thread. We create a policy group using the same settings on page one, but we still get the winlogon issue about once a week  or so. Webroot is current on all of the terminal servers for both clients. 
 

Reply