Exchange 2013 and Server 2012 Remote Desktop Gateway Coexistence Issues
We’ve just setup a Windows Server 2012 with Exchange 2013 and Remote Desktop Session Host services and ran in to an issue where XP clients (or machines without RDP 8 Update) can’t remote desktop in to the server with the following:
“An error occurred while sending data to the Remote Desktop Gateway server. The server is temporarily unavailable or a network connection is down. Try again later, or contact your network administrator for assistance.”
We tested a Windows 7 computer and it worked fine, so we tested another Windows XP and ran in to the same issue, we researched a fair amount and came across a couple of promising articles, so we made sure the XP client had the latest Remote Desktop Connection:
http://support.microsoft.com/kb/969084
Then we made sure it support NLA:
http://support.microsoft.com/kb/951608
So that when you click About on the Remote Desktop Connection client it looked like:
However we were still getting the same issue, I compared this to another Windows Server 2012 Remote Desktop Session Host server setup and the settings looked right, but this server didn’t have Exchange 2013 installed.
When I dug deeper I realised I was running in to the same problem as
Exchange 2013 moves the RpcWithCert application to the ‘Exchange Back End’ site which doesn’t have the 443 binding:
As reference in the previous article this affects XP as it relies on RPC over HTTP as per the table in:
Windows 7 with the RDP 8 update can use HTTP and will happily work with this setup, even though Remote Desktop Gateway moans about the certificate, but because XP uses RPC over HTTP it wont work, ever.
We got around this by moving the Remote Desktop Gateway role to the Remote Desktop Session Host server, creating a new DNS record pointing to a secondary WAN IP address and adding this record to the SAN certificate. Not everyone will have the luxury of secondary WAN IP addresses, in that case you’d have to start splitting your Exchange roles up which will increase cost, so I’d plan ahead and get the secondary WAN IP.