A client reported an issue that when some one RDP into their Windows 2012 server (which is also a domain controller) s/he get a black screen, The same black screen exist even if some one logs into console session, however apart from this all the services on the server functions just fine.  The only thing they can do to resolve the issue is to reboot the server.

We researched on the issue and found that a lot of people are facing same or similar issues on server 2008 R2 and Windows 2012, We did implement some possible solutions on the server but as of now I am not Cent Percent sure if the issue is resolved as it happens rarely.

Solution 1:

We have observed that when a user gets black screen s/he, usually it has a disconnected session which is not getting reinitialize, so as a solution we implemented an idle session timeout limit on the server, so that after a specific time (18 hrs in our case), any disconnected session will be logged off immediately. The settings can be implemented in session state if the server is configured as a Terminal server or session host server.  it can also be configured by manually editing registry, we although configured it using local Group policy on the server.

Session timeout connection Group policy settings

Session timeout connection Group policy settings

Solution 2:

Some people have claimed to resolve this issue by configuring following group policy setting to enable both TCP and UDP protocols, if you do so, ensure that you make required changes in your network router or Firewall.

Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections

Solution 3:

If you are RDPing into the server from Internet and  you get this black screen issue, than try to RDP into the server from local Lan, some people have found the issue only happens from internet. If that is the case than an easier workaround would be to connect to VPN and then access the server on local IP

Solution 4:

This solution is also published by MS as a fast publish article here, this one talks about Authenticated Users and Interactive logon not having enough rights on the server, here is the solution

Method 1:

Add the “Authenticated Users” and “Interactive Logon” to the local “Users” group and reboot. If the machine is a DC, do the same in the builtin\users Group
Click Start, Run, type lusrmgr.msc then ENTER.
Select Groups in the left pane.
Double-click Users in the right pane.
Click Add, and then click Locations. Scroll to the top of the Locations dialog and select the local computer name, then click OK.
In the Enter the object names to select field, type Interactive; Authenticated Users (separated by a semi-colon). Then click OK.
Restart the computer.

Method 2 :

Run the following commands from a command prompt:

Net localgroup Users Interactive /add
Net localgroup Users “Authenticated Users” /add

Solution 5:

Some people have observed that this issue happen if “On resume display logon screen” is enabled on-screen server settings of the server, so one can try disabling the same under

Control Panel->Display->ScreenSaver settings

Solution 6:

In case of Windows 2008 R2, this issue is known to be caused by a specific Microsoft update KB 2830477, you can try un-installing it from your server if it’s there.

Solution 7:

I wouldn’t really bet on this one but like we used to disable UAC on Windows 2008R2 server to reduced unexpected issues, I will suggest to disable Network Level Authentication on Windows Server 2012/R2 as its known to cause a lot of RDP issue. Please refer out other article, here, for the steps to disable NLA.

Apart from the above steps which we took on the server to prevent the issue, I did find a lot of work around which people found to get around the issue if you actually see it happening that you do not want to fiddle with server.

Workaround 1:

Changing color depth to 24bit (or less) in rdp file solves the problem, but this is a partial (unwanted) solution.

RDP properties Chaging Color Depth

RDP properties Chaging Color Depth

WorkAround 2:

Disable BitMap Caching in your RDP client (on the EXPERIENCE tab). This solution is also explained in MS fast publish article here

RDP properties: Disable Bitmap Caching

RDP properties Disable Bitmap Caching

PS : The same can also be disabled by editing RDP config file and adding or editing  bitmapcachepersistenable:i:0

 WorkAround 3:

Edit RDP config file and by adding or editing  enablecredsspsupport:i:0

WorkAround 4:

Instead of using standard remote desktop console, try opening it in admin mode. Start->Run->Mstsc /admin

WorkAround 5:

This one has got really positive reviews by alot of users

Click on the black RDP windows (to select it) and press CTRL-ALT-END to bring up the Windows Security screen and select LOG OFF, then log back in. If this fixes the issue than it can be because of Idle connections, in which case set session time out limits as explained above in Solution 1.

Or

Click on the black RDP windows (to select it) and press CTRL-ALT-END to bring up the Windows Security screen, Then I hit cancel, then I closed RDP.  Then I re-opened RDP and I had my desktop back.

Above I have tried to explain a variety of solutions and workaround I found for this issue, please try them and do update us in comments about the one which helped you. Also feel free to report any new issue where you seek expert help on fourm.

Update:  Though I request you to strictly follow the above logical steps for this issue, however I found another very specific reason for this problem and have written an article about it here, please do check it out if these steps do not resolve your issue.

The following two tabs change content below.
An automobile enthusiast at heart and computer geek by profession, started my Career with MS in 2005.Left Jobs and started Pledge Technologies (the parent company to Grishbi) back in 2009.We have been providing IT consulting to various Small and Medium businesses across US and UK since then.Our company specialises in Microsoft Server technologies like AD, Exchange, the rest and with numerous Office 365 migrations under our belt, we quite an expert with that too. Whatever we learn in our day to day life, we share it back on Grishbi as a Thank for all the love and support our customers have given us.
%d bloggers like this: