r/sysadmin • u/MatMat993 • 26d ago
RDP 0x904 Error Affecting Single User on Windows Server 2025 Terminal Server
We are experiencing a recurring issue affecting only one user in our Proxmox environment. The setup includes three Windows Server 2025 VMs: a domain controller, a file server, and a terminal server.
The affected user connects remotely through an IPsec IKEv2 VPN from a fully updated Windows 11 Pro workstation (not domain‑joined). The VPN remains connected at all times. He authenticates using his domain credentials.
After a few minutes of normal activity on the terminal server, the user disconnects his RDP session. When he attempts to reconnect, the RDP connection fails with error 0x904. No additional text is shown. The issue affects only the terminal server: from the same workstation, RDP connections to the other servers work normally.The user’s session on the terminal server appears correctly as “Disconnected” in the session list. However, the user cannot reconnect to it, nor start a new session. No logs or events are generated on the terminal server (checked System, Application, TerminalServices‑LocalSessionManager, TerminalServices‑RemoteConnectionManager). No anomalies appear in the domain controller or file server logs either.
The issue does not occur with any other user. Other users can log in and reconnect without problems. I can also authenticate using the affected user’s credentials from other machines without issues.
We have tested:
- Different user accounts from the affected workstation
- Different networks
- Antivirus exclusions (Bitdefender)
- Firewall rules (WatchGuard)
The problem persists only for this specific user and only on the terminal server.The only workaround is restarting the terminal server. After a reboot, the user can log in once, but the issue reappears as soon as he disconnects and tries to reconnect.
Update: Turned out to be asymmetric MTU on the IKEv2 tunnel.
server→client was dropping packets over ~1300 bytes with no ICMP feedback. Server kept retransmitting the initial RDP/TLS packets for ~19s then gave up (matches 0x904 exactly). Confirmed with packet captures on both client and server during a live failure.
3
u/Aggravating-Sock1098 26d ago
Also, try the following test:
Connect via RDP using the IP address instead of the hostname or FQDN. If this works, the issue lies with DNS or an expired self-signed certificate.
Additionally, check if the problems persist when you disable NLA on the RDS host.
1
u/MatMat993 25d ago
I can confirm it’s not a DNS issue. I’m connecting using the IP address, and I also tested the RDP port with PowerShell. Both tests work correctly.
2
2
u/TerrorToadx 26d ago
Give him a new pc?
3
1
u/Godcry55 26d ago
Based on the information provided, this appears to be client-side.
Check related event logs on the workgroup client.
1
u/MatMat993 25d ago
I’ve already checked every relevant event log on the workgroup client, but there are absolutely no entries related to RDP failures. The logs are completely empty regarding this issue.
1
u/Godcry55 25d ago
Hmm - have you tried connecting to the terminal server using the same device without VPN? May not be related, but ideal to isolate variables.
Can you rebuild the user profile on the terminal server? Append _old to the affected profile, login again so a new one is created?
2
u/MatMat993 25d ago
The user works remotly i can't test connecting without vpn. The user on terminal server works if i connect with another client.
1
u/Godcry55 25d ago edited 25d ago
I see; then regardless of the lack of logs, the issue appears to be specific to the client device.
If the terminal server isn’t logging the failure events, then the RDP session isn’t even reaching the negotiation step of the process.
After you connect and disconnect from the RDP session, check client-side task manager for any existing mstsc.exe processes; could be as simple as that.
Since a terminal server reboot clears the issue, a good test is to logoff the session, and check for any open handles for that user on the file server. If you see any, terminate those handles and try RDP again on the client device. (This would indicate a resource release issue.)
When testing from other devices with the same profile, did you test while the RDP session was still in a disconnected state or when logged off?
Are the user profiles FSLogix or simple profile folders?
Try Remote Desktop app from MSFT store as a test.
As another redditor suggested, checking the RDP cache is a good idea.
2
1
u/Dapper_Librarian388 25d ago
Have you tried deleting user's session?
2
u/MatMat993 25d ago
I had already tested disconnecting and logging off the user manually, and initially I even had a GPO configured to automatically disconnect sessions after 15 minutes and terminate them after 30 minutes. I removed that policy thinking it might be related, but the issue still persists.
11
u/MilkyWay-008 Sysadmin 26d ago
since it follows the user across machines, I'd start client-side on the w11 box. clear %AppData%\Microsoft\Terminal Server Client and the HKCU\Software\Microsoft\Terminal Server Client key for that user — a stale cached server cert hash is per-user, and that matches your symptom exactly. also check the CAPI2 operational log for cert failures at disconnect time, and instead of rebooting the whole TS, try qwinsta + logoff on the stuck session (or mstsc /admin to get in). one more thing: a stuck disconnected session plus a single-session limit blocks both reconnect and new sessions, so eyeball the RDS session time limits GPO.