Link to home
Start Free TrialLog in
Avatar of rgmckenz
rgmckenz

asked on

Windows Server 2016 displays black screen when connecting via Remote Desktop from a different subnet

We've been managing a mix of Windows Server 2012 R2 and 2008 R2 servers over multiple subnets via remote desktop.  We are able to login to those servers and go about our various management tasks with no issue.  We recently installed a couple new Windows Server 2016 virtual host boxs and setup RDP for those as well.  We can login just fine using a remote desktop client when we are on the same subnet, but when we try to remote in across an SSL-VPN connection or over a point-to-point VPN (any other subnet), we get a black screen after login.  No changes to our firewalls or routers and just defaults on the servers.  Happens whether local server firewall is on or off.  Can someone tell me what was changed "out of the box" for 2016 that results in black screens from remote subnets after login?  Thanks!
Avatar of Cliff Galiher
Cliff Galiher
Flag of United States of America image

Nothing has changed that could explain the behavior you are seeing. RDP still attempts to use UDP, and still falls back to TCP if UDP fails. There is a new RemoteFX codec, but again, that is negotiated.  Unofficial clients or misconfigured firewalls would be my suspicions.
Avatar of rgmckenz
rgmckenz

ASKER

Thanks for taking a look, Cliff.  Very strange indeed.  No changes in the firewalls - same remote desktop clients (Win10, Win7) - all other servers work (Win2K12, Win2K12R2, Win2K8R2) - all servers a mix of Dell PowerEdge T710's, T620's and R630's.  The servers experiencing the problem are the newest Dell PowerEdge R630.  Is it possible that some video driver/configuration is no longer able to be viewed?  I guess if that were the case, you couldn't even view the RDP session from the local subnet.  As a test, I turned off the 2016 server's local firewalls and also Windows Defender.  Same exact issue.  Anyone else have the same result I have when using remote desktop to access a 2016 server from a different subnet?
I didn't mean local firewall (but it isn't out of the realm of possibility.) But different subnets by definition means some sort of routing (even if only via layer 3 switch) and that usually has basic firewalling capabilities between the subnets. If UDP is getting mangled, it may make fallback to TCP fail.

As to your second question, yes I have this working. Most of my environments put servers in one or more subnets for more granular access control. And azure has 2016 images, which absolutely means different subnets when connecting remotely. That's a pretty big base of successful deployments in the wild not showing this behavior. This is definitely something tied to your environment. I can only point at likely causes. Wireshark might be necessary to see the traffic flow.
Yep - when I mentioned no changes in the firewalls, I was referring to our group of Cisco and SonicWALL NSA units that support our point-to-point VPN tunnels and our SSL-VPN tunnels for traveling users.  And if the RDP protocols/ports haven't changed and I can manage all of the other non-2016 servers over those very same firewall/routers, then I don't know why 2016 won't work as well.

Nice point about the Azure images - makes sense.  So, I agree with you that it is tied to our environment.  However, I'm thinking that it is something that I have misconfigured somewhere on the servers themselves - maybe some protection that doesn't like to pass or show the video from remote subnets.  Another odd thing is that it does actually login.  I can verify that after I remote in from the subnet.  It's just that the screen is black and displaying a mouse pointer and I can't see what is going on.  Like someone's pulling a shade over the desktop when I'm on a remote subnet.  I've been working with Windows remote desktop in multi-site environments ever since RDP first hit the scene, but I've never encountered this type of behavior.  I'm taking your advice and will Wireshark it to look at the flow, and will also scope the traffic and port access on the servers in question.  Be back to you with some results.
Open for a quick test? You should install win10 v1703. With 1703 we got rid of a nasty rdp bug that only happened when using win10 and server 2016 together. It wasn't a "black screen bug", but I'd still want to make sure if the problem is still there with the latest version of win10.
Thank you for the advice. I will give that a shot as well.
OK - the plot thickens.  I always find that I should be testing more thoroughly.  I was able to test Remote Desktop from both a Windows Server 2008 R2 box and a Windows 10 Pro (pre-1701) box that are on a remote subnet from my Windows Server 2016 servers.  I was able to see the screen from the 2008 R2 server, but not from the Windows 10 Pro laptop when remoting in.  Of course, my own laptop is pre-1701 as well, and that's the unit I've done the most testing from.

So, it looks like a typical Microsoft bug - Windows 10 build and Server 2016 not playing well together.  McKnife, looks like you might have pegged that one.  I'm upgrading to the Windows 10 Creator's Update as we speak and will update everyone after I find out if it makes a difference or not.  Thanks to all for your assistance.  Be back to you soon.
Definitely *not* a "typical" Microsoft bug. As McKnifd said, there was a big, but it did bot cause the behavior you described. And was well known. I go back to azure as a good daya point (as I don't like relying on "just" my personal experience...no matter how valid.)

You'd basically have to believe that nobody managed 2016 Azure VMs using win10 1607, and that you are the first to discover this big, sox months after 2016 came out of preview.

I await your results, but just throwing out the "typical" sleight is unwarranted and doesnt even line up with the advice McKnife himself posted.
The result, at least in my case, was that after Windows 10 Creator's Update was installed on my computer, I was able to access the desktop of all three Windows 2016 servers, both locally and across the VPN.  It's not super-speedy like the Windows Server 2008 R2 remote desktop sessions and it hesitates, but the interface is at least accessible.  I went back and tried from the non-updated Windows 10 box to the same servers across the point-to-point VPN and still couldn't get the interface.  So, there might be something with the update that corrected at least part of the issue, but I'm pretty sure there is still something wrong - there should be no hesitation.  And Cliff, I think it is more along the lines of the firewall or network configuration as you originally suggested.  I don't know what it is yet, so I will continue on with Wireshark and other network scanning tools/logs until I locate the issue.

Cliff - Per my "sleight" - I think the level of chastisement that I received in your last comment was unjustified.  We've suffered through plenty of bad experiences with Microsoft, from blown updates/patches to rushed interface development to removal of popular feature sets.  I know they are a huge corporation and have a lot of offerings, and obviously can't account for every combination of hardware, software and network environment, but sometimes the quality control is lacking.  Nevertheless, it was perhaps harsh for me to label this possibility as "typical" for the company.  I have been been a vocal supporter of Microsoft, their ideas and their products for over 30 years and appreciate their product direction (with the possible exception of their recent guerrilla marketing tactics).  I know that neither I, nor Microsoft are perfect, but there have definitely been cases in which their quality has been poor, and not always due to simple oversight or environmental issues - thus my frustration.  But I do understand your comment about the problem not occurring over a large installed base.  I also recognize my assumption that the issue was "undiscovered" bug was incorrect.  Point taken.
We use RDP over VPN and locally to 2016 - no hesitating. It could be caused by problems with the server authentication. The authentication is tried with kerberos and also (if possible) using server certificates. After connecting, click on the lock icon in the connection bar to get a report if both was successful. Example:User generated image - here, only kerberos authentication was used, Either no certificate is being used or certificate approval failed.
Thanks, McKnife.  Here's some new information and I'm sorry to say that some of the results have been inconsistent.  After my upgrade to Creator's on Windows 10, I had the desktop displayed over RDP to the Windows 2016 servers.  The hesitation was caused by an unrelated networking issue that was also affecting RDP sessions to other servers.  However, as of last night, I'm back to the eternal black screen at login.  So here's what I know for sure:

The following Remote Desktop Clients connect to any of my Windows 2016 servers with no screen issues, both over LAN and WAN:

Windows 7 Pro
Windows Server 2008
Windows Server 2008 R2

The following Remote Desktop Clients login to my Windows 2016 server properly, but display a black screen and a mouse pointer immediately after login, both over LAN and WAN:

Windows 10 Pro (any build, including Creator's)
Windows Server 2012 R2

I've verified that the RDP sessions from Windows 10 and Windows Server 2012 R2 actually login and display the Server Manager, and I'm shown as connected.  I can even click on and select options on the screen, but I can't see what I'm doing because the remote desktop display is blacked out.

I feel that I'm missing something here or that I've made some very elementary configuration error on either the 2016 server side or the client remote desktop side.  I've played with every option I can think of on both sides - display options, video, etc., but I get the same results.  I can't think of anything else that might interfere.  Any additional thoughts?  Thanks to all who have contributed so far.
Blackscreen and mousepointer are seen whenever the process userinit.exe wasn't launched alright. When in that state, please press CTRL-Shift-Escape and task manager will appear. From there, check, if explorer.exe is running. If not (as suspected), start the process explorer.exe from task manager.
OK, tried the CTRL-Shift-Escape, but nothing shows up on the screen.  Still black with a mouse pointer.  I then connected from a 2008 R2 server to see what was on the screen, and it displayed the Task Manager and the Server Manager, so at least I know keyboard and mouse are working.  However, can't even see it because of the black screen.  Some sort of privacy thing which I'm not aware of?  I'm about out of ideas.
ASKER CERTIFIED SOLUTION
Avatar of Cliff Galiher
Cliff Galiher
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks, Cliff. I'll test that out as soon as I return from another client appointment today.  Be back to you with the results.
I have no idea how this should be a firewall issue. If you see the mouse pointer and your keystrokes invoke something (you proved that ctrl-shift-esc did indeed start task manager), then the session is alive and kicking, but the graphics are not transferred apart from the mouse cursor (but that could be the overlay mouse cursor of the local system!).

So you need to do experiments with different screen resolutions in the RDP client.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Cliff, have not yet had the chance to try out your firewall recommendations yet, but when I was at another customer, I was able to test out essentially the same scenario:  Dell PowerEdge (tower) running Windows Server 2016 with a Hyper-V role installed with an RDP connection from my Windows 10 Pro (1701) laptop.  I am able to login to the Windows 2016 server just fine - no blacked-out screen, no other apparent issues.  I'll be onsite with the problem customer later this afternoon, so I'll be able to attempt the same local connection again to the servers in question.  If I get the black screen, then its almost certainly a localized problem with my 2016 servers at that site or interference from another device.

One additional test:  I connected to the site through a Sonicwall Mobile VPN client, then attempted to connect to the 2016 servers via my RD Client app on my iPhone.  It connected quickly and logged into the 2016 server desktops with no black screen.  I even tried a 2016 server that was across another point-to-point VPN connection from my SSL-VPN connection point and it worked beautifully.  Makes me think that while it might have something to do with a firewall, it only affects my Windows Server 2012 R2 and Windows 10 RDP clients.  All other clients I have tested so far connect without the black screen issue.
Those are clients where v8 turned UDP on by default. While v8 patches were released for win7/2008R2, UDP is *disabled* by default even when patched for v8. The patch includes instructions to enable UDP transport.

Note that my conclusions are based on information provided. Which, up to now, has been that it is black over VPN but works on the same subnet. If it is black on the same subnet, that is entirely new information and would obviously drastically change the symptom analysis.

Complete aside, there is no 1701.
Thanks for the input gentlemen - all good stuff!  Lots of things to try this afternoon.  McKnife, I did try multiple resolutions on the client side - from the native to full-screen - same black screen on all affected clients (Win10 and Win2K12R2).

I'll know a lot more when I get my computer onsite and attached to the LAN directly.  Then hopefully I can cut this problem down to size - eliminate some of these options.
Cliff,  I'll verify the existence or the absence of the black screen on the LAN when I get there this afternoon.  Agreed - will change things a great deal.  Different firewalls to look at.

So noted on the Windows 10 version (1701):    :-)    Actually, it's  Version:  1703   OS Build: 15063.138.   Typed that on the fly and my memory isn't what it used to be.
Cliff - Brilliant, sir.  Found the culprit that appears to have been preventing the access.  The device in question was the SonicWALL NSA 2600 at the primary location that was supporting both SSL-VPN and two of our site-to-site VPNs.  The module causing the issue was the NSA's Advanced App Control policy, which appears to have identified return UDP traffic from our remote 2016 server to my laptop as an UltraSurf encrypted proxy and discarded the packets.  The result in this case seems to have been prevention of the video display from the server in question, causing the black screen.  Still had the outbound traffic from my laptop to the server, so I could still control things on the other side, but the video never reached my RDP client.  Message noted in the firewall logs:

[b]Application Control Prevention Alert: PROXY-ACCESS Encrypted Key Exchange -- UDP Random Encryption(UltraSurf), SID: 7, AppID: 2900, CatID: 27      192.168.10.5, 3389, X1      192.168.1.165, 57521, X0      udp[/b]

For a quick check, I halted the App Control and tried my connection again.  Of course, this time I received a full-screen response from the server.  I turned App Control back on and I'm editing the policy to account for the servers and RDP traffic.  We activated the App module on the SonicWALL not long ago and both that and DPI-SSL has been effective at shutting out a couple of potential Ransomware attempts.  While we have fine-tuned the policy to meet our needs, I did not account for this type of RDP traffic and it bit me in the butt this time.  Apologies to Microsoft for casting any aspersions upon their integrity in this case.

Everything now connecting properly now - no more RDP black screens.  I wonder how in the world I was able to get a couple of 2016 desktop screens through the firewall yesterday after my 1703 update?  I'm sure we could work out that theory if I walked back the steps, but it's not worth either of our time.  Again, thank you so much for helping me track down that issue.  Lesson learned.
Great!
"I wonder how in the world I was able to get a couple of 2016 desktop screens through the firewall yesterday after my 1703 update?" - me too. That was pretty misleading... :-)
Glad I could help.
Agreed, McKnife.  Sent us both down entirely the wrong path.  If I had the time, I'd go back and trace my steps after the update to see why I could view the 2016 desktop.  It was really choppy at the time as well, but that was due to another totally unrelated issue caused by the Internet service provider at the host site.  I've been burned before on some of those firewall app policies.  Not one that I think I would have thought of though, but glad that we found a resolution.  Thanks for your assistance - appreciate the advice.