We run an RDS farm with more than 15 session hosts. Four heavily used servers belong to our office collection, and they now frequently give users—and even administrators—a completely black screen when connecting through RDP. Nothing can be clicked or typed, and the host only becomes usable again after a reboot. This is happening more than ten times per day, while the less-used collections do not seem to be affected.
The hosts are virtual machines running on a local Proxmox cluster. They originally ran Windows Server 2019 and were upgraded to Server 2022 while troubleshooting, but the issue remained. I have also updated the NVIDIA drivers. User profiles are stored with UPD, not FSLogix, and licensing is valid. Capacity should not be the problem because each host can handle the full company user load.
I have tried several common fixes without success. What logs, services, policies, or RDS components should I investigate to identify the cause?
4 Answers
Check the User Access Logging Service on the affected hosts. If it is failing to start or its logging database is damaged, user profiles may not load correctly and RDP sessions can appear stuck. Temporarily disabling the service may help confirm whether it is involved; a longer-term fix may require rebuilding its database.
Since the issue is concentrated on the busiest hosts, compare their session counts, disconnected sessions, profile disks, and resource usage with the healthy servers while the problem is occurring. Even if the VMs have enough CPU and memory overall, a stuck session, profile mount, storage delay, or host-side virtualization problem could prevent new logons. UPD storage should be investigated directly rather than assuming it is unrelated.
Make sure the latest applicable Windows cumulative and out-of-band updates are installed manually where required. Some RDS fixes are not always delivered through the normal update path. This may not match the timeline of the problem, but it is still useful to verify before focusing entirely on drivers or licensing.
Review the session-management policy and the RDS event logs. The policy that restricts users to one Remote Desktop Services session is worth verifying, since abandoned or broken sessions can cause trouble. Also check the relevant Terminal Services, User Profile Service, and Remote Desktop licensing logs immediately after reproducing the problem. If the logs are being cleared or only retain current-day entries, check the event-log retention and forwarding configuration.
The issue started well before the update associated with that fix, so it may not apply here, but I will verify the installed update levels and rule it out.