Windows 10 Multi-Session as the RDSH of the future (and running Edge as a published App!)

By now, you most likely heard about Windows Virtual Desktop (WVD) as the evolution of RDmi and how Windows10 Multi-session is part of that evolution. If not, these announcements we’re all made public during Microsoft Ignite 2018 last month. I previously published a blog post on news that was shared in a post that is called Windows Virtual Desktop, RDS 2019 and Multi Session Windows 10, What a week and I covered a recap of the sessions I presented myself in Orlando called Presented 2 sessions at Microsoft Ignite 2018, Orlando.

I have been part of the RDmi private preview program since the early days, almost a year ago, and I’ve had the privileged to test the early WVD platform as well. In this blog post I want to focus on one of the benefits of WVD, the ability to use Windows10 Multi-session.
At Ignite 2018, Microsoft officially announced the Windows10 Multi-Session, the first official multi-user Windows 10 version that allowed multiple concurrent users to connect. This basically means that Windows10 can now also be used as an “RD Session Host server”, where this was previously only possible using a Windows Server operating system. So why is this interesting and how is this beneficial for publishing Applications and Desktops?

Let’s look at the three pillars in the below diagram (credits to various Microsoft Slide Decks used at Microsoft Ignite 2018).

- On the left-hand side, we have Windows Server RD Session Host. Traditionally, this has been widely used option to publish Applications and Desktops using RDS. The great thing about Windows Server RD Session Host is that it allows users to share available resources. Multiple users can connect to a server simultaneously making a very flexible, cost-effective and easy to manage solution. The obvious downside of this solutions is that it is based on Windows Server. This means that the user is presented with a different experience compared to his local modern Windows10. Modern Apps like for example Edge and Cortana are not available and it’s all based on a Long-Term Service Release.

- On the right-hand side we have Windows 10 in a Pooled or Personal VDI-like setup. Compared to Windows Server RD Session Host, this setup does allow the user to get the modern experience he is used to, including Universal Windows Apps. One of the downsides of this approach has always been that this is a one-to-one setup. Whether is a pooled or personal setup, every user runs his own Windows 10. This adds additional challenges in terms of scaling, complexity and in most scenarios resulted in less cost-effective setup. Over the years, many vendors have however been developing great suites and tools to remove parts of the complexity, add scaling and trim down the costs.

- In the middle Microsoft introduced Windows 10 Multi-Session, and this is basically best of both worlds. This approach has the multi-user benefits of RD Session Host and the modern experience benefits from Windows 10. What’s also important to note is that going forward, Windows 10 will be the only option to run Office 365 Pro Plus. Windows Server 2019 will only support Office 2019 Perpetual meaning you will miss out the all of the collaboration features.

With all of the improvements of RDS in Windows Server 2019, Microsoft is definitely not giving up on RD Session Host. But based on the all of the arguments outline above, I’d state that Windows 10 Multi-User is the RD Session Host of the future. There is one caveat worth mentioning, Windows 10 multi-user only comes with WVD meaning you cannot run this outside of Azure. For workloads that cannot move to Azure, Windows Server 2019 will be the way to go.

There are two questions I get very frequently when talking to people about WVD.

- Microsoft introduced RDmi last year, is WVD replacing RDmi?
The answer is no. WVD is evolved on RDmi and uses the RDmi platform rather than replacing it. This means that all of the good things of RDmi like Multi Tenancy and AAD support still exist. The main difference is that you will not be hosting the RDS infrastructure roles in your own subscription (the model that RDmi was) but instead Microsoft will host them for you.

- Does Windows Virtual Desktop only support publishing Full Desktops and not RemoteApps?
The answer is no again. Despite the name Windows Virtual Desktop, a Host Pool in WVD is very flexible and can publish Full Desktop and RemoteApps. It can even host a mix of Desktops and Remote Apps coming from servers and clients that go back as far back as Windows7 (with free extended support) and Windows Server 2012R2!

Windows Virtual Desktop can be provisioned using the Azure Marketplace and using ARM Templates. Below is a preview screenshot of the marketplace entry, note that this may be subject to change.

Once WVD is provisioned, management can be performed using PowerShell or Rest API.

In the below screenshot you can see a mix of RemoteApps and Full Desktop within the HTML5 client of WVD. The RemoteApps as well the Full Desktop is based on Windows 10 Multi-Session.

And you can see even Edge (not available in a Windows Server RDSH) is now published here as a RemoteApp! And yes, that means I can run Microsoft Edge inside Chrome! :)

Besides HTML5, I can also leverage the RemoteApp & Desktops Connections applet and configure it with the WebFeed URL from WVD resulting, in the WVD Desktop & RemoteApps available in my local start menu!

Here is Edge Running as a RemoteApp using the full mstsc experience. You can tell it is a RemoteApp by looking at the taskbar where an RDP icon appears over the Edge icon.

When opening Winver and Task Manager we get prove that this really is the multi-user version of Windows 10.

And for the 3^rd most asked question:

- When will WVD become available?
WVD is planned to become Public Preview soon (later this year) and General Availability is expected early 2019. If you want to get a notification as soon as the Public Preview is available, sign up here: aka.ms/wvdpreview.

Presented 2 sessions at Microsoft Ignite 2018, Orlando

During Microsoft Ignite 2018 last week in Orlando, I had the opportunity to present 2 sessions. In this blog post I want to elaborate some more on my experiences during Ignite.

My first session was on Monday at 7PM. A challenging time slot, but a lot of people showed up, which was great! The session was called “Become an ARM hero and deploy RDS on Azure in under 30 minutes” (THR3114).

The key takeaway was providing the audience the right tools and skills to get started with automated deployments of Remote Desktop Services on Azure IaaS. With Windows Virtual Desktop being announced during the Ignite Technical Keynotes, I was also able to hook onto those announcements and explain how RDS on Azure IaaS is a great step to get prepared for Windows Virtual Desktop in the future!

After the brief introduction I performed a demo of an Azure Resource Manager (ARM) template that creates a full High Available RDS deployment in Azure. I covered how the template is built up, how to launch it and I showed the end results from an end user, as well as from an admin perspective.

The session and live demo went very well, and I received great feedback and questions afterwards from attendees. Many of them were amazed by the number of configurations and installations the ARM templates automated. The session received great feedback scores via the evaluation forms. I’m really happy with the outcome of the session!

My second session, I co-presented with Benny Tritsch on Thursday at noon. This session was called “Measuring perceived end user experience in RDS, and why you should care” (THR3089).We started the session by explaining the importance of measuring user experience by capturing and analyzing what is perceived by the user and shared a couple of real life uses cases.

In the second half of the session we performed live demo’s REX Analytics which allows you to visualize a comparison of the perceived end user experience between different scenarios. The session was very well received, and we received some great feedback scores via the evaluation forms.

I want to take this opportunity to thank everyone for attending my sessions, for the many great conversations afterwards and for providing great feedback!

During Microsoft Ignite, the book that I co-authored with Claudio Rodriguez was also being sold at the book store at Ignite. We sold a lot copies throughout the week and I signed many of them personally. It was a great honor to have our book being sold at the conference! The book is also available as eBook and hard copy via Amazon.

Besides presenting my 2 sessions and attending many others, Microsoft Ignite was mostly about connecting! It was great catching up with many of the RDS Product Team members, meeting a lot of other vendors and attendees, running into old friends and meeting new ones. I had a super great time and hope to be back in November for Ignite 2019!

Windows Virtual Desktop, RDS 2019 and Multi Session Windows 10. What a week!

I’m at Microsoft Ignite 2018 this week in Orlando. Where a lot of announcements have been made in the RDS space. Being part of the MVP Community, we have the privilege of hearing about the future steps before they are made public. Now that the news has been made public, I want to share the announcements in the RDS space in this blog post. We’re seen announcements of a new services called Windows Virtual Desktop, details on the improvements of RDS in Windows Server 2019, the official announcement of Multi Session Windows 10 and much more!

Let’s start at the beginning. The general keynote by Satya Nadella was followed up by 3 main Technical Keynotes which were running at the same time. Windows Virtual Desktop got a lot of attention as it was announces in 2 of the Technical Keynotes. During the rest of the week several overview and deep dive session followed explaining Windows Virtual Desktop in more detail.

So, what is Windows Virtual Desktop?

Windows Virtual Desktop (let’s refer to it as WVD) is a service on Azure for VDI and RDSH management. Basically, it means Microsoft is now officially entering the DaaS space with a service of their own. WVD allows you to publish Desktops and RemoteApp programs using a managed RDS backend infrastructure that is fully managed by Microsoft on Azure. This means that you literally go to the Azure Marketplace, follow a wizard and create an RDS deployment in Azure. All of the RDS infrastructure roles (Broker, Web Access, Gateway) are all being managed for you. The only Virtual Machines that are running in your Azure Subscription are the RDSH or VDI machines. That raises a couple questions, wasn’t that what RDmi was? Is WVD replacing RDmi? I’m assuming you are familiar with Remote Desktop modern infrastructure (RDmi), if not check out one of my previous articles. But, the answer is that WVD is built upon the RDmi platform. So, it includes all of the great improvements that RDmi has like Azure AD, Conditional Access, MFA, Auto scale et cetera. The big difference with RDmi technical preview is that with RDmi you would host your own RDS infrastructure services (Azure Services) in your own subscription. You would be responsible for setting up those services and keeping them running. Microsoft evolved WVD into a full service. Which means that the Azure Services for the RDS infrastructure roles are fully managed by Microsoft. As a WVD customer you basically become a customer in their multi-tenant WVD environment. This means even less management compared to what RDmi was in past, and it allows for a full scalable service. Don’t get distracted by the name WVD, it does allow you to publish Full Desktops as well as RemoteApp applications. A major feature is also that this is not limited to publishing Windows Server 2016 or Windows 10. WVD allows you to publish a combination of Applications and Desktops coming from Windows 7 and up, and Windows Server 2012R2 and up! So, what about licensing? If you already have Microsoft365 E3/E5 or Windows E3/E5, the service is included! This means you will only be paying additionally for the IaaS costs of the RDSH / VDI machines. This licensing step is a great move by Microsoft! The timeline for WVD is that it will reach Public Preview later this year and General Availability will be in early 2019!

Multi Session Windows 10

This was the second big announcement, a multi session version of Windows 10! As MVP’s we were informed about this step a while back, and there was a rumor going on, on social media, but the news is now official. Microsoft is working on a multi session version of Windows 10. This is a major step in this space. This means the operating system om the client side and the one used to publish applications and desktops in Azure is identical. This means images can be shared between the two, and application support will be much better. Multi Session Windows 10 is not a separate product, it is part of Windows Virtual Desktop. This means that, at least for now, Multi Session Windows 10 can only be running in Azure. It also means Semi-annual updates are being available, which allows you to keep updating and a much faster pace. Furthermore, this step also introduces support for Modern Apps like Edge, Cortana and Microsoft Store. Besides all of this, Microsoft is also heavily investing in optimizing for Office 365 ProPlus. More details in that later!

Remote Desktop Services 2019

To be very clear, Windows Virtual Desktop is not replacing current RDS deployments based on IaaS. In fact, that are a series of improvements announced for Remote Desktop Services based on Windows Server 2019.

- RD Licensing can now update per-user licenses without direct contact to AD.

- A Licensing program rolling out for Cloud Solution Providers (CSP) is now available

- RD Licensing now supports true HA based on an SQL Database

- RDS Certificates can now be stored in Azure keyvault

- Discrete Device Assignment is improved a lot and as a results RemoteFX vGPU is being deprecated

- Video playback has been improved

- High-level redirection of built-in or attached video camera

- New perfmon counters are introduced to troubleshoot applications performance

With Windows Server 2019 being General Available and Windows Virtual Desktop being in public preview soon, we now have 2 ways of dealing with Remote Desktop Services. When do you use which version? Below is Microsoft’s message on this

Windows Virtual Desktop ideal if you want…

- Microsoft to manage the brokering infrastructure as a services

- Windows 10 Enterprise multi-session capabilities
Windows 7 Extended Security Updates

RDS 2019 ideal if you want…

- full end-to-end control of the desktop virtualization environment

- a private, isolated environment

- to extend current deployments

Consider this blog post a first quick overview of all that’s announced at Microsoft Ignite. As soon as I’ve had a change to test drive Windows Virtual Desktop, Multi Session Windows 10 and RDS 2019. I will create and publish more in depth articles covering my experiences.

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/

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…”

“…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…”

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

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.

Microsoft 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:

• Tricerat: http://www.tricerat.com
• Devolutions: http://www.devolutions.net
• ControlUp: http://www.controlup.com

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/

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

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

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

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.