I'm trying to use Remote Desktop to log onto a Dynamics 365 AOS server hosted in Azure, using the RDP file and credentials displayed on the environment's LCS page.

The Dynamics 365 AOS server is a Windows Server 2016 Datacenter Edition box.

When accessing it via a Windows Server 2012 R2 server (i.e. RDPing onto the server, then downloading the DFO365 RDP file from LCS onto that machine and running the RDP client on the "proxy" server) all works, but attempting to access directly from my Windows 7 SP1 machine fails. A colleague, also running Windows 7 SP1, has exactly the same issue.

My public IP (i.e. as seen by visiting WhatsMyIp) is whitelisted for RDP (via the LCS Maintain > Enable Access).

Both myself and my colleague had been able to RDP on to this VM until mid last week.

By going via the "proxy" server I was able to view the event logs on the remote Dynamics 365 AOS server. Looking at the Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational event log I could see my connection attempts hitting this server, as there were warning messages stating: The server security layer detected an error (0x80090304) in the protocol stream and the client (Client IP:123.45.67.89) has been disconnected. (where 123.45.67.89 matches my public IP address). There are several other information events either side of the warning:

• info The server accepted a new TCP connection from client 123.45.67.89:58177.
• info Connection RDP-Tcp#4 created
• info Interface method called: PrepareForAccept
• info Interface method called: SendPolicyData
• info PerfCounter session started with instance ID 4
• warn The server security layer detected an error (0x80090304) in the protocol stream and the client (Client IP:123.45.67.89) has been disconnected.
• info Interface method called: OnDisconnected
• info The server has terminated main RDP connection with the client.
• info During this connection, server has not sent data or graphics update for 0 seconds (Idle1: 0, Idle2: 0).
• info Channel rdpinpt has been closed between the server and the client on transport tunnel: 0.
• info Channel rdpcmd has been closed between the server and the client on transport tunnel: 0.
• info Channel rdplic has been closed between the server and the client on transport tunnel: 0.
• info The disconnect reason is 14

These events repeat 3 times, implying that MSTSC makes 3 connection attempts before reporting the failure.

Looking around the web I've seen mention of some certificate and key issues. I noticed that there are 120,078 files under C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, including one beginning f686aace6942fb7f7ceb231212eef4a4_ (TSSecKeySet1). I haven't tried removing or amending any of these though, as don't know what the impact would be / haven't seen any explanation of why such fixes should work. My gut is that the sheer volume of files in that directory may be related to the issue.

Question

Does anyone know what may be blocking these connection attempts / what's required to allow the connections through?

Updated 2018-04-30: the solution which worked for Dev/Build environments does not work for Sandbox environments.

For Sandbox (Tier 2) environments

TL;DR

Upgrade client RDP protocol to include DTLS and RDP 8.0 (potentially only the first part is required; not tested).

Detail

• Check your RDP Protocol Version
  • Hold down the Windows key and press R to bring up the run prompt
  • Type MSTSC then click OK
  • Right click in the title bar & select About
  • The bottom line of text will read Remote Desktop Protocol #.# supported. If this is less than 8.0 you'll need to upgrade (for me it was 6.1)
• Upgrade RDP
  • Download and install DTLS (KB2574819). More info on this dependency is listed on Wikipedia(!)
  • Download and install RDP 8.0 (KB2592687)
  • Restart your computer when prompted
• You should now be able to successfully RDP onto the remote server.

NB: RDP 8.1 is available too (KB2923545); however this is not required / for me would not install (presumably there are additional undocumented prerequisites).

For DEV / Build (Tier 1) environments, this solution works:

TL;DR

Redeploy the environment.

Detail

As of Platform Update 12 MS no longer supports the use of the admin account. This is outlined here: https://blogs.msdn.microsoft.com/lcs/2017/10/31/restricted-admin-access-with-platform-12-updates/

Instead we needed to use the standard user account; however this did not exist on our instances. To get this account we ad to redeploy the environment, following the steps here: https://community.dynamics.com/enterprise/b/dynamicsaxand365/archive/2017/04/30/tips-and-tricks-to-successfully-set-up-your-dynamics-365-for-operations-platform-part-5-environments-set-up (NB: It can take up to 48 hours for a deployment to complete; not 12 hours as stated in the post/comments).

Once the environment was redeployed we had the correct accounts in place, and could successfully RDP onto the environment using the User### rather than Admin### RDP account (listed under the Local Users rather than Local Administrators section.

It's unclear why we'd been able to access from the "proxy" server but not from our local machines given this cause... My best guess is that the server in our data center somehow benefitted from having the same external IP address as other devices in the same LAN which may have already had open connections; and thus were not blocked... but that's pure conjecture.

Thanks to Microsoft Support for pointing us to the cause / solution.