Fixing the issue of Remote Desktop Gateway server not being reachable from a Windows 10 device

One of my customers recently reported an issue where RDS was not reachable from an AAD joined Windows 10 device. They were trying to connect remotely and reported the following error.

The devices are enrolled in Intune and users are setup as Standard accounts. So what does the error mean?

Based on my research, the error indicates that the RDP connection failed to establish using HTTP with UDP. RD Gateway role is used for securing connectivity to Remote Desktop Services via the Internet.  RD Gateway uses the following 3 transport protocols -

1. RPC over HTTP – used with RDP 7.1 and previous clients, or when connecting to a Windows 2008 R2 RD Gateway.

2. HTTP – RDP 8.0 clients always use HTTP as the default transport, falling back to RPC over HTTP if the HTTP transport is not available. The HTTP transport uses the Secure Sockets Layer to establish secure connections between the remote desktop client and the remote desktop server through RD Gateway. This transport type became available starting with Windows 2012.

3. UDP – Requires the RDP 8.0 or newer client and a RD 2012 or newer Gateway.

What are the possible ways to fix this?

There are currently 2 ways that you can fix this -

1. Server Registry - Set the EnforceChannelBinding registry value to 0 (zero) to ignore missing channel bindings on the Gateway server. Following registry is not present by default and needs to be created on the server side.

HKLM\Software\Microsoft\Windows NT\CurrentVersion\TerminalServerGateway\Config\Core

Type: REG_DWORD

Name: EnforceChannelBinding

Value: 0 (Decimal)

2. Client Registry - Set the RDGClientTransport registry value to 1 to hardcode the use of RPC-HTTP. Here is the path to the registry.

HKCU:\Software\Microsoft\Terminal Server Client

Type: REG_DWORD

Name: RDGClientTransport

Value: 1 (Decimal)

Note: DWORD 0x00000000 or Not Present translates to negotiating NLA using TLS. If both Client and Server are not up to date on security related to RDS and TLS, and NLA security is not properly configured, the connection will most likely fail.

Due to some challenges in getting the registry tweaked on the server side, I had to implement the client side registry as in my case the devices in question were being provisioned using Autopilot and it was easy enough for me to implement the registry script (covered below) along with rest of the Autopilot configuration.

How to fix this using Intune?

There are multiple ways to roll out the registry, but if you are managing your devices using Intune, then you can easily setup a Windows PS script and deploy it in user context. Here you can do this -

I put together a simple PS script that will create the registry in HKCU hive of the end user's device.

If ($(Test-Path -Path "HKCU:\Software\Microsoft\Terminal Server Client") -eq $False) { New-Item "HKCU:\Software\Microsoft\Terminal Server Client" }

New-ItemProperty "HKCU:\Software\Microsoft\Terminal Server Client" -Name "RDGClientTransport" -Value 1 -PropertyType "DWord" -Force

Save the above script and import in Intune.

1. Sign-in to the Microsoft Endpoint Manager admin center portal. 

2. Browse to Devices – Windows – PowerShell Scripts

3. Click on Add

4. Give a Name

5. Select the script

6. Set Run this script using the logged on credentials as Yes

7. Set Enforce script signature check to No

8. Set Run script in 64 bit PowerShell Host as Yes

9. Deploy to a user based group.

Once the device checks in with Intune, the script should execute. You can always restart the Intune Management Extension service on the devices or reboot them to speed things up. On successful execution, the registry will get created and the RDP to the RDS over internet should work again.

Conclusion

A registry fix like the one above, can break or fix things. While the Decimal value of 1 for RDGClientTransport can get you past the RDS not reachable error by establishing an RDP security based connection, you are in fact bypassing the default RPC-HTTP mode for connections. There have been instances reported over the internet that RDG connections have failed with incorrect user name and passwords. A Decimal value of 0 against RDGClientTransport has been found to fix things. I haven't experienced this particular issue myself, so can't comment on it further, but please be mindful of these settings before implementing them.