I created a public DNS record for and pointed that to the public IP of the Azure Load Balancer. To test the HTML5 web client, open a browser (currently Edge, IE 11, Google Chrome browsers are all officially supported) and browse to For example, in my case I tested an Azure IaaS setup with 2 RD Web Access servers behind an Azure Load balancer. Make sure you export the certificate using the security principal option as shown below. Note, in the beta release the Import-RDWebClientBrokerCert currently does not accept password protected pfx files. Publish-RDWebClientPackage -Production -LatestĮasy as that! HTML5 support is now added to the RD Web Access role! Then run the following commands in the PowerShell Admin console. Optionally export it first, and make sure to include the private key. Next, we copy the certificate used by the RD Web Access role. Import-Module ($Env:ProgramFiles + “\rd-html5-manage\RDWebClientManagement”) We open an Administrative PowerShell console and run the following commands: Based on the current beta, here’s an example of what these cmdlets might look. Mobile devices are not supported.īy the time the client releases, new PowerShell CmdLets will be available to deploy, manage and configure the client.
The client performance will however be better when connecting to Windows Server 2016 or Windows 10 Anniversary Edition or later. The endpoints (RDSH or Windows Client SKUs) can be running any Windows Operating System starting from Windows 7 SP1 / Windows Server 2008 R2.
Since a few years, Microsoft also has a Remote Desktop client for other platforms like iOS, Mac OS X and Android, available for download from the App Store, the Mac App Store, and the Google Play Store.Īs a next step, Microsoft now also has a web client based on HTML5 (currently into preview), called the RD Web Client. Everyone will be familiar with the Remote Desktop client called MSTSC. This entry was posted in Microsoft, Remote Desktop Gateway, Windows 2019, Windows Server.
When we removed this line from our template the problem went away. In an attempt to make it easier for clients to connect by auto-populating our domain name into the shortcut.
We cracked open the RDP file (it’s just text) to find what the difference was: On a whim one of our Techs still had a copy of our original RDP template we used for initial testing where everything worked and found that it still worked on Mac OS 10.15.6 with Microsoft RDP 1.14.0.
We also found that the latest Microsoft RDP Client, 1.14.0, worked fine on Mac OS 10.14.1 but the same was not true for Mac OS 10.15.6. We found that rolling back the Microsoft RDP Client to 1.13.8 (the latest 1.13.x build) would solve the problem. The registry entries it mentioned did not exist on our servers. I originally came cross this Technet thread when researching the issue: If this keeps happening, contact your network administrator for assistance. This might be due to an expired password. and only some Mac users.Ĭlients using Mac OS 10.15.x and Microsoft RDP 1.14.x were greeted with this error message: Right before go-live day we updated our RDP template we provide to clients and that’s when things started going wrong for only Mac users…. For Mac OS we had clients download the official Microsoft RDP App from the App Store. Initial testing worked great for Mac OS, Windows and Linux users. Over the summer we build a Remote Desktop Gateway Cluster to provide remote access to workstations for some of our clients.