Connection Failed. The User at the computer did not respond to your connection request.
Issue: Remote users constantly receive the following error, "Connection Failed. The User at the computer did not respond to your connection request", and require system administrator intervention before they are able to access the remote workstation.
Splashtop Streamer: v 18.104.22.168
VM Instance: Win10
Host: Hyper-V 2012
Server: HP Proliant ML350 G6
How to reproduce: On a computer, connect to a remote workstation via Splashtop and then either disconnect (by closing Splashtop Viewer) while still logged into a Windows session or drop your network connection. Then immediately attempt to reconnect to the machine using the same or different domain credentials. You will be unable to access the machine and greeted with that message.
Validation: view remote machine either locally or via Hyper-V Manager. There is a popup dialog box requesting confirmation to allow the previous user to reconnect to the same system. However as this is a remote session and there is no one physically there to click the button, the session remains hung until a system admin; logs into the remote machine and disconnects the user. If the windows session hasn't been locked by the screen saver, the system admin may use Hyper-V VMC to lock the windows session. Or they may remotely log the user out via command prompt.
Our AD is configured to automatically lock any workstation after 45 minutes of in activity when the screensaver activates. (Windows lock screen, followed by a blank screen, and then the power management for the monitor being set for sleep).
However the Splashtop user confirmation box is persistent in the previous user session and prevents any new Splashtop connections to the remote. (RDP and Hyper-V connections are not impacted). Even after the screen saver kicks in and locks the windows session, another remote Splashtop user may not remotely connect until a system admin clicks the "other user" button via the Hyper-V Manager VMC.
Dropped connections appear to be the overwhelming cause for this issue, as remote user now understand the correct way to exit a remote session.
Initially I was considering that lag, drop packets, and PDV to be the primary causes of this; and the potential solution would be to modify the TCP settings for this server to treat this as LFN, however this may not be the best solution. (RTT is ~250ms to remote users in the Philippians and India).
What are other potential solutions or best practices we should be doing in order to help mitigate or completely avoid this issue?