There is 35 different disconnect reason codes that have a good explaination of why one get disconnected from a RDP session. tl-run-rdesktop handles 7 of them and reports back via dialog to end user the specific reason for the disconnect. However, if not handled, a generic disconnect message and the code (number) is presented, which is a bit simple. There is definitely more codes that would be valued if presented as text instead of a number, such as code 5: "The connection to the session was replaced by another client".
https://social.technet.microsoft.com/wiki/contents/articles/37870.rds-remote-desktop-client-disconnect-codes-and-reasons.aspx
The initial description is a bit wrong. The 7 codes that are handled by tl-run-rdesktop are cases where we decided to not show any error at all. Unfortunately, code comments explaining this was removed in r28403 for bug 4352. However, there is still a point in that there are some return codes that could be presented to the user instead of either ignoring them (as explained above) or being handled by the generic message that displays the exit code number.
Official documentation for the codes from the RDP server: https://msdn.microsoft.com/en-us/library/cc240544.aspx
Should be improved now. Testing should most importantly verify that we are not getting any error messages when the user disconnects or logs out himself. Other normal disconnection cases should also be verified. Needs to be tested against at least Windows Server 2008 R2 and Windows Server 2012. I have tested 2016 quite extensively.
Some of the messages were modified to be more end user friendly after internal feedback. A few new specific messages were added as well.
I did not manage to trigger all return codes from rdesktop. For example the out_of_memory one got interesting; I found a tool made by microsoft that was made for testing low-memory conditions. When I finally reached a point where my VMWare machine didn't allow me to create a remote session I got a protocol error from rdesktop instead. However, it's not crucial to trigger all of the cases for testing here since they all use the same mechanism. The most important parts are that we catch and help out in the most common cases and doesn't display a confusing message.
Verified message for "logged in from elsewhere" using tlclient second session, verified messages for disconnect & log off (and send message and shadow) from local Server Manager, all ok. Would suggest changing message for log-off to "An administrator logged you out from you remote desktop session."
The tests mentioned in Comment #11 was carried out on 2012 R2. Note that testing for Windows server 2008 R2 remains.
Ran the same tests on 2008 (the demo system) with all three messages showing up ok.
There seems to be an issue for some sessions that were redirected by the broker. In such a session, when the administrator uses the Server Manager to log the user out, no message was displayed to the user, and the log said that the user himself disconnected. The reason sent by the server was: ERRINFO_RPC_INITIATED_DISCONNECT_BYUSER 0x0000000B Which is the same reason the server sends as when the user disconnects himself. In a session which wasn't redirected by the broker, the same procedure results in the correct behavior by tl-run-rdesktop (a message dialogue and the correct log message).
Our initial plan was to try to reproduce this behavior with Microsoft's client, but we hit some roadblocks. The fact is that we have verified that the RDS server sends the same reason code for these two actions (normal user disconnect and admin log out after broker redirect). It is difficult to handle this perfectly: * Normal user disconnect is very common and should not show any message to the user. * An administrator logging the user out after the connection has been redirected by the broker should be less common but should ideally show a message to the user since it could be unexpected. However, we have decided to not care about this behavior. It is likely a bug in Microsoft's RDS server. Notes about what happened when trying to reproduce with mstc: We were not able to successfully connect using mstc when the broker wanted to redirect the connection to another server due to issues with how our connection broker is setup. Microsoft's client expects the user to connect using a DNS-name that corresponds to the RDS collection, and not directly to one of the hosts. rdesktop doesn't care about this.
