Are you getting Winlogin Error 4005? If so, there's a workaround for that, which is to uninstall the following patches:

KB2621440

KB2667402

---

There is no error until the time out saying the remote connection is unvailable. It attempts to login and the progress bar "loads" at establishing connection but never connects. 

---

Anything in the event logs?

---

Hi Nic,

 

Just to let you know, we've had winlogon issues on our 2008 terminal server farm, but removing these two patches have not resolved the issue. In fact, we have rebuilt all the servers from scratch, not installing these two fixes, and we still have the issue.

 

I believe my colleague has opened a ticket with support, and we are also working with Microsoft.

---

Ok sounds like it might be a different issue then.  Let me know what support says!

---

We had this issue happen on two of our terminal servers that we installed Webroot on. It would happen once every 6-7 days and only on the two servers with Webroot on them. Since adding Webroot was the only thing we changed we removed it a month ago and have not had a reoccurance since then. The issue persisted about 6 weeks before we removed Webroot and reinstalled the old AV. Rebooting the server would fix the login issue but it not a solution at 9am on a Tuesday when half the office is in an working already and the other half arrives and can't Login. 

 

Our goal is to get Webroot back on those servers as we prefer this solution to McAfee but we need to find a fix for this. 

 

Events that occured that morning around the issue are:

 

Event ID 1 - VDS Basic Provider - Unexpected failure. Error code: 490@01010004

 

Event 1103 - TerminalServices-Printers - An internal communication error occurred.  Redirected printing will no longer function for a single user session.  Check the status of the Remote Desktop Device Redirector in the System folder of Device Manager.

 

Event ID 29 - Kerberos-Key-Distribution-Center - The Key Distribution Center (KDC) cannot find a suitable certificate to use for smart card logons, or the KDC certificate could not be verified. Smart card logon may not function correctly if this problem is not resolved. To correct this problem, either verify the existing KDC certificate using certutil.exe or enroll for a new KDC certificate.

 

 

 

 

---

hi, we too are suffering from the same problem. On 2 terminal servers 2008R2 running about 50 sessions we have random unexpected winlogon errors # 4005. In the same moment an error 20 in Microsoft-windows-terminalservices-LocalSessionManager/operational  is recorded for each error # 4005. When this happens, people already connected to terminal server  work regularly while other users can't access terminal anymore. No other solution is left  than reboot the machine. 

We have removed the 2 MS patches with no result. HKLMsystemcurrentcontrolsetcontrol erminal serversysprocs is configured correctly 

---

Anyone find a solution to this issue?  We're having a similar issues with a 2012 R2 Terminal Server.  After about 5 days, users can't login and we're seeing errors in the event log referring to schannel as well as errors saying the login process has terminated unexpectedly.  It seems like it started around the time we installed Webroot.  I thought it was a DoS attack since the server is public facing, but at the time it stops accepting logins there were no failures in the security log.  We are using a modified version of the default server policy.

 

Troy

---

This was the solution presented to us by support, and so far we've not seen a return of the issue. Hope it helps someone else:

 

"It sounds like our latest release from Friday has some fixes in place for this issue. Can you create a new Terminal Server policy with the following settings? You'll first want to copy the Recommended Server Defaults policy, then ensure the following adjustments are made:



Basic Configuration - Favor low disk usage over verbose logging - ON

Scan Schedule - Time - Choose a day and time that fits in with low disk IO activity (i.e. everyday at a specific time or only on weekends)

Scan Schedule - Hide the scan progress window during scheduled scans - ON

Scan Settings - Scan archived files - OFF

Self Protection - Set to Minimum

Real-time Shield - Scan files when written or modified - OFF



Once that has been completed, I would like to have you try it on one of your servers. Again, I apologize for the delay on this ticket and sincerely thank you for your patience. "

---

We have been experiencing the same issue at 2 sites with the same topology/setup, 2 node terminal server farm, connection broker on a different server, all 3 are 2008 r2, and both are similar sites with mostly similar software/applications on them. We have tried all sorts, changing the connection broker to a different server, building brand new connection broker, checking event logs etc 

Removing webroot resolved the issue

 

We will create new policy with the above settings and re-install webroot with this policy and see if that works, thanks

---

Let us know how it goes!

---

Will do Nic, thanks. We've applied this policy today so we'll see what happens.

---

Hi Nic!

 

Good news, after 2 weeks the terminal servers still haven't crashed.

 

We will start implementing it on more of our client sites that were affected in the past with the expectation this is resolved.

 

Thanks

 

Wesley.

 

 

 

---

Glad to hear it!

---

Hey - we had the issue re-occur last night on one of the machines we originally posted about, it seemed to happen when webroot was trying to update (and was doing a scan).

 

We are wondering, when webroot does a version/program update, does it reset all settings then re-poll to get it's policies applied again? e.g. could this cause a crash situation like we had last night, if all settings reset to default during the program update?

---

I checked with the escalations engineer who's working on this issue. He let me know that the it doesn't re-poll the console to get the policies, it just reloads those from the locally stored configuration.



On the plus side, we have finally figured out how to reliably reproduce the issue, so that means the devs can work on properly fixing this one.

---

Hi,

 

I have been following this for a long time, we installed Webroot on all our Servers/PC/Laptop's at the beginning of the year (moving from McAfee) and along with others here have had our RDS Servers (2008R2) intermittently stopping users logging on to the RDS Cluster until we work out what RDS server has the winlogon error and reboot it, not ideal.

 

So I have tried all the fixes in this thread and none have resolved the problem, I applied the policy settings recommended on 17.8.16 and this morning (7.9.16) got the issue again.

 

For a big company (Webroot) this problem has been around for nearly a year now this is very poor service, yes McAfee was a little heavy on resources and not as easy to manage but if there was an issue with a new release/update/DAT it was fixed within a few days if not the next day.

 

So it looks like I am going to have to install the old version (as previously suggested by support to us) again as this worked ok for months prior to me applying the fix/policy on the 17.8.16.

 

"We recommend copying your policies and disabling the Automatic Updates.

 

Once done, assign this to the server your testing on.

 

Download the agent build from:

download.webroot.com/8.0.8.53/wsasme.exe

 

Then, install the agent via the following method.

 

wsasme.exe /key=(keycode) /noupd

 

This will ensure the agent does not update on install, and also does not update at all as the policy setting is turned off as well.

 

Please note that this build does not support path based exclusions, only MD5 overrides. If you think this will cause a problem, we will need to look at alternative testing options.

 

Since this is an intermittent issue then this test could take a bit of time."

 

In the temp fix suggested by Webroot Support above, as the updates are turned off is this just software updates? So are we still protected against new strains of virus/spyware etc to the same level as if we were running the latest version of Webroot or will the protection be 11 months out of date?

 

Jamie

 

---

Can any Mod's/Admins answer this for me please ?



In the temp fix suggested by Webroot Support above, as the updates are turned off is this just software updates? So are we still protected against new strains of virus/spyware etc to the same level as if we were running the latest version of Webroot or will the protection be 11 months out of date?

---

Well the database that the agent talks to still updates, so that won't be an issue. And we hope to have a full fix for this in an update soon so once that happens then you can continue to update the agent again.

---

Ok Thanks, please keep this thread updated with any news of a fix/update release date.

---

Is a daily (or weekly) RD Server reboot sufficient to aleviate this issue, pending the engine fix?

---

We scheduled in regular reboots, and it had no impact.

 

In fact the issue would happen more than once a week on some servers, so a weekly reboot wasn't frequent enough in our case.

 

In once instance, we rebooted a server after a problem for it to reoccurr about 3 hours later.

---

Thank you for posting. So in your opinion is Webroot usable in any server workloads? I already found that it destroys SYSVOL replication for domain controllers.

---

Not at all. We have Webroot running quite happily on a large number of servers.

 

This issue was with our Terminal Server farm, which has been mitigated by different policy settings.

 

On all of our other servers, we are pretty much using the Webroot created Server Defaults.

---

?, can you please share your modified policy settings that you used in order to stop this from occuring?

---