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

Great 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 1^st 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;

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 3^rd 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?

Using Azure Firewall to secure RDS and RDmi on Azure

Recently 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

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

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

Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Network

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.

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

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.

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.

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.

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.

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.

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.

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.

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)

And we open the Github published application.

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.

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.

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!

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.

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.

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

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.

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!

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\

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!

Presented a session at the Azure Saturday Conference in Munich

On 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/