RDS Problem reconnecting to a session

Question

Hello,

I am having a problem on my RDS farm (Windows Server 2019) :

After a session is locked, manually by the user or automatically by GPO, when the user tries to reconnect and enters their password, his session does not open and the screen freezes. There is the usual login page, with the logo and the name of the user, but there is no loading circle with the message "Welcome". See the screenshot below.

The problem is encountered by a large number of users with no correlation between their hardware, whether through connections with thin clients or hard clients. The problem appears every day but not at set times.

The RDS farm was installed recently and this problem appeared quite soon after the farm was put into production.
The problem appears on both the RemoteDesktop collection and the RemoteApp collection.

The scenario of the problem :

On the Broker, before the user tries to reconnect, the session appears in Disconnected status.
When the user tries to reconnect and the screen freezes, the session appears in Active status.

From the Broker server, a right click -> Disconnect on the user has no effect.
To unblock the user, the "Windows Logon User Interface Host" process (LogonUI.exe) for the session concerned must be terminated manually. Then, the session is unblocked and the connection to the session works perfectly. The user reconnects to his session and retrieve the documents and applications he had opened, and he reconnects to the same session server.

In the event viewer on the session server, the following errors appear when the user tries to reconnect and screen freeze :

Disconnect trace: CUMRDPConnection Disconnect trace: 'calling spGfxPlugin-> PreDisconnect ()' in CUMRDPConnection :: PreDisconnect at 4595 err = [0x80004004], Error code: 0x80004004

The network characteristics detection function has been disabled due to Reason Code: 2 (Server Configuration).

'Failed GetConnectionProperty' in CUMRDPConnection :: QueryProperty at 2884 err = [0x80004001]

The network characteristics detection function has been disabled due to Reason Code: 1 (Client not supported) ..

'Failed CreateVirtualChannel call on this Connections Stack' in CUMRDPConnection :: CreateVirtualChannel at 2498 err = [0xffffffff]

RDP_SEC: An error occurred while transitioning from FStatePassthrough in response to FEventCheckAndCompleteReadsFailed (error code 0x8007139F).

I have taken the following actions but it still does not work :

-Added registry keys on all session servers:

-HKLM \ SYSTEM \ CurrentControlSet \ Control \ Terminal Server \ SysProcs : csrss.exe = 0
-HKLM \ SYSTEM \ CurrentControlSet \ Control \ Terminal Server \ SysProcs : winlogon.exe = 0
-HKLM \ SYSTEM \ CurrentControlSet \ Control \ Terminal Server \ WinStations : fEnableRemoteFXAdvancedRemoteApp = 0
-HKLM \ SOFTWARE \ Microsoft \ Terminal Server Client : UseURCP = 0
-HKLM \ SOFTWARE \ Policies \ Microsoft \ Windows NT \ Terminal Services : VisualExperiencePolicy = 2

-Farm servers, computers updated with the latest Windows KB.

Thank you in advance for your help.

Answer 1

I think I've come up with a work-around. Disable the NTLM requirement and you should get past the black screen. If you get stuttering on your RD sessions, disable UDP for Remote Desktop. This will cause file transfers and other things to go very slow but did fix my stuttering.

EDIT

Ignore it all. Issue persists.

Answer 2

Any updates on this?
We are experiencing the same problem unfortunately..

Answer 3

Now I do have some positive stuff from our end. We have constantly been trying to RDP to the server using a CNAME (server-A-alias), in which every now and then we get the hung session. If another admin looks up that session and kills logonui.exe in that session, then the reconnection works.
When connecting to the server's A record, it's short name server-A, it seems to work flawlessly.

Does the above information correlate to others experiencing the issue?

Answer 4

Anybody using N-Able RMM? If yes this might be the cause.

Answer 5

Our solution to the issue was to remove/uninstall NetId, which according to MS had hooks into the logonui.exe process and sometimes caused it to stall.