Aug 03 2020 07:13 AM
Aug 03 2020 07:13 AM
Windows 10 Pro Laptop, Version 1909, OS build 1863.959 attempting to connect via RDP to Windows Server 2019 Standard (Hyper-V VM), Version 1809, OS build 17763.1282.
Observations: 1) Remote connection is allowed. 2) Remote session, once connected, will freeze almost immediately and becomes unresponsive to ALL input (mouse, keyboard, etc.). 3) Remote session must be disconnected forcibly. 4) Connection attempts to the PHYSICAL server, also running Windows Server 2019, works fine. 5) Likely unrelated but worth noting, the 2019 server hosting the RDS session host deployment has started randomly stopping the Remote Desktop Connection Broker service which has to be manually restarted. I am supporting a 100% remote workforce due to COVID-19 and this has to work! Any help appreciated.
Nov 03 2020 02:57 AM - edited Nov 03 2020 03:00 AM
We are experiencing similar issues.
Host must be 2019 1809 (fully patched), Guest must be 2019 1809 (fully patched). RDP connection from the same network segment is OK.
If we come from another network (across WAN or VPN), then RDP sticks at "Securing Remote Connection".
Interestingly, on the guest, if logged in locally on the console, you will be locked out when RDP commences. (i.e. RDP session is starting).
If we use an invalid user, or user without permission, we get the expected error. (so authentication and permission evaluation is working).
If we run a 2016 guest on the same host, it's fine.
If we move the 2019 guest to a 2016 host in the same VLAN and physical switch, it's fine.
Wireshark shows the bidirectional conversation happening, but no clue to why it's failing.
Nothing in event log either side. We've turned off Windows firewall for testing.
Other network services are fine, for example, SMB. So file shares on the guest are fine. It's specifically RDP, on a 2019 guest, on a 2019 host, when coming from a different network.
We've escalated to Microsoft using up some Software Assurance benefits. Never had to do this before, but it's got us flummoxed. We've had our best networking consultant on it, and he has no idea either. It does seem to be Windows itself with the issue, as we've proven the fundamental networking is OK.
My gut feel, is it's a software bug in the VSwitch. So a fix may be far away.