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 3rd 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.

Monday, October 1, 2018

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!

Sunday, September 30, 2018

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

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.

Monday, July 16, 2018

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 1st release out there now!

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

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 3rd party Application Launchers. You can vote for this feature here

Friday, July 13, 2018

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.

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:

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.

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 AzureFirewallSubnetotherwise 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 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!

Friday, July 6, 2018

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 clientUpdate the PowerShell moduleClose/re-open the PowerShell windowInstall the new version of the clientadding 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:

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!

Monday, July 2, 2018

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!