One of our clients recently started to experience the dreaded RDP Black Screen issue on their Win 2016 servers. I had read about this problem, but never witnessed it first hand. The only thing that managed to get the servers operational again was a reboot. Not good in commercial environment.
After much research, I thought I'd consolidate all my findings in this post in the hope it saves you, the reader, the same pain.
These servers were running as Virtual Machines in an Esxi 6 U2 environment and all users are using UPDs (User Profile Disks).
There are reports that restarting the Audio Service on the server rectifies the problem, but it didn't work in our case. I thought I'd document that so you have the info here:
Open an admin command prompt and type the following
net stop Audiosrv
taskkill /F /IM AudioDG.exe
net start Audiosrv
These are the changes that were made to the RDP servers that seems to have stabilised them:
- Ensure TCP Offloading is disabled on the server NICs. This is recommended even if you're not experiencing this issue. This is for Virtual Machines only. Do not do this if the OS is installed on a physical machine.
- Ensure none of the users UPDs are full. Apparently this can cause this Black Screening for all other users of the RDP servers. You can expand their disks by following this tutorial here...
- This was not the case in our issue, but apparently if you have removed the Account "NT AUTHORITY\INTERACTIVE" from the Users group on the machine, this can cause this problem. You can read more about that here...
- Duplicate firewall rules created within the registry when users log on every day. This can lead to 10s of thousands of records created needlessly causing a slow log on experience for your users. To clear them out I've created a Schedule Task that runs a midnight each day on each RDP Server that runs a batch file with the following registry edit syntax: reg delete "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System" /va /f
This has seems to have stabilised the servers in the interim and I will update this post should any further information become available or include additional remediation techniques.