ITschoolGuy
Instructor
I have a strange issue that just appeared out of nowhere the other day. I support a client with a Windows network that includes a DC running Server 2008 R2 and a pair of load balanced application servers, also running Server 2008 R2. Most of the users are outfitted with Wyse Win-Term thin-clients. They logon using their domain accounts but the thin-clients are configured to bring them directly to an RDP desktop from the app server cluster. This setup has existed for nearly two years now with no major problems (although it was initially installed and configured by another contractor who is no longer in the picture - so I have had to learn my way around how they have it set up).
A few days ago, certain users began getting the following error at logon: "The task you are trying to do can't be completed because Remote Desktop Services is currently busy. Please try again in a few minutes. Other users should still be able to logon." In addition, when or if those users were able to logon, they would experience the following when they finally tried to logoff: "Please Wait For The User Profile Service" - this would stay on the screen indefinitely, even if the app servers were rebooted in the interim or even if the thin-client was power cycled.
I have done a lot of Google searching and found various possibilities. The most commonly listed solution was to apply a Microsoft hotfix (KB2661332), which I did on both app servers. It didn't help.
After reading some more, I replaced the Ethernet switch to which the majority of the affected thin-clients were wired - still no good.
After that, the most promising thing I found was that the app server System Event Log might contain a "TermDD" error with ID 56 stating: "The Terminal Server security layer detected an error in the protocol stream and has disconnected the client."
Sure enough!! That exact error appears in the app server event logs whenever one of these clients experiences the aforementioned problem. The data in the error contains an HRESULT of B50000D0, which I was advised to break up into its component bytes and reverse, resulting in: D00000B5. Then I found out you have to change the D at the beginning to a C, which I did, resulting in a code of C00000B5. Searching for that yielded the following solution: Run Remote Desktop Session Host Configuration, double-click the RDP-Tcp connection, and, on the General tab, change the security layer setting from "Negotiate" to "RDP Security - which I have done.
Now, the thin-client users can connect, but when they do, the app server to which they attach tries to log them on locally instead of onto their domain user account. As a temporary workaround, I have asked the users to append the domain name and a backslash to their logon name as follows:
DOMAIN\username
This seems to work, but I am still trying to determine what caused all of this in the first place and how best to go about restoring everything to normal... especially since there are various little things cropping up now that must be related. For example, at logoff, some users get a message that their profile couldn't be fully saved properly. Other users have lost their MS Outlook settings and have had to have their Outlook email account settings re-entered.
Please, if anyone has any experience with this issue, let me know how I can go about getting it resolved once and for all. Any insight would be immensely appreciated!
A few days ago, certain users began getting the following error at logon: "The task you are trying to do can't be completed because Remote Desktop Services is currently busy. Please try again in a few minutes. Other users should still be able to logon." In addition, when or if those users were able to logon, they would experience the following when they finally tried to logoff: "Please Wait For The User Profile Service" - this would stay on the screen indefinitely, even if the app servers were rebooted in the interim or even if the thin-client was power cycled.
I have done a lot of Google searching and found various possibilities. The most commonly listed solution was to apply a Microsoft hotfix (KB2661332), which I did on both app servers. It didn't help.
After reading some more, I replaced the Ethernet switch to which the majority of the affected thin-clients were wired - still no good.
After that, the most promising thing I found was that the app server System Event Log might contain a "TermDD" error with ID 56 stating: "The Terminal Server security layer detected an error in the protocol stream and has disconnected the client."
Sure enough!! That exact error appears in the app server event logs whenever one of these clients experiences the aforementioned problem. The data in the error contains an HRESULT of B50000D0, which I was advised to break up into its component bytes and reverse, resulting in: D00000B5. Then I found out you have to change the D at the beginning to a C, which I did, resulting in a code of C00000B5. Searching for that yielded the following solution: Run Remote Desktop Session Host Configuration, double-click the RDP-Tcp connection, and, on the General tab, change the security layer setting from "Negotiate" to "RDP Security - which I have done.
Now, the thin-client users can connect, but when they do, the app server to which they attach tries to log them on locally instead of onto their domain user account. As a temporary workaround, I have asked the users to append the domain name and a backslash to their logon name as follows:
DOMAIN\username
This seems to work, but I am still trying to determine what caused all of this in the first place and how best to go about restoring everything to normal... especially since there are various little things cropping up now that must be related. For example, at logoff, some users get a message that their profile couldn't be fully saved properly. Other users have lost their MS Outlook settings and have had to have their Outlook email account settings re-entered.
Please, if anyone has any experience with this issue, let me know how I can go about getting it resolved once and for all. Any insight would be immensely appreciated!
