We run an RDS farm with more than 15 session hosts. Four heavily used servers belong to the office collection, and they have recently started showing a recurring problem: users connecting through RDP receive a completely black screen and cannot do anything. Even administrative connections fail when the issue occurs, and the only reliable recovery so far is rebooting the affected server. This now happens more than ten times per day.
The other collections do not show the problem, although they have significantly fewer users. The hosts use User Profile Disks (UPD), with no FSLogix involved. Licensing appears healthy, and the servers should have enough capacity for the workload. All hosts are virtual machines running on a local Proxmox cluster. They originally ran Windows Server 2019 and were later upgraded to Windows Server 2022, but the upgrade did not resolve the issue. Updating the NVIDIA drivers also made no difference.
The policy restricting users to a single Remote Desktop Services session is already enabled. Event Viewer has not been very useful because the relevant RDP log appears to have been cleared, leaving only current-day entries. Has anyone dealt with this kind of recurring black-screen condition, and which services, policies, logs, or updates should be checked?
4 Answers
Look at the User Access Logging Service on the affected hosts. If it fails to start or its database becomes unhealthy, user profiles may fail to load correctly. Disabling the service can be a useful diagnostic test, while a lasting fix may require repairing or recreating its logging database.
Review the Remote Desktop Services and TerminalServices event logs immediately after reproducing the problem, and preserve the logs before rebooting. Check for stuck or disconnected sessions, profile-loading failures, licensing events, and service restarts. The single-session policy is sensible, but it will not necessarily clear sessions that are already hung. Since the logs are currently incomplete, configure retention or forward them to a central collector so the evidence survives the next failure.
Since the hosts use UPD exclusively, FSLogix-specific problems are unlikely to be involved. Still, compare the affected servers with the quieter collections and look for differences in profile-disk behavior, session counts, storage latency, and disconnects. A profile or session problem that only appears under heavier usage could produce symptoms like this without showing obvious CPU or memory pressure.
There is no FSLogix deployment here, only UPD. I’ll compare the busy and unaffected collections more closely, especially profile-disk and session-related events.
Check whether the latest out-of-band updates are installed. Some RDS fixes are not delivered through the normal update cycle and may need to be applied manually. It may not explain an issue that started earlier, but it is still worth ruling out before digging further.
The single-session restriction is already enabled. Unfortunately, the RDP log only contains entries from today, so I’m going to monitor it and capture the events while the black screen is active instead of relying on the post-reboot state.