Monday, July 16, 2018

Microsoft HTML5 client for RDS (RD Web Client) reached general availability!

imageGreat news, the Microsoft RD Web Client reached general availability today! This means we can now start using a modern browser to access published Desktops and Applications based on HTML5. I have been following the RD Web Client since very early private preview stages and it’s great to see the 1st release out there now!

An overview of the articles I published on this topic over the past year:

January 2018
HTML5 client for Microsoft Remote Desktop Services 2016: Remote Desktop Web Client

March 2018
Microsoft HTML5 client public preview now available!

July 2018
New logon experience for RDS HTML5 client, with SSO! (and close to general availability)

The PowerShell CmdLet Install-RDWebClientPackage will automatically download the latest version of the client. I have already updated my lab;

image

This is the first version of the RD Web Client but the product team is already working on new features and improvements. One of the features I hear requested a lot is the ability to provide direct links to individual RemoteApps. This is referred to as Deep Linking and allows you to add links to for example the Office365 App Launcher, SharePoint or other 3rd party Application Launchers. You can vote for this feature here

Microsoft Documentation on Docs: Set up the Remote Desktop web client for your users

More information on the updates of this release and previous releases, check out What's new for the Remote Desktop web client?

Friday, July 13, 2018

Using Azure Firewall to secure RDS and RDmi on Azure

imageRecently Microsoft released the public preview version of Azure Firewall. Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It is a stateful firewall as a service with built-in high availability and unrestricted cloud scalability. Using Azure Firewall, you can create, enforce, and log application and network connectivity policies across subscriptions and virtual networks. It also integrates with the Azure platform, portal UI and services.

How does the Azure Firewall relate to Network Security Groups (NSG)? NSG and Azure Firewall are complementary providing better in-depth network security. An NSG provides distributed network layer traffic filtering to limit traffic to resources within virtual networks. Azure Firewall is a fully stateful centralized network firewall as-a-service, providing network and application level protection across virtual networks.

This public preview supports the following features

- Outbound FQDN filtering

- Network traffic filtering rules

- Outbound SNAT support

- Azure Monitor logging

Time to put this Preview Release to the test! In this blog post I’m test-driving Azure Firewall Preview by testing a specific Use Case, to secure outbound traffic from a Remote Desktop Services environment. This blog post describes how to leverage Azure Firewall to secure Remote Desktop Services sessions running on Azure. The setup in this blog post based on RDS on Azure IaaS but is also applicable to the upcoming Remote Desktop modern infrastructure (RDmi). In fact, the deployment is exactly the same since both RDS on IaaS as well as RDmi use RD Session Hosts running in your Azure Subscription based on IaaS.

The first step is to enable your Azure Subscription to use the Public Preview of Azure Firewall.
Logon to Azure RM using PowerShell and run the following two commands:

Register-AzureRmProviderFeature -FeatureName AllowRegionalGatewayManagerForSecureGateway -ProviderNamespace Microsoft.Network

Register-AzureRmProviderFeature -FeatureName AllowAzureFirewall -ProviderNamespace Microsoft.Network

image

The registration can take ~30 minutes to complete, but in my case, it took ~10 minutes. You can check the status of the registration by running these two commands. Once completed it should state registered.

Get-AzureRmProviderFeature -FeatureName AllowRegionalGatewayManagerForSecureGateway -ProviderNamespace Microsoft.Network

Get-AzureRmProviderFeature -FeatureName AllowAzureFirewall -ProviderNamespace Microsoft.Network

image

Once the status shows registered, run the following command to finish the registration

Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Network

image

Before we can create the Azure Firewall, a new subnet must be created. For the purpose of this lab environment I’m creating a new subnet within my existing Vnet where a separate subnet with my RDS deployment already resides. For production deployments, a hub and spoke model is recommended, where the firewall is in its own VNet, and workload servers are in peered VNets.

The screenshot below shows the creation of the Subnet for the Azure Firewall. Note that the subnet name must be names AzureFirewallSubnet otherwise you will not be able to deploy the Azure Firewall.
clip_image002[5]

Next, we can go ahead and create the Azure Firewall, which is available from the Azure Marketplace.
clip_image004[4]

We need to specify the parameters. Make sure you select the existing Vnet where as part of a previous step, the subnet called AzureFirewallSubnet was created. Also, I noticed that the Azure Firewall needs to be created in the same ResourceGroup as the existing Vnet.

clip_image006[4]

You can of course also use a JSON template to create the Azure Firewall. Below is code snippet of how to create the Azure Firewall using JSON.

image

After the creation of the firewall, we need to create a new route table to make sure outbound traffic from the Subnet will go through the Azure Firewall.

clip_image008[4]

Next, we associate the Route Table to subnet where our destination servers are located. In this example I selected the Subnet where the RD Session Host servers are running.

clip_image010[4]

And finally, we need to add the route. For this example, we set the prefix to 0.0.0.0/24 and point it to the private IP-address of the Azure Firewall. This basically means that all outgoing traffic will flow through the Azure Firewall. Note that although the Azure Firewall is more of a managed service, we need to select virtual appliance here.

clip_image012[4]

Now that the Azure Firewall and Route are in place, we can start defining rules in the firewall. For this use case we want to control traffic from the RD Session Host to the internet. For this example let’s say we are publishing a browser as a RemoteApp on RDS and want to control, basically whitelist, the URL’s the user can browse to, ultimately creating a “secure browser”.

In order to do so, we create the rule below. This basically says, anything from within the Subnet that we want to control is allowed http and https access to *github.com. Anything else will be rejected.

clip_image014[4]

In this environment the RD Session Host server is a member of an Active Directory domain, where the Domain Servers are within a subnet within the same vnet. In scenarios where you are using an external DNS service, you also need to create a rule to allow DNS services. This can be done using a Network. Rule, the screenshot below shows an example of what that could look like.

clip_image016[4]

And that’s it. We have just created a basic secure browser environment. Let’s logon to RDS as an end user and take a look at some of the results.

In this scenario, the RD Session Host server that is part of an RDS on Azure IaaS deployment is located on the Subnet with the Route and thus the Firewall in place.

We log on to Remote Desktop Services web client (HTML5) (which recently went to Preview 0.9.0 release)

clip_image018[4]

And we open the Github published application.

clip_image020[4]

We now running a secure browser with github.com from within a locally running chrome. Isn’t that what you’ve always wanted to do? Run IE inside Chrome? :) This is just an example of course, we could have also used mstsc or RD Web Access as well.

clip_image022[4]

But anyway, let’s put the Azure Firewall to the test and browse to a different URL, amazon.com. We can now see the Azure Firewall at work, blocking that traffic based on the rules we defined.

image

This completed my first test. Obviously, this is just the first preview release of the Azure Firewall and we’ve only looked at a specific feature (Outbound FQDN filtering) to get some hands-on experience. It is however great to see Azure Networking evolving, and I’m looking forward to future features!

Friday, July 6, 2018

New logon experience for RDS HTML5 client, with Single Sign On! (and close to general availability)

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 like. Back then, this was all based on a Private Preview that I was part of. In March of this year the HTML5 client entered the Public Preview stage allowing everyone to start testing the client.

And now, the Public Preview is updated to a new release, the 0.9.0 release which has some great new features in it. This blog post discusses those features.

The most important change in the release is the support for Single Sign On (SSO)! If you’ve seen my previous article on the private preview version or if you have been testing the public preview after it became available, you will have noticed that the WebClient was not SSO at that time. After logging on to the RD Web Access page and clicking on a Published Application or Desktop you were presented with another logon request as shown below.

clip_image001

The number 1 feedback request I heard when showing the WebClient or discussing this with customers was Single Sign On. It is great that this new release now supports it!

So, what does the new logon look like? With the 0.9.0 Public Preview the Sign In Experience itself has also changed. With previous release, when browsing to the WebClient, you were presented with logon screen below, which is identical to the generic RD Web Access page.

clip_image002

With the new 0.9.0 Public Preview Release, the logon screen now looks like this

clip_image004

After entering our username and password, we’re taken to the WebClient Interface showing the Applications and Desktops. This is similar to the WebClient looked like in previews releases.

clip_image006

If I now open a Published Application of Desktop however, it uses the credentials I entered before and the process is a nice and smooth Single Sign On experience!

clip_image008

This is a very welcome change!

You may also have noticed the URL to access the WebClient has changed in this release as well. In previous Preview Releases, this used to be https://<FQDN>/RDWeb/Pages/webclient. This is now changed to https://<FQDN>/RDWeb/webclient/index.html. Similar to the way I explained in a previous article, you can also create IIS redirection in case you want to redirect users directly to the WebClient without the need to specify /rdweb/webclient/index.html when browsing.

Note that the location of the WebClient files also changed to C:\Program Files\RemoteDesktopWeb\Internal\Clients\

clip_image010

Besides the Logon experience and the Single Sign On, this release also support time zone redirection and contains various bug fixes.

I my case I used my existing Azure Resource Manager (ARM) template to deploy a new RDS on Azure IaaS environment. This ARM Template already contained the installation and configuration of the WebClient previous version. For me there was no additional task needed at all. I deployed on ARM Template and it automatically used the latest 0.9.0 release :)

If you do have an existing WebClient Preview implementation based on a previous version, the general advise to upgrade is following the steps as briefly outlined below.

Uninstall the web client
Update the PowerShell module
Close/re-open the PowerShell window
Install the new version of the client
adding the SSL certificate

Note that the instruction above are only applicable for this release update because of some of the changes. For subsequent updates, uninstallation should not be necessary.

For more Microsoft Resources on the installation process use the following links:

Set up the Remote Desktop web client for your users

Access the Remote Desktop web client

I cannot comment yet on the General Availability release date of the WebClient, but I expect this to be very soon and I can encourage you all to start test driving this latest 0.9.0 Public Preview Release!

If you have any questions, feel free to reach out!

Monday, July 2, 2018

Presented a session at the Azure Saturday Conference in Munich

imageOn May 26th I presented a session at the Azure Saturday conference 2018 in Munich. Azure Saturday is a community conferences organized by 3 German MVP’s. The conference was being held in the Microsoft Office in Munich, which made for a great venue!

I presented a session on hosting RDS on Azure. Since Microsoft Ignite last year, I have been getting a lot of questions about RDmi, asking how it really compares to traditional RDS on IaaS. This is the question I answered in my session. Based on 7 facts, I presented my comparison between RDS on Azure IaaS vs RDS on Azure PaaS (RDmi). A big part of the session was a live demo showcasing the 2 solutions.

It turned into a very well received and interactive session. The fact that I handed out stroopwafels for everyone asking an interesting question during the session, might also have helped :)

I really enjoyed speaking there, compliments to the organizers for hosting this, and I hope to be back next year!

Link to the conference: https://azuresaturday.de/

image

Wednesday, April 25, 2018

New Remote Desktop Session Host performance counters to diagnose app performance!

New performance counters for the RD Session Host role are available for the latest Windows Server 2019 preview release!

“…One of the most difficult problems to diagnose is poor application performance - the applications are running slow or don't respond. Traditionally, you start your diagnosis by collecting CPU, memory, disk input/output, and other metrics and then use tools like Windows Performance Analyzer to try to figure out what's causing the problem. Unfortunately, in most situations this data doesn't help you identify the root cause because resource consumption counters have frequent and large variations. This makes it hard to read the data and correlate it with the reported issue. To help you more quickly solve your app performance problems, we've added some new performance counters (available through the Windows Insider Program) that measure user input flows…”

“…The User Input Delay counter can help you quickly identify the root cause for bad end user RDP experiences. This counter measures how long any user input (such as mouse or keyboard usage) stays in the queue before it is picked up by a process, and the counter works in both local and remote sessions…”

“…The User Input Delay counter measures the max delta (within an interval of time) between the input being queued and when it’s picked up by the app in a traditional message loop, as shown in the following flow chart…”

clip_image002

“…The following graph shows readings for users working remotely in Microsoft Word. In this case, the RDSH server performance degrades over time as more users log in…”

clip_image004

Source: Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts

Here is a link to the RDS Team Blog announcement about this:
https://cloudblogs.microsoft.com/enterprisemobility/2018/04/25/new-performance-counters-diagnose-user-application-responsiveness-on-remote-desktop-session-hosts

Tuesday, April 17, 2018

Co-authored a book on Remote Desktop Services!

Cláudio Rodrigues and I have published a book on Remote Desktop Services. We’re proud to announce it’s available for pre-order on Amazon today!

RDS - The Complete Guide: Everything you need to know about RDS. And more.

61Lvlt82g8LMicrosoft Remote Desktop Services, or RDS for short, is a complete platform for remote application delivery, on-premises or in the cloud. Several well-known products like Citrix XenApp, VMware Horizon and Parallels RAS use RDS as their foundation. This book covers everything you need to know to deploy a properly configured Microsoft RDS environment, based on Windows Server 2012 R2 and up, using the Remote Desktop Session Host as the platform where the users' applications will run. Deploying, managing, troubleshooting, monitoring, printing, connecting, every single item is there, explained in very detailed step-by-step guides by long time Microsoft MVPs for Remote Desktop, Cláudio Rodrigues and Freek Berson, both having deployed RDS based solutions for hundreds of customers worldwide. If you are considering migrating from Citrix or other competing products and you want to learn everything about RDS and more than that, learn it the right way, this is the book for you. Companion books covering Windows Server 2016 RDS, Windows Server 2019 RDS and the new RD Modern Infrastructure, RDmi for short, will be available shortly after this release.

Also check out these companies that have contributed to this book as well:

Wednesday, March 28, 2018

Microsoft HTML5 client public preview now available!

Back in January of this year I published a blog post on one of the first releases of the Microsoft HTML5 client for Remote Desktop Services (called Web Client). You can find that blog post here HTML5 client for Microsoft Remote Desktop Services 2016: Remote Desktop Web Client. This was based on a preview private that I was part of. I’ve seen huge interest for the HTML5 client, and the client is now officially in Public Preview, ready for anyone to test drive!

All the information you need:

- Set up the Remote Desktop web client for your users

- Access the Remote Desktop web client

An here is a link to the official RDS Team Blog post where the announcement was made:

https://cloudblogs.microsoft.com/enterprisemobility/2018/03/28/remote-desktop-web-client-public-preview/

clip_image002

Happy testing! If you want more information or help in the setup, feel free to reach out!

Friday, January 12, 2018

HTML5 client for Microsoft Remote Desktop Services 2016: Remote Desktop Web Client

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-manage\RDWebClientManagement")
Install-RDWebClientPackage

clip_image002

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

clip_image004

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.

clip_image006

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.

clip_image008

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.

clip_image010

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.

clip_image012

Since this was the first RemoteApp, the RDS session will now process the logon.clip_image014

And shortly after, the RemoteApp is now available within the browser.clip_image016

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.

clip_image018

The RD Web Client also allows you to copy-paste between your local machine. It is however currently limited to text only.

clip_image020

There is also support for Remote Audio.
clip_image022

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.

clip_image024

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:\sites\Default 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:

clip_image026

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.

clip_image028

I’m able to print to this redirected printer

clip_image030

Which results in the pdf being locally available

clip_image032

And in this case, I opened it in my local browser to then print to a locally available printer.

clip_image034

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.