I authored the e-book Windows Virtual Desktop Migration Guide for Remote Desktop Services. This book takes you through a 7-step process of migrating your RDS workloads to WVD.
The e-book is published by Microsoft as a free download: https://azure.microsoft.com/en-gb/resources/windows-virtual-desktop-migration-guide-for-remote-desktop-services/
Recently Parallels announced version 18 of their Remote Application Server (RAS) product is coming soon! The release notes with added features and improvements for this version is huge! The highlights are as:
For an explanation of the full list of this release see this article: Coming Soon in Parallels RAS 18. In this article I want to focus on the Windows Virtual Desktop Integration. I remember conversations with many people of the Parallels RAS team discussing Windows Virtual Desk integration approaches based on their early mock up diagrams. I had the privilege of testing version 18 release during technical preview and it’s great to see the ideas and discussions come to life integration into their product. They did a great job! The parallels RAS product is known for it’s feature richness without the complexity, and they managed to pull that off once again with the WVD Integration!
If you’re familiar with installing Parallels RAS, the installation process of version 18 will look very similar. You do of course have to have a couple of additional requirements in place specifically for the WVD integration. Because of the integration, a couple of permissions on the Azure AD and Azure Resources side need to be in place and Parallels RAS uses an App registration for all of this. I will not cover these steps for now as they will be shared in great detail when version 18 will hit general availability.
Below is the architecture of the integration with WVD. It shows a hybrid deployment with on premises setup, however RAS can of course also be deployment entirely on Azure as well.
After the installation you will immediately notice the new Wizard in the admin console that guides you through the process of configuring WVD integration.
The first steps is to provide a location where the WVD agent and bootloader will be placed. This is because Parallels RAS will perform the installation of these components for you. Next, you provide the credentials that Parallels RAS will use to communicate with Azure, this result into a Provider object.
The next step in the wizard is creating the WVD Workspace, you’ll obviously see the same parameters compared to creating the Workspace directly in Azure.
The next step is the creation of the WVD Host pool including the properties like load balancing etc. Notice that Parallels RAS already provides the option to configure a Power On for hosts on demand, which includes pooled configurations! This means the first user to connect to a host pool causes a WVD host to Power On in case all hosts are powered off due to auto scaling.
Next we can define the Template to be used for the provisioning of WVD Hosts. We have 2 options here.
Note that if you already have existing hosts and do not need autoscaling, then you can also use Standalone (unmanaged) option instead.
The next step allows us to configure the naming convention for WVD hosts, the number of VM’s, buffers and whether the newly deployed hosts should remain powered on after deployment or turned off for later use.
The next step is to provide sizing, and networking details. The wizard presents easy to use dropdown boxes with information taken directly from your Azure Subscription.
And finally, the wizard allows us to configure image optimization settings that Parallels RAS provides out of he box, which is a great feature. It also allows us to either use Sysprep or Parallels RASprep to prepare the images.
Upon completion, Parallels RAS will create our Workspace, Host pool and App group, prepare the Image in Azure and deploy x number of WVD hosts, join them to the domain and add them to the WVD host pool. Below is a quick summary of what the result looks like in the console.
Similar to how we are used to publish applications and desktops in the Parallels console, we can also do this for WVD resources. The great thing is that we can now also mix and match resources from RDS on premises and WVD using a single console and providing these to the user using a single Parallels RAS client, which means Hybrid scenarios!
When opening the Parallels Client for Windows and logging on were a presented with the Desktop hosted in WVD.
Upon connection we leverage the WVD Client (default option) which means we get all the capabilities of the WVD Windows client.
And this release of Parallels RAS also contains a fully integrated way of configuring FSLogix including all of the advanced settings, very cool!
The RAS Console also provides great session details
And we can also interact with the session directly, including shadowing.
And finally, below you see a Hybrid scenario with Applications and Desktops coming from an RDSH farm as well as a Desktop coming from WVD, all in a single client with a single identity!
This article focussed on the WVD integration of release of Parallels RAS, the team once again did an amazing job! As said before, they provide great additional features on top of native VWD without the penalty of over complexing things. Special thanks to Christian Aquilina, Director of Program Management at Parallels for providing me tech preview access and reviewing this article. Stay tuned for Parallels RAS 18 to become Generally available and try it out for your self!
I had the privilege to test drive the integration of MSIX app attach in the Azure portal at an early stage. In this article I’ll share my early test results!
On October 16, 2019 I wrote the article MSIX app attach will fundamentally change working with application landscapes on Windows Virtual Desktop! This was based on a pre-private preview providing a sneak peek on what’s coming. Since that time I wrote several other articles covering the evolution of the technology. I covered publishing a heavy design application using MSIX app attach, I shared some scripts to transform MSIX applications into packages, and recently I published a video showing the staging and registering of seven applications inside a single MSIX app attach container. Until now, MSIX app attach was all based on PowerShell to stage and register MSIX app attach applications.
Recently Microsoft shared more details on MSIX app attach and Stefan Georgiev, Senior Program Manager on the WVD team, published a great video on the Azure Portal Integration with for MSIX app attach.
Before we get started we obviously needs MSIX app attach packages ready on a share and accessible from the Host Severs. This process is identical to way we performed that when using the PowerShell method of staging and registering, so I won’t repeat that here. Instead, let’s jump right in and take a look at the integration in the Azure Portal! Inside the Azure portal on the Host Pool blade, we now have a new option MSIX packages.
This allows us to perform the first step, staging applications to all WVD Hosts that are part of this host pool. By clicking Add we can specify the UNC path towards the MSIX app attach package (IaaS File Share, Azure Files et cetera). And after doing that the list of MSIX applications (entry points) inside that package is retrieved and presented in a dropdown box. In the example below I have seven applications inside a single package. For this step to work, the host pool obviously needs to be in a healthy state, and at least 1 WVD Host needs to be running. Adding MSIX packages to a host pool will trigger the RD Agent on a healthy WVD Host inside the pool which is randomly selected. That WVD host will then load, parse, and validate the MSIX image and the MSIX packages stored inside it.
After selecting an application we are able to complete the application details by providing the application name, display name description etc.
After completing this for a couple of example applications this looks like below.
At a five minute interval the RD Agent on each WVD Host that is part of the host pool will contact the WVD management service to check for any updates. During that time the Staging step takes place and the WVD Host will mount the MSIX app attach package. This can be confirmed by taking a look at disk manager.
In order to prevent users from using the MSIX package before it is staged on all WVD Hosts, you can set to the state “Inactive” in the Azure Portal.
Now that we have covered the staging step, let’s take a look at the registering step. For that we open the WVD App group we want to use and select Add. This allows us to specify the MSIX source package and select an application.
After completing the step for in this case 4 sample applications, that looks like below.
We can now log on with a test user who is a assigned to this application group and see the end result. Upon logon, the registering step takes place and the MSIX app attach application now appear in the session!
And here are all four applications running in my user session coming from, in this case, a single MSIX app attach container!
We covered working with MSIX app attach in the Azure Portal, but the PowerShell equivalents are of course also available to help automate the configuration. For that to work, make sure you update your Az.DesktopVirtualization to version 2.0.1. Below is an example of using Get-AzWvdMsixPackage.
In case you want to change the 5-minute interval that WVD hosts use to check for MSIX app attach updates, here is the corresponding registry location.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RDInfraAgent\MSIXAppAttach]
“PackageListCheckIntervalMinutes”=dword:00000001
The Event log also provides information about the various staging and registering steps.
Below is a nice visual representation of the MSIX staging and registering steps, as shared by Tom Hickling.
And finally, special thanks to Stefan Georgiev for providing the preview information and the ability to test drive this early! It’s super great to see huge steps MSIX app attach is taking. The integration in the Azure Portal works really well! Looking forward to adding more applications and test-driving other scenarios!
A couple of weeks ago I posted an article on my first experiences with Project ‘Bicep’. Back then, Project ‘Bicep’ was just released as an 0.1 Alpha version. In case you missed that article, follow this link.
Recently, version 0.2 was released which contains some great features as listed on the left. I was especially looking forward to the option of using Modules and Scopes and having IntelliSense and code formatting to improve the overall authoring experience.
To get started, install the latest Bicep 0.2 release using the URL below.
https://github.com/Azure/bicep/blob/main/docs/installing.md
To use bicep VS Code extension, simply install the latest extension from within VSCode. If you were using a previous version of the Code Extension you have to uninstall that version first.
We are now ready to start testing some of the new features in this 0.2 release. First of all, modules! Modules can be used to separate Bicep code, that creates a specific (set of) resources, into different files. Not only does this allow you to further simplify a single bicep file into multiple files, it also allows you to reuse code by simply calling the modules.
Creating a new bicep module is no different than creating a regular bicep file. Modules also have the .bicep extension and the same way of declaring parameters, variables and resources.
Let’s start by creating a super simple module that deploys a new Vnet and Subnet. Below is the Bicep code. If you have played with Bicep 0.1 before you’ll notice that this is no different than creating a regular bicep file. I still love how extremely simply the Bicep syntax is!
Before we start: Yes, the code snippets throughout this article are screenshots and therefor not easy to copy-paste and reuse, but I shared the entire set of all Bicep files, Bicep Modules and transpiled JSON code on Github here: Multi-module Bicep project for WVD. I’m using screenshots as this allows for easy reading and annotations.
Before Bicep 0.2 release we would build (transpile) a corresponding JSON file from the Bicep file by running the command below.
And since a Bicep Module file is no different than a regular Bicep file, we still can. We are however not going to do that. Instead we are going to call the module from another Bicep file. To call a Bicep module we use the code below. We specify the keyword ‘Module’ followed an identifier and then specifying the ‘type’ which in this case is the location of the bicep file, in this case the module that creates the Vnet and Subnet. Note that we can pass parameters to overwrite any defaults specified in the module itself. Also, the ‘name’ that we specify here is not the name of the vnet, but it is the name of the nested deployment that gets created in JSON, more on that later.
Second thing you’ll notice that we specified a scope. This is great because it allows us to specify the, in this case, resourceGroup where the resources of this module are going to be deployed. So this also allows us to call several different modules that deploy different resources into various different resource groups. This comes in very handy for larger deployments that expand a single resource group. Do make sure that you specify targetScope as ‘subscription’ inside the Bicep file from where you call your Modules.
We are now only calling a single Bicep module from another Bicep file. That of course does not really add value. Let’s step up our game and create another module. This time a module that creates a Storage Account including a file share.
Let’s start with the Storage Account and deliberately leave out a property inside resource declaration that defined the storage account. Note that the VSCode with the extension notifies us of the exact parameter that is missing. Great authoring experience! Not only when mistakenly leaving out a parameter, but throughout the creation of the resource, intellisense provides great feedback in properties to create.
Let’s now add the creation of a basic file share inside this module. Note that VSCode with the Bicep Extension allows us to easily browse through all resources including in this case all available api versions of the storage account resource.
Let’s now move forward to the test case of this blog post, creating a multi-module Bicep Project that deploys the following for us: a WVD Environment containing the following:
Let’s start by creating the main bicep file from where we will be calling the various Bicep Modules. We start by defining the parameters. Since we will be calling various Bicep Modules from within the main file, we define the parameters we need for all modules. Again, we also set the targetScope to ‘Subscription’ to allow us to create Azure objects into various different Resource Groups.
Next, we create 4 new Resource Groups and we generate the names based on the a defined prefix. We could of course also have created these 4 Resource Groups using a module, but I chose not to do so in order to show that you can combine the creation of resources with calling modules from a single main bicep file.
Let’s now call our first module. This module will create a WVD Hostpool, AppGroup and Workspace, create relationships between all objects and also configure the diagnostic information for all of the WVD objects.
In a previous article I already focussed on the creation of the WVD Objects itself, so I will not repeat that here. In order to create the Diagnostic information for the WVD Objects, obviously the WVD Objects themselves need to be created first. And the Log Analytics Workspace needs to exist too. To achieve this, I’m actually calling another module from within this module :)
Note that for the parameter logAnalyticsWorkspaceID, I’m referring to the ID of the log analytics workspace. This causes Bicep to auto-create the necessary dependency in JSON.
In fact, Bicep took care of a lot more depends on sections for us throughout the generated JSON file, we call this implicit dependencies. When authoring JSON directly, these would all have to be explicitly created.
To finish off the main bicep file we call the 2 other modules that create the network and file services components respectively.
The end result is a main bicep file with 5 Bicep module files as shown below.
When Bicep modules are transpiled into ARM template JSON, they are turned into a nested inline deployment automatically. Basically, each module equals one nested deployment regardless of the number of resources that are defined inside a single module. This means we only have to transpile the main bicep file. The build process, which only takes a second to complete, transpiles all bicep files automatically including all the module files that are used. Below is the build command I used. I did get a warning. This is a know issue with version 0.2 because extension resources like e.g. diagnosticsettings and locks are not detected in this release yet. This functionality is going to be added soon. For now we can safely ignore the warning, and the JSON is successfully created.
From within VSCode we can directly deploy the generated JSON file to Azure Resource Manager.
And here is the end result in Azure, we have 4 new Resource Groups created.
A WVD Hostpool, AppGroup and Workspace are created and the objects are connected to each other.
A Storage account with a File Share is created.
A Log Analytics Workspace is created including the diagnostic configuration of all WVD Objects.
And lastly, a Virtual Network with a Subnet is created.
This concludes my first test drive with Bicep 0.2. I must say impressed by the added features and can’t wait for new features to be added in the already planned 0.3 release!
As mentioned before, I made the Bicep files including all the Bicep modules and the transiled JSON code available on GitHub. Feel free to reuse and contribute!
