- In this tutorial we will see how to deploy RemoteApp configured by Group Policy (GPO) on an RDS farm. The deployment of the RDS farm must have: A server with the RD Web Access service. A collection of configured with remoteapp programs. Customers must be on Windows 8 minimum.
- RDS 2012 R2 – Account Restrictions are preventing to signing in – Issue 2; RDS 2012 R2 – Access is Denied While connecting to remoteApp- Issue 3; RDS 2012 R2 – Access is denied – Issue 4; RDS 2012 R2 – DMZ and failing connections; The Situation. We had established a RemoteApp infrastructure with one of our customers.
Nov 08, 2017 Doing some testing before I deploy a RemoteApp farm in a new server environment. Lets say I have Adobe Reader on the RDS server and published in RemoteApp. A user has a PDF file on their local desktop. Is it possible for the user to load the local file into RemoteApp by just double clicking it? Also, lets turn the situation around.
Everyone will be familiar with the Remote Desktop client called MSTSC. 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.
As a next step, Microsoft now also has a web client based on HTML5 (currently into preview), called the RD Web Client. This blog post runs through the setup, based on the early preview that I tested. The Remote Desktop Web Client is installed as an extension of the RD Web Access role.
Requirements
The requirements for the Web Client are as follows;
· RD deployment with Gateway, Broker and WebAccess roles all running Server 2016 Operating System. The endpoints (RDSH or Windows Client SKUs) can be running any Windows Operating System starting from Windows 7 SP1 / Windows Server 2008 R2. The client performance will however be better when connecting to Windows Server 2016 or Windows 10 Anniversary Edition or later.
· The RD deployment should NOT be configured to use per-device license.
· The Server 2016 machine hosting RD Gateway role must have this update installed – https://support.microsoft.com/en-us/help/4025334/windows-10-update-kb4025334
· The Gateway and WebAccess roles should be using public trusted certificates
· The client should work on most HTML5 capable browsers and has official support for Edge, IE11, Google Chrome, Firefox and Safari. Mobile devices are not supported.
Installation
By the time the client releases, new PowerShell CmdLets will be available to deploy, manage and configure the client. Based on the current beta, here’s an example of what these cmdlets might look.
We open an Administrative PowerShell console and run the following commands:
Import-Module ($Env:ProgramFiles + “rd-html5-manageRDWebClientManagement”)
Install-RDWebClientPackage
Next, we copy the certificate used by the RD Web Access role. Optionally export it first, and make sure to include the private key. Then run the following commands in the PowerShell Admin console.
Import-RDWebClientBrokerCert <cer file>
Publish-RDWebClientPackage -Production -Latest
Easy as that! HTML5 support is now added to the RD Web Access role!
Note, in the beta release the Import-RDWebClientBrokerCert currently does not accept password protected pfx files. Make sure you export the certificate using the security principal option as shown below.
Testing
To test the HTML5 web client, open a browser (currently Edge, IE 11, Google Chrome browsers are all officially supported) and browse to https://<publicdomain>/RDWeb/Pages/webclient. For example, in my case I tested an Azure IaaS setup with 2 RD Web Access servers behind an Azure Load balancer. I created a public DNS record for rds.rdsgurus.com and pointed that to the public IP of the Azure Load Balancer. I then browsed to https://rds.rdsgurus.com/RDWeb/Pages/webclient.
At first you will see the regular RD Web Access login screen and you login with a test account as you normally would too.
After logging in you will see the following screen, this is the HTML5 web client containing the 4 sample RemoteApps I published in the RDS deployment.
If you click on one of the RemoteApps an RDP session will be launched. Note that currently you will get an additional prompt for the first RemoteApp as there is no full Single Sign On yet.
Since this was the first RemoteApp, the RDS session will now process the logon.
And shortly after, the RemoteApp is now available within the browser.
From this point, you can navigate to the bar on the left-hand side and switch between applications and launch new application. All RemoteApps are available within the same screen to allow to work with multiple application easily.
The RD Web Client also allows you to copy-paste between your local machine. It is however currently limited to text only.
There is also support for Remote Audio.
For further management, the RDWebClientManagement PowerShell module beta version also comes with a few other Cmdlets to retrieve the package information, certificate and to uninstall the package. Note that these Cmdlets might slightly change once the PowerShell module reaches general availability.
If you want all users to be redirected to the Web Client instead of the traditional RD Web Access page, you can run the following command on the RD Web Access Server
Set-WebConfiguration system.webServer/httpRedirect “IIS:sitesDefault Web Site” -Value @{enabled=”true”;destination=”https://<domainname>/rdweb/pages/webclient”;exactDestination=”false”;httpResponseStatus=”Permanent”;childOnly=”true”};
Or change the same value using IIS Manager:
The RD Web Client also comes with printing support. A virtual printer called “Microsoft Print to PDF” is available in the user’s session. Don’t be confused by the postfix “redirected 3”. This is not a redirected printer, the name will most likely change so that it is clear that it’s a virtual printer. By virtual printer we mean that the printing to this printer will result in a .pdf file that is transported and opened on the local client. From that local client it can then be printed to any locally available printer.
I’m able to print to this redirected printer
Which results in the pdf being locally available
And in this case, I opened it in my local browser to then print to a locally available printer.
This concludes a first walkthrough of the RD Web Client that is coming up, based on the current preview version. I will share more details on this new client as they come in. If you are currently using RDS in a production environment and would like to test drive the RD Web Client functionality. Feel free to reach out to me so that I can help to get onboarded on the preview.
-->Rds Remote Apps
Applies to: Windows Server (Semi-Annual Channel), Windows Server 2019, Windows Server 2016
Below are various configurations for deploying Remote Desktop Services to host Windows apps and desktops for end-users.
Note
Remote Desktop Remoteapp
The architecture diagrams below show using RDS in Azure. However, you can deploy Remote Desktop Services on-premises and on other clouds. These diagrams are primarily intended to illustrate how the RDS roles are colocated and use other services.
Rds Remoteapp Pro
Standard RDS deployment architectures
Remote Desktop Services has two standard architectures:
- Basic deployment – This contains the minimum number of servers to create a fully effective RDS environment
- Highly available deployment – This contains all necessary components to have the highest guaranteed uptime for your RDS environment
Basic deployment
Highly available deployment
RDS architectures with unique Azure PaaS roles
Though the standard RDS deployment architectures fit most scenarios, Azure continues to invest in first-party PaaS solutions that drive customer value. Below are some architectures showing how they incorporate with RDS.
RDS deployment with Azure AD Domain Services
The two standard architecture diagrams above are based on a traditional Active Directory (AD) deployed on a Windows Server VM. However, if you don't have a traditional AD and only have an Azure AD tenant—through services like Office365—but still want to leverage RDS, you can use Azure AD Domain Services to create a fully managed domain in your Azure IaaS environment that uses the same users that exist in your Azure AD tenant. This removes the complexity of manually syncing users and managing more virtual machines. Azure AD Domain Services can work in either deployment: basic or highly available.
RDS deployment with Azure AD Application Proxy
The two standard architecture diagrams above use the RD Web/Gateway servers as the Internet-facing entry point into the RDS system. For some environments, administrators would prefer to remove their own servers from the perimeter and instead use technologies that also provide additional security through reverse proxy technologies. The Azure AD Application Proxy PaaS role fits nicely with this scenario.
For supported configurations and how to create this setup, see how to publish Remote Desktop with Azure AD Application Proxy.