Microsoft Rdp Web Client

01-05-2021
 |  [RAND-100] - Comments



-->

The Remote Desktop web client lets users access your organization's Remote Desktop infrastructure through a compatible web browser. They'll be able to interact with remote apps or desktops like they would with a local PC no matter where they are. Once you set up your Remote Desktop web client, all your users need to get started is the URL where they can access the client, their credentials, and a supported web browser.

Important

The web client does support using Azure AD Application Proxy but does not support Web Application Proxy at all. See Using RDS with application proxy services for details.

What you'll need to set up the web client

RDP web Client Gateway (secured) access via an F5. Trying to troubleshoot a communication issue between an RDP Web Client to an RDG server via an F5.

  1. First published on CloudBlogs on Jun, 08 2009 Since the debut of RemoteApp in Windows Server 2008, Windows users have been able to enjoy remote applications with the same look and feel as local applications. RemoteApp and Desktop Connections is a new feature in Windows 7 and Windows Server 2008 R2.
  2. You can control a remote PC by using a Microsoft Remote Desktop client. The client can run on almost any device, including on your mobile smartphone. The client gives you the same powers you would have if you could reach the PC's keyboard. Through the client, you can.
  3. The main difference between this and an RDP connection manager is it allows the screen to be shared. With RDP the remote system will log off so you can’t share the screen with the end user. That’s why RDP managers are best for servers. Damware is supported on Multiple platforms and allows remote control of Windows, Linux, and Max computers.
  4. In January of this year I wrote a blog post about the Microsoft HTML5 client for Remote Desktop Services, called WebClient. This RDP Client allows you to access Publish Applications and Desktops entirely from within your browser, based on HTML5 technology. In that first article I showed the installation process and what the end result looked.

Before getting started, keep the following things in mind:

  • Make sure your Remote Desktop deployment has an RD Gateway, an RD Connection Broker, and RD Web Access running on Windows Server 2016 or 2019.
  • Make sure your deployment is configured for per-user client access licenses (CALs) instead of per-device, otherwise all licenses will be consumed.
  • Install the Windows 10 KB4025334 update on the RD Gateway. Later cumulative updates may already contains this KB.
  • Make sure public trusted certificates are configured for the RD Gateway and RD Web Access roles.
  • Make sure that any computers your users will connect to are running one of the following OS versions:
    • Windows 10
    • Windows Server 2008R2 or later

Your users will see better performance connecting to Windows Server 2016 (or later) and Windows 10 (version 1611 or later).

Important

If you used the web client during the preview period and installed a version prior to 1.0.0, you must first uninstall the old client before moving to the new version. If you receive an error that says 'The web client was installed using an older version of RDWebClientManagement and must first be removed before deploying the new version,' follow these steps:

  1. Open an elevated PowerShell prompt.
  2. Run Uninstall-Module RDWebClientManagement to uninstall the new module.
  3. Close and reopen the elevated PowerShell prompt.
  4. Run Install-Module RDWebClientManagement -RequiredVersion <old version> to install the old module.
  5. Run Uninstall-RDWebClient to uninstall the old web client.
  6. Run Uninstall-Module RDWebClientManagement to uninstall the old module.
  7. Close and reopen the elevated PowerShell prompt.
  8. Proceed with the normal installation steps as follows.

How to publish the Remote Desktop web client

To install the web client for the first time, follow these steps:

Rdp Client Download

  1. On the RD Connection Broker server, obtain the certificate used for Remote Desktop connections and export it as a .cer file. Copy the .cer file from the RD Connection Broker to the server running the RD Web role.

  2. On the RD Web Access server, open an elevated PowerShell prompt.

  3. On Windows Server 2016, update the PowerShellGet module since the inbox version doesn't support installing the web client management module. To update PowerShellGet, run the following cmdlet:

    Important

    You'll need to restart PowerShell before the update can take effect, otherwise the module may not work.

  4. Install the Remote Desktop web client management PowerShell module from the PowerShell gallery with this cmdlet:

  5. After that, run the following cmdlet to download the latest version of the Remote Desktop web client:

  6. Next, run this cmdlet with the bracketed value replaced with the path of the .cer file that you copied from the RD Broker:

  7. Finally, run this cmdlet to publish the Remote Desktop web client:

    Make sure you can access the web client at the web client URL with your server name, formatted as https://server_FQDN/RDWeb/webclient/index.html. It's important to use the server name that matches the RD Web Access public certificate in the URL (typically the server FQDN).

    Note

    When running the Publish-RDWebClientPackage cmdlet, you may see a warning that says per-device CALs are not supported, even if your deployment is configured for per-user CALs. If your deployment uses per-user CALs, you can ignore this warning. We display it to make sure you're aware of the configuration limitation.

  8. When you're ready for users to access the web client, just send them the web client URL you created.

Note

To see a list of all supported cmdlets for the RDWebClientManagement module, run the following cmdlet in PowerShell:

How to update the Remote Desktop web client

When a new version of the Remote Desktop web client is available, follow these steps to update the deployment with the new client:

  1. Open an elevated PowerShell prompt on the RD Web Access server and run the following cmdlet to download the latest available version of the web client:

  2. Optionally, you can publish the client for testing before official release by running this cmdlet:

    The client should appear on the test URL that corresponds to your web client URL (for example, https://server_FQDN/RDWeb/webclient-test/index.html).

  3. Publish the client for users by running the following cmdlet:

    This will replace the client for all users when they relaunch the web page.

How to uninstall the Remote Desktop web client

To remove all traces of the web client, follow these steps:

  1. On the RD Web Access server, open an elevated PowerShell prompt.

  2. Unpublish the Test and Production clients, uninstall all local packages and remove the web client settings:

  3. Uninstall the Remote Desktop web client management PowerShell module:

How to install the Remote Desktop web client without an internet connection

Follow these steps to deploy the web client to an RD Web Access server that doesn't have an internet connection.

Note

Installing without an internet connection is available in version 1.0.1 and above of the RDWebClientManagement PowerShell module.

Note

You still need an admin PC with internet access to download the necessary files before transferring them to the offline server.

Note

Microsoft Rdp Web Client Html5

The end-user PC needs an internet connection for now. This will be addressed in a future release of the client to provide a complete offline scenario.

From a device with internet access

  1. Open a PowerShell prompt.

  2. Import the Remote Desktop web client management PowerShell module from the PowerShell gallery: Adobe photoshop cs6 extended keygen generator.

  3. Download the latest version of the Remote Desktop web client for installation on a different device:

  4. Download the latest version of the RDWebClientManagement PowerShell module:

  5. Copy the content of 'C:WebClient' to the RD Web Access server.

From the RD Web Access server

Follow the instructions under How to publish the Remote Desktop web client, replacing steps 4 and 5 with the following.

  1. You have two options to retrieve the latest web client management PowerShell module:

    • Import the Remote Desktop web client management PowerShell module:
    • Copy the downloaded RDWebClientManagement folder to one of the local PowerShell module folders listed under $env:psmodulePath, or add the path to the folder with the downloaded files to the $env:psmodulePath.

  2. Deploy the latest version of the Remote Desktop web client from the local folder (replace with the appropriate zip file):

Connecting to RD Broker without RD Gateway in Windows Server 2019

This section describes how to enable a web client connection to an RD Broker without an RD Gateway in Windows Server 2019.

Setting up the RD Broker server

Follow these steps if there is no certificate bound to the RD Broker server

  1. Open Server Manager > Remote Desktop Services.

  2. In Deployment Overview section, select the Tasks dropdown menu.

  3. Select Edit Deployment Properties, a new window titled Deployment Properties will open.

  4. In the Deployment Properties window, select Certificates in the left menu.

  5. In the list of Certificate Levels, select RD Connection Broker - Enable Single Sign On. You have two options: (1) create a new certificate or (2) an existing certificate.

Follow these steps if there is a certificate previously bound to the RD Broker server

  1. Open the certificate bound to the Broker and copy the Thumbprint value.

  2. To bind this certificate to the secure port 3392, open an elevated PowerShell window and run the following command, replacing '< thumbprint >' with the value copied from the previous step:

    Note

    To check if the certificate has been bound correctly, run the following command:

    In the list of SSL Certificate bindings, ensure that the correct certificate is bound to port 3392. Webmail 4.61.

  3. Open the Windows Registry (regedit), go to HKLMSYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp and locate the key WebSocketURI. Next, set the value to https://+:3392/rdp/.

Setting up the RD Session Host

Follow these steps if the RD Session Host server is different from the RD Broker server:

  1. Create a certificate for the RD Session Host machine, open it and copy the Thumbprint value.

  2. To bind this certificate to the secure port 3392, open an elevated PowerShell window and run the following command, replacing '< thumbprint >' with the value copied from the previous step:

    Note

    To check if the certificate has been bound correctly, run the following command:

    In the list of SSL Certificate bindings, ensure that the correct certificate is bound to port 3392.

  3. Open the Windows Registry (regedit) and navigate to HKLMSYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp and locate the key WebSocketURI. The value must be set to https://+:3392/rdp/.

General Observations

  • Ensure that both the RD Session Host and RD Broker server are running Windows Server 2019.

  • Ensure that public trusted certificates are configured for both the RD Session Host and RD Broker server.

    Note

    If both the RD Session Host and the RD Broker server share the same machine, set the RD Broker server certificate only. If the RD Session Host and RD Broker server use different machines, both must be configured with unique certificates.

  • The Subject Alternative Name (SAN) for each certificate must be set to the machine's Fully Qualified Domain Name (FQDN). The Common Name (CN) must match the SAN for each certificate.

How to pre-configure settings for Remote Desktop web client users

This section will tell you how to use PowerShell to configure settings for your Remote Desktop web client deployment. These PowerShell cmdlets control a user's ability to change settings based on your organization's security concerns or intended workflow. The following settings are all located in the Settings side panel of the web client.

Suppress telemetry

By default, users may choose to enable or disable collection of telemetry data that is sent to Microsoft. For information about the telemetry data Microsoft collects, please refer to our Privacy Statement via the link in the About side panel.

As an administrator, you can choose to suppress telemetry collection for your deployment using the following PowerShell cmdlet:

By default, the user may select to enable or disable telemetry. A boolean value $false will match the default client behavior. A boolean value $true disables telemetry and restricts the user from enabling telemetry.

Remote resource launch method

Note

This setting currently only works with the RDS web client, not the Windows Virtual Desktop web client.

Microsoft rdp web client html5

By default, users may choose to launch remote resources (1) in the browser or (2) by downloading an .rdp file to handle with another client installed on their machine. As an administrator, you can choose to restrict the remote resource launch method for your deployment with the following PowerShell command:

By default, the user may select either launch method. A boolean value $true will force the user to launch resources in the browser. A boolean value $false will force the user to launch resources by downloading an .rdp file to handle with a locally installed RDP client.

Reset RDWebClientDeploymentSetting configurations to default

To reset a deployment-level web client setting to the default configuration, run the following PowerShell cmdlet and use the -name parameter to specify the setting you want to reset:

Troubleshooting

If a user reports any of the following issues when opening the web client for the first time, the following sections will tell you what to do to fix them.

What to do if the user's browser shows a security warning when they try to access the web client

The RD Web Access role might not be using a trusted certificate. Make sure the RD Web Access role is configured with a publicly trusted certificate.

If that doesn't work, your server name in the web client URL might not match the name provided by the RD Web certificate. Make sure your URL uses the FQDN of the server hosting the RD Web role.

What to do if the user can't connect to a resource with the web client even though they can see the items under All Resources

If the user reports that they can't connect with the web client even though they can see the resources listed, check the following things:

  • Is the RD Gateway role properly configured to use a trusted public certificate?
  • Does the RD Gateway server have the required updates installed? Make sure that your server has the KB4025334 update installed.

If the user gets an 'unexpected server authentication certificate was received' error message when they try to connect, then the message will show the certificate's thumbprint. Search the RD Broker server's certificate manager using that thumbprint to find the right certificate. Verify that the certificate is configured to be used for the RD Broker role in the Remote Desktop deployment properties page. After making sure the certificate hasn't expired, copy the certificate in .cer file format to the RD Web Access server and run the following command on the RD Web Access server with the bracketed value replaced by the certificate's file path:

Diagnose issues with the console log

If you can't solve the issue based on the troubleshooting instructions in this article, you can try to diagnose the source of the problem yourself by watching the console log in the browser. The web client provides a method for recording the browser console log activity while using the web client to help diagnose issues.

  • Select the ellipsis in the upper-right corner and navigate to the About page in the dropdown menu.
  • Under Capture support information select the Start recording button.
  • Perform the operation(s) in the web client that produced the issue you are trying to diagnose.
  • Navigate to the About page and select Stop recording.
  • Your browser will automatically download a .txt file titled RD Console Logs.txt. This file will contain the full console log activity generated while reproducing the target issue.

The console may also be accessed directly through your browser. The console is generally located under the developer tools. For example, you can access the log in Microsoft Edge by pressing the F12 key, or by selecting the ellipsis, then navigating to More tools > Developer Tools.

Get help with the web client

If you've encountered an issue that can't be solved by the information in this article, you can report it on Tech Community. You can also request or vote for new features at our suggestion box.

In January we published a blog post on our first experiences with the HTML5 RD Web Client. Now, in this multi-part article series, we investigate the overall performance of this new client (out in public preview). Our testing focuses on the perceived end-user experience. For these tests we:

  1. Used REX Analytics workloads to generate automated work in the user session
  2. Recorded the user experience of the primary user using Camtasia software
  3. Used REX Analyzer to visually compare the recordings

To simulate a real-world scenario, we created our RDS environment in Azure (West EU) and we connected to the deployment from a location in Amsterdam which generates low latency, typical of users connecting to an azure deployment from their office. Appendix A details our RDS environment build out in Azure.

Part 1 – RD Web Client vs MSTSC Client

This article compares the performance of the RD Web Client against the traditional MSTSC client that is native to the Windows OS. We will look for any variation in the end user experience that we witness as due to using one client or the other. Specifically, we will look for variation in user interface response times and refresh rates as well as perceived graphics and media performance. We chose to run a full desktop session for these tests and we also enabled AVC encoding via Group Policy. Appendix A explains why we chose these options. We published the Session Collection and connected to the deployment via the respective web sites. The following is our match-ups and our analysis.

Test 1 – 1080p Video Performance

In this test we played hi-res video (1080p) stored on the RD Session Host server.

[fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”]

Results: Both clients had issues playing the hi-res video. In the beginning the MSTSC client seems to output more frames for a crisper, smoother, more detailed picture. But throughout both test runs we encounter some choppy performance and missed frames. Particularly towards the end of the match-up, we witness some serious mosaicking. If we had to choose a winner we would choose the MSTSC client, but not by much.

Test 2 – Google Maps Performance (DX9)

This test compares Google Earth DX9 performance.

[/fusion_builder_column][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”]

Test 2 – Google Maps Performance (DX9)

Results: The experiences were very similar for both clients. Nothing particularly remarkable stood out by comparison. It did seem like the HTML 5 client might have performed just slightly better a few times – a few scenes became crisper faster. But on the whole, this was a tie.

Test 3 – Roller Coaster Performance (DX9)

This test runs a DX9 animation file depicting a roller coaster ride.

Microsoft Rdp Web Client Login

[/fusion_builder_column][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”]

Results: The MSTSC client and the HTML 5 client performed similarly. We did not see any real difference in the amount of degradation or frame loss, the graphics were both smooth at the same points and choppy at the same points.

Test 4 – PowerPoint Presentation Performance (DX10)

In this test we use Microsoft PowerPoint Viewer to open and run a PowerPoint presentation that has animations.

[/fusion_builder_column][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”]

Test 4 – PowerPoint Presentation Performance (DX10)

Results: Both clients performed decently. MSTSC client wins this round, but again, not by much. We can tell a few times where MSTSC provides more frames resulting in a more detailed and smoother transition from one graphic animation to the next.

Detected Bandwidth Observation

It was interesting that in these back to back test runs (per match-up) we saw that the bandwidth detected by RD Analyzer in the HTML5 test runs was approximately double the bandwidth in the MSTSC test runs. Spaceclaim download full. More investigation here is needed.

RemoteApp Start Experience

We noticed that when you close a RemoteApp using the HTML 5 client the webpage window goes black for several seconds.

After several seconds the screen changes and you will see the RemoteApp icons again. The user experience with the MSTSC is different in that when you closed a RemoteApp you could immediately start another RemoteApp from the RD We Access website.

This is expected behavior. Since the RD Web Client uses Immersive RemoteApp, when the last window is closed, the session is still active. By default, the session will stay active (even when there are no windows open) for 20 seconds (configurable by admins) before dropping the session. In MSTSC, when you close an application window, you still see the regular RD Web Access website, so you can instantly choose a different RemoteApp – the session sticks around for 20 seconds in this scenario as well – you just don’t realize it because if you used the RD Web Access website, you end up back on that webpage and you can choose a new RemoteApp.

IN the RD Web Client you need to select the All Resources tab to launch a new RemoteApp without having to wait.

AVC vs Default Profile

We made sure that both clients used the AVC profile. We also did some comparisons with the clients using their default configuration to see what differences in performance there might be. This meant that out of the box, MSTSC does not use the AVC profile and the RD Web Client does. In this context, the HTML 5 client performed a bit better in our Google Earth test runs, and it performed as well as the MSTSC client in our PowerPoint test runs and used less bandwidth. Here are those match-ups:

Test 5 – Google Maps Performance – Default Deployment

Within this test we run Google Earth testing DX9 performance.

[/fusion_builder_column][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”]

Test 5 – Google Maps Performance – Default Deployment

Results: The HTML 5 client experience wins. The HTML 5 client showed more graphic details especially while panning across the globe surface. The details of zoomed in locations also appeared to be more defined faster than in the MSTSC client experience.

Test 6 – PowerPoint Presentation (DX10) Performance – Default Deployment

In this test we use Microsoft PowerPoint Viewer to open and run a PowerPoint presentation.

[/fusion_builder_column][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”]

Test 6 – PowerPoint Presentation (DX10) Performance – Default Deployment

Results: Both clients performed decently. We do see some dropped frames and some stuttering, but on the whole the performance was similar in both scenarios. It is interesting to point out that the MSTSC used more bandwidth and utilized the UDP protocol while the HTML 5 client does not use UDP and uses less bandwidth while providing a similar end user experience.

UDP vs TCP

In the “out of the box” tests, we noticed more than once that UDP output bandwidth in the MSTSC client test run was much more (twice+) than the TCP output bandwidth in the HTML5 client test run. (see the Roller Coaster test runs to witness it). It would seem that in this case TCP as a remoting protocol is more efficient than RDP 10 (UDP). For now, this is just an observation and requires more research. When we know more, you will.

Summary

We were expecting the MSTSC client to do better than the HTML 5 client due to it utilizing the UDP protocol (the HTML5 client cannot use this protocol). We also expected that when both clients utilized AVC that MSTSC would really shine. So, we were a bit surprised to observe that while MSTSC may have had a slight edge on some test runs and scenarios, the HTML 5 client really stood up well.

This is great news in that your client options have just grown – it’s possible that you can offer an out of the box HTML5 client, and you may not have to give up much in performance!

Coming Up Next!

In our next article we will compare these two clients again, but this time we will remove UDP protocol from the mix (as some companies do not like to enable it.) We expect that the HTML 5 client may shine here. Stay tuned to find out if this is true or not!

Have a great idea for a comparison that you would like to see between the native MSTSC client and the new RD Web Client? Let us know!

Appendix A – Our Infrastructure Setup

For this article series we will run all performance tests in the same highly available RDS environment hosted on Azure IaaS with the following components:

  • 2 VMs running the RD Connection Broker (RDCB) and RD Licensing (RDL) roles
  • 2 VMs running the RD Web Access (RDWA) and RD Gateway(RDGW) roles
  • 2 VMs running RD Session Host (RDSH) role
  • 1 External Azure Load Balancer, load balancing the RDGW and RDWA roles
  • 1 Internal Azure Load Balancer, load balancing the RDCB role
  • 1 Azure SQL Database used by the RDCB roles

More environment details are as follows:

  • The RD Session Host servers are a D2_v2 VM, (Xeon E5 processor, 7GB RAM)
  • We installed the RD Web Client (the HTML 5 client) on both existing RD Web Access Servers
  • We used a Windows 10 client with the latest updates & patches
  • We used Microsoft Edge as the web browser

Web Client Camera Viewer

Full Desktop Comparison Instead of RemoteApp

We decided to use the full desktop instead of RemoteApp so that we made a fair comparison. Here’s why:

“The windows client (MSTSC) can do full integrated RemoteApp with advanced graphics but the RD Web Client can only do immersive RemoteApp. Integrated RemoteApp with advanced graphics supports per surface remoting and each surface (RemoteApp window) has its own graphics context. This allows us to integrate better with the local shell and provide a seamless experience for users. But it is also more resource intensive. Immersive RemoteApp only has 1 graphics context for each monitor. For example, if a RemoteApp is occluded on the screen, we won’t have its graphics content. The resource cost of this kind of connection is similar to desktop.”

Jayashree Sadagopan – Software Engineer Lead, Microsoft

AVC Encoding Tweaks

We enabled AVC encoding via Group Policy to make sure both clients used the same AVC capabilities. By default, MSTSC uses the default profile (non-AVC enabled) whereas the RD Web Client uses the AVC profile (the RD Web Client uses a thin client flag to get AVC from the server regardless of Group Policy settings).

AVC encoding will outperform for graphics intensive scenarios in terms of encoding time and bit rate. Also, both clients use hardware accelerated decoding for the AVC profile but not for default profile.

We should also point out that AVC capabilities also have OS version requirements:

  • RemoteApp in advanced graphics mode was supported since Server 2012 R2 – https://cloudblogs.microsoft.com/enterprisemobility/2013/11/25/remoteapp-improvements-in-windows-server-2012-r2/.
  • AVC mode was supported since Server 2016

For more on Remote Desktop Protocol (RDP) 10 AVC/H.264 improvements in Windows 10 and Windows Server 2016 see this article.

Appendix B – Other REX Bench-marking Tests

Here are some other examples of projects where we have use the REX Analytics framework:

[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]