You have probably heard the news via various social channels, the Public Preview for Microsoft Teams A/V Redirection and media optimizations is here!
This will create a direct path between your users when sharing video, significantly improving the video and audio and overall user experience when using Audio & Video within Microsoft Teams.
Many have been waiting for this next step because is takes the overall Office 365 Experience, which was already significantly improved with the acquisition of FSLogix, to the next level! Users can now participate in Teams Meetings right from their WVD Desktop and have a smooth experience! A very welcome update, specially during the COVID-19 situation we’re still in.
Of course I had to test drive this functionality in our WVD.Ninja lab environment! Setting it up is actually quite easy! I’ve drafted out the installation steps below.
(1) Prepare your image for Teams
Before installing Microsoft Team, set the following registry key on the host using GPO Registry Preferences, other 3rd party tools you might already use, or add it to your custom template image. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Teams, IsWVDEnvironment, DWORD, 1
(2) Install the Teams WebSocket Service
Download and install the WebSocket Service. No specific install options are required.
(3) Install Microsoft Teams with per-machine option
Download the Teams MSI package that matches your environment. It is recommend to use the 64-bit installer on a 64-bit operating system. Make sure you use the option ALLUSER=1.
(4) Verify both installs
Verify that both installs were performed correctly. It should show up as shown below.
Now open Microsoft Teams, logon, go to About and click on version. Your Teams client should now show “You have Microsoft Teams Version 1.3.00.4461 (64-bit). WVD Media Optimized.”
And as you can see I have my local devices available & ready inside WVD to jump into a Microsoft Teams call with optimized Audio/Video support! A couple of quick tests show a great experience, I will test drive some more over the coming week.
Igel has released a new (private preview) version of Igel OS which supports Windows Virtual Desktop Spring 2020 update!
This release of Igel OS now supports both the Fall 2019 as well as Spring 2020 Update feeds. The client enumerates both feeds and shows them in one single overview. The screenshot below shows the resources coming from Spring 2020 Update webfeed. Both RemoteApps and Desktops are available coming from 2 different Workspaces.
In this release they also added a new cool feature. The Igel OS WVD client now shows live previews of sessions! The screenshot below shows this functionality. Here we see a live preview of a RemoteApp session as well as two different Full Desktop sessions. This allows me for super fast switching between sessions!
Even more cool, a single right-click on the published Application or Desktop does a instant user logon for that published resource without actually connecting to it in full screen. So I stay within the Igel OS WVD client and with 3 simple right-clicks I can launch resources in the above screenshot and watch the logon sequence of all three. I like it!
I shot a quick video to show this functionality in action. I used a Surface Pro with a Igel UD Pocket (UDP), a super small and portable “thin client” which allows me to USB boot any device or thin client and convert into an Igel OS device. The Igel UDP is so small that I attached a key cord to not loose it :).
And here is the Igel OS WVD spring 2020 Update client in action. It’s a quick video, not focussing on the image quality but purely to show the new functionality.
The webinar “Getting Started with Microsoft Azure” is coming up! This webinar week will take place from 2 to 5 June 2020.
“…Over the course of five days we will deliver virtual sessions on Digital Transformation, Azure Landing Zone and migration to the cloud, Modern Data Warehouse, security and Windows Virtual Desktop. These sessions will be delivered by Microsoft experts in close collaboration with our top partners…”
Wortell joins as one of the partners presenting at two of the Azure Webinars: Secure & Well-managed and Windows Virtual Desktop!
During this webinar, I will represent Wortell and talk about our vision and approach on helping you Jump Startyour Windows Virtual Desktop deployment. Sign up!
During this Webinar my colleagues Lourens Siderius and Maarten Goet will dive into the Wortell vision on a helping you achieve a secure and well-managed Azure Environment. Signup!
In my previous article I covered the use case of using Windows Virtual Desktop to publish a centralized Management Server / Jump in Azure to provide secure and easy access for administrators, applications vendors or external contractors. In that article I also briefly touched on using a PowerShell script to add a Host (weather its Windows 10 Multi User or Windows Server) to an existing WVD Host Pool. This PowerShell script is multi-purpose and can by used as part of a JSON deployment, any other automation, but also to manually add or re-add a host during troubleshooting or migration steps.
The script is no rocket science, but…
I believe this script to be a very valuable asset in an administrators WVD Toolbox. I decided to share this script publicly on GitHub for others to use it!
I’m happy to take any suggestions on improvements and proposals for new features of course using pull requests! Here is a direct download to the Github location:
The script currently takes 9 parameters which allow you to customize which existing Workspace, Host Pool and App Group to use. You also need to specify the credentials of the Service Principal account. Because of changes in the new Spring Update 2020 release of WVD, we also need to specify the azureADTenantID, resourceGroupName and azureSubscriptionID inside any az.DesktopVirtualiztion PowerShell Cmdlet. Therefor, we collect those as parameters too. And finally the scripts allows you to configure if the new hosts should be placed in Drain Mode or not and it optionally can also create the association between the Workspace and the App Group if you had not performed that before.
The actions that the script performs are:
Connect towards Azure PowerShell using the Service Principal provided.
Check if there is an existing and still valid Registration Token for the Host Pool that was provided, if so grab that one and if not, create a new one.
Download and install the WVD Agent providing it the Registration Token.
Download and install the WVD Boot Loader
Optionally set itself in Drain Mode to not allow new sessions yet
Optionally create the Workspace-AppGroup Association
Let’s talk about scenarios and use cases to leverage this script.
SCENARIO 1 : Using the script as part of a Host Pool Custom ARM Deployment creation or to add hosts to an existing Host Pool.
Windows Virtual Desktop Host Pools can be created and updated using the Azure Portal. This functionality was already there in WVD Fall 2019 Update, but became a lot more intuitive and easy to use in WVD Spring 2020 Update. As I also explained and showed in a previous article (Migrating your existing WVD Workloads to WVD Spring Update!) using a Custom ARM Template to deploy and update the WVD Hosts in your Host Pool also has advantages. Especially if you want to have granular control over what gets created using specific naming conventions for various Azure Objects.
From within a Custom ARM Template, this is how you can use the CustomScript Extension to download an execute the PowerShell script during the ARM Deployment. The parameters that are passed to the PowerShell script are collected as JSON Parameters when deploying the ARM Template. Again, besides ARM you can use the same approach in any existing automation your might already be using.
This allows me to deploy a Virtual Machine in Azure using existing ARM code I might already have and automatically add the Virtual Machine as a WVD Session Host inside a Host pool.
So, when deploying an ARM Template I allow the admin to select Workspace and Host pool information from an easy to use drop down list and pass these parameters to the PowerShell script.
The WVD step in the ARM Deployment shown below is where the PowerShell magic happens.
SCENARIO 2 : Using the script as part manually and quickly adding or re-adding a host
In some scenarios you might just want to add or re-add a WVD Host to a Host pool manually. For example;
When you are troubleshooting an issue on a host that e.g. did not successfully register or lost connectivity towards a Host pool.
If you want to move a WVD Host from one host pool to another without redeploying it.
Or, as also outlined in this article, you are manually migrating WVD Hosts from Fall 2019 towards Spring 2020 Update.
In all of those cases you can just copy the PowerShell script to that host and simply run it by providing the parameters as previously discussed.
The script provides basic logging as per the example show below. It does not do any error handling yet, something I’m looking at adding in the future.
As said, I’m happy to take any suggestions you might have on improvements and proposals for new features using pull requests on GitHub, or just reach out to me directly.
On April 28, the event Microsoft meets Community: Windows Virtual Desktop took place. This was originally planned as an in person event hosting 120 attendees. Due to COVID-19, it unfortunately had to be transformed into a virtual event. It did however, turn into a huge success! With 2236 registrations and approximately 1200 live attendees!
I had the privilege to present the topic "Dealing with application landscapes on WVD, current and future, together with Micha Wets". We had a blast presenting on WVD, MSIX app attach, FSLogix and Azure DevOps CI/CD pipelines!
Today, all content of the event has been published! Videos and slide decks of all sessions are available to everyone!
Two weeks ago, on April 30, Windows Virtual Desktop Spring Update 2020 Public Preview was released! A huge jump forward for WVD! If you missed those announcements, check out my two previously published articles:
In this article I want to highlight a different use case, using WVD to provide your (customers) administrators a secure management server accessible from anywhere using any device.
If you are running any resources in Azure, there is a good chance that one of those resources is a Management Server / Jump Host or whatever you want to name it. Such a server is used as central management for administrators to access admin tools like Active Directory Users & Computers, DNS, Group Policy, other MMC Snap ins and any other 3rd party vendor management consoles. It is also often used a single point of entry to RDP “jump” into other servers. Why is this? When organisations move resources to the Public Cloud, in this example Microsoft Azure, the first thing you need in Azure is Networking & Storage. In most cases expanding a current (on premises) Active Directory Domain (ADDS) is the next step to support Domain Services for Azure resources. Or, you might be implementing Azure Active Directory Domain Services (AADDS) or Azure Active Directory only. Having either of these services available in Azure allows you to deploy Domain Joined Application Servers, File Servers, Database Services et cetera. As you move more resources to Azure, the need for a centralized management server grows. In many cases you already have such a management server on premises or at a hosting facility. A couple of questions: How are you allowing access to that management server? Using a VPN? Published by an RDS/Citrix/VMware platform? Is it secured by Conditional Access & MFA? Can administrators access it on any device?
Why not leverage the Windows Virtual Desktop platform in stead?
Use a centralized Management Server / Jump in Azure and publish it to your administrators, applications vendors, external contractors using Windows Virtual Desktop! This allows secure access using any device from any location!
Using an RDS deployment (on premises, hosted or in the Public Cloud) you can of course achieve the same the goal. For example if you have an RDS deployment in your environment that you use to publish applications and desktops to end users, it makes perfect sense of course to re-use that platform for administrators to access a management server. But if you don’t, setting up a full RDS Deployment just for remote management only is not that cost-effective and by default it does have the security needs we require today like for example Conditional Access, enforced MFA et cetera. Sure, you could also just deploy an RD Gateway Server with an NPS Server and MFA Extension. I wrote about this back in 2017 in the article Securing RD Gateway with MFA using the new NPS Extension for Azure MFA! and I have seen a lot of organizations successfully use this approach. Also remember that using RDS requires the purchase of a RDS Client Access License. With WVD, and especially with Spring 2020 release, I believe its time to move on and start leveraging the latest technologies!
Even if you do not use the WVD platform right now, if you have the need for a secure management server in Azure, leveraging WVD makes total sense! And if you do already have WVD for other use cases, re-use it and eat you own dog food!
So, how do we get started? Deploying a WVD Workspace including Host pool and AppGroup for the purpose of publishing a Management Server is similar to deploying WVD for any other purpose. Your deployment options are as follows
Deploying using the Azure Marketplace entry in the Azure Portal. This allows you to deploy all the necessary WVD backplane components including the VM acting as the Management Server. Recently published article on Tech Community by Christiaan Brinkhoff
Using your own custom JSON template, specially useful if you are deploying the same setup in multiple environments or for multiple customers.
Deploying using 3rd party tools or community tools. For example CloudJumper(who recently became part of NetApp), Nerdio, the free community WVD Management GUI provided by Marcel Meurer, or any of the other tools available.
For the purpose of this article, we’ll go for option 2. We’ll use a JSON template that we can easily re-use in various Azure Subscriptions. If you are less familiar with JSON, a while back I published a 9-part series of articles on deploying RDS in Azure IaaS using JSON templates that is a good start to get introduced into JSON based on the RDS use case.
STEP 1 Creating the WVD backplane components
We’ll start this walkthrough with the creation of a WVD Workspace using JSON. The section below shows this code. The Object Type to deploy is called Microsoft.DesktopVirtualization/workspaces. The minimum we need to define is a name, location, friendlyname and description. We’ll leave the applicationGroupReference empty since we are creation an association later.
To make sure name of the WVD Workspace meets the overall naming convention I’m using for other Azure Objects, I define the WorkspaceName as follows.
Next, we create the Host Pool. We need a couple properties to define the friendlyname, description, hostpool type and load balancing type.
Again, to make sure we comply to a generic naming convention we define the host pool name as shown below. For the Host Pool load balancing type we select Pooled since multiple Administrators will be sharing sharing a pool of x number of Management Servers. We define the load balancing type as BreathFirst so that sessions are distributed evenly across the VM’s we publish as Management Servers as part of this host pool.
Breadth-first distributes user sessions across all available session hosts in the host pool. Depth-first load balancing distributes user sessions to an available session host with the highest number of connections which has not reached its maximum session limit threshold. More info:https://docs.microsoft.com/en-us/azure/virtual-desktop/configure-host-pool-load-balancing
Next, we define the creation of a WVD App Group. Again we define the usual properties like name, location, friendly name and description.
For the property applicationGroupType we choose “Desktop” since we are publishing a Full Desktop session towards the management server. The other option is RemoteApp which allows us to publish individual applications. For the property hostpoolarmpath we provide the resource ID of the hostpool we had create earlier. The screenshot below shows the list of variables used to give you an idea what was specified.
In my case, I have reused an existing ARM template we use to deploy a new vanilla VM to Azure inside the specified Subset and using the specified naming convention. On top of that I like to use the Domain Join Extension. This allows me to join the VM to a existing domain in the OU that I specify. More into of the extension can be found here on Github: Joins an Azure virtual machine into an AD Domain by using JsonADDomainExtension extension
In most case, you will not want to deploy a vanilla Windows Server 2019 or Windows 10 Enterprise Multi-Session VM. Instead, it’s convenient to create your own Template Image in Azure first. You can do that by deploying a new VM in Azure, Windows Server 2019 or Windows 10, and once that is complete install all the tools you want to have on the management server. For example you might want to install the RSAT tools and any other 3rd party management tools you want to allow administrators to leverage.
If you select Windows Server as your operating system for a WVD Template Image make sure you install the RD Session Host role, otherwise the WVD deployment will fail. For Windows 10 Multi-Session, this is not needed. Also, using Windows Server requires an RDS Client Access License where Windows 10 Multi-Session does not.
Once you are done customizing the VM you need to sysprep and generalize the VM and capture it to a Template Image.
Note that the actions below result in the VM object that you used to create the template image, becomes unusable. Therefor you might want to take a snapshot of backup before starting the starting Sysprep and capture process.
And finally, to create a Template Image object we capture the VM to a Template Image. To do this, select the capture option on the VM and specify a Tempate Image name and Resource Group location.
STEP 3 Have the VM add itself to the freshly WVD host pool
During step 1 we created the JSON code code create the WVD Workspace, Host Pool and AppGroup. During step 2 we talked about creating the JSON code to create a domain joined VM, optionally based on a Template Image. Its now time to bring it all together! Lets cover the most critical piece, automatically adding the freshly deployed VM to the brand new hostpool we deployed.
Of course we could go ahead and use the WVD Management options on the Azure Portal to add the new VM to the new Host Pool. In stead, lets cover how to automate that part and have the VM join request a new registration key and using that key add itself to the Host pool.
I selected ARM PowerShell extensions to perform this action. Main reason is that this allows me to re-use that same PowerShell script when expanding the Host Pool with additional servers using ARM and even leverage it as a way to (re)register VM’s as part of troubleshooting steps in the future by manually kicking of the same script.
To have the script support a variety of different use cases it accepts the following 10 parameters to define how the host adds itself to the existing host pools and what other optional configurations are performed
Next, the script authenticates using the Service Principal account and checks for existing registration info. If registration info for the Host pool exists, it grabs the corresponding token and if not, it creates a new registration info and collects that token.
Next, the scripts downloads both the WVD Agent and Bootloader and silently installs it on the WVD Session Host providing the token from the previous step.
Optionally, the WVD Host can set itself in drain mode by specifying the DrainMode parameter. For the purpose of this Management Server it’s most likely not needed, but this allows us to re-use this script to add additional WVD Host servers to a production WVD Host pool which we do not want to take in production right away. E.g. if you are rolling out a new Template Image version and want to switch over later during the evening or a different maintenance window.
And Finally, the script (optionally) associates the AppGroup with the Workspace. This is optional and particularly handy when the script was part of a full JSON Deployment in which a new Workspace and AppGroup were also created.
STEP 4 Deploying the Custom JSON Template
Let’s now take a deploying in an Azure Subscription. We perform a new custom deployment in our Subscription. and deploy it to a dedicated Resource Group.
As stated before, I’m reusing an existing JSON template we also use to deploy new vanilla VM’s in Azure. And we have added the creation of a Workspace, Host pool and AppGroup to is. We also added a new PowerShell extension to run the PowerShell Steps on the deployed VM as outlined in step 3. Below is a snippet from the JSON code to give you an idea how the PowerShell Extension is launched as part of the ARM deployment.
In order to collect a couple of parameter to pass to the PowerShell extension, we collect them as part of the JSON template. And after that we kick off the deployment…
STEP 5 Taking a look at the end result
The entire JSON template only took 11 minutes to complete! This includes the creation of the domain joined VM, all the WVD backplane components ( workspace, Host pool, AppGroup) and adding the VM to the WVD host pool!
Below is what it looks like from a Deployment overview as well as from a Resource Group overview with the created Azure objects.
The template created a WVD Workspace and performed the association with the created AppGroup.
And the Host Pool is created with the Management Server added and available as well.
Ans also, the VM was joined to the domain inside the designated OU we specified as one of the parameters.
So, we have deployed a secure and easy to access management server published via WVD and accessibly anywhere using any device in ~11 minutes! Lets see the end result!
When we log on to Windows Virtual Desktop, in this case using the Windows Client, we have the Management Server available with all the admin tools we need!
And of course we have that same management server available at our finger tips on any other OS as well using the Remote Desktop App from the various AppStores, including a Web Client based on HTML5.
To conclude: In this article we talked about using a centralized Management Server / Jump in Azure and publishing it to administrators, applications vendors and external contractors using Windows Virtual Desktop! This allows secure access for management purposes using any device from any location! Regardless if you are already using WVD for other purposes or not, I can recommend using the service to provide easy and secure access, including conditional access, to a management server without the needing a VPN.
