Deploy Horizon Cloud on Azure – Part 4: Deploy Windows 10 Multi-Session Host Image
Quick Links
Part 1 – Azure Environment Preparation
Part 2 – Deploy Horizon Cloud Infrastructure
Part 3 – Configure General Settings
Part 4 – Deploy Windows 10 Multi-Session Host Image – (This Post)
Background
Previously we have configured Azure, Deployed a Horizon Cloud pod, and Integrated with Active Directory. But now for the main amazeballs, deploying Windows 10 multi-session hosts with Horizon \o/.
So what is a Windows 10 Multi-Session host I hear you ask? Let’s see what Microsoft has to say on the matter.
Windows 10 Enterprise multi-session, formerly known as Windows 10 Enterprise for Virtual Desktops (EVD), is a new Remote Desktop Session Host that allows multiple concurrent interactive sessions. Previously, only Windows Server could do this. This capability gives users a familiar Windows 10 experience while IT can benefit from the cost advantages of multi-session and use existing per-user Windows licensing instead of RDS Client Access Licenses (CALs)
Oooof, so what does that mean for us? It means we can enjoy the full Windows 10 desktop experience whilst offering user to server consolidation ratios that you could only expect to find when using a Remote Desktop Session Host.
Why is that good? It means that you can accommodate many users on a single Windows 10 virtual machine. As public cloud virtual machine consumption tends to be based on the amount of memory, disk, and CPU consumed, it means we can lower the operational expenditure for virtual machines whilst still offering a great Windows 10 experience.
Look at it this way, in a traditional on-premises Horizon View deployment, you would typically deploy 1 desktop to 1 user. Forget about floating or assigned desktops, that is typically the ratio, 1:1. If you replicate this setup in the public cloud, that is going to be 1 desktop to every user, which is not cheap.
Out of the box, the default settings for a Windows 10 multi-session host used by Horizon Cloud on Azure, is 20 users to 1 desktop, or 20:1. I will let you do the maths :).
Configuration
There are a few distinct steps involved to make this a reality. If you have administered Horizon View before, this will all seem familiar. The config options are presented in a slightly different way.
Create a Windows 10 VM.
In this step, we will create a new Windows 10 Multi-session host and deploy applications to it before sealing it and making it the gold image.
Click on add to import a new VM.
Here we can see there are a few different options for OS, they are what is available from the Azure market place. I believe you can import your own image here as well, but this just makes it way easier to use a pre-canned desktop OS and is the only way to choose a multi-session host image.
Notice you can domain join the base image and even include a GPU if the Azure region supports it. The option to optimise the image is to let Horizon do all the heavy lifting of installing the required agents and changing settings in the OS to make it more streamlined for VDI use. Just think of the time and hassle it would take to do this in an on-prem environment. Install an Nvidia GRID card, run all the optimisations manually etc.
Give the base image a name. This is the name that will show up in Azure. Also, make note of the user credentials you define here.
If we take a look at the advanced options, we can see a lot of the settings that would typically set during Horizon and VMware tools agent installations.
And once the VM is imported, we can see it deployed into Azure. It is from here that we can update the base image by installing additional applications, etc.
Updating the VM
Let’s log into the VM using the Bastion service.
It is a pretty standard VM.
I installed Visual Studio Code and updated to the latest version of Edge browser. Also note some of the Horizon tools have started to install.
One thing that tripped me up with this is that because this is kinda acting as an RDSH host, rather than a traditional Windows 10 desktop, I also needed to define the remote desktop users in the base VM.
Once done, log out of the VM, but leave it turned on.
Creating the gold image
Click on new image.
Choose the VM we configured previously. YOu may have to wait a moment for the agent status to update.
Define the company name that will appear within the OS and change the time zone to a preferred time zone.
Define the admin credentials for the gold image and click publish.
If we take a look at the Images section in the Horizon control panel, we can now see that the image creation is in process. This will create an Azure image based from the VM we created earlier.
Create a desktop farm
Click to create a new desktop farm.
In step 1, define a friendly name for the new farm and provide a description.
Step 2, choose a VM naming convention that makes sense to you. This is what the VM will be called when it joins active directory.
Step 3, choose the appropriate Horizon pod.
Step 4, notice you can choose different VM size types.
These can be limited from the VM Types and Sizes settings if you wish, otherwise, all VM size types are available.
Step 1, define the protocol and client type. Blast Extreme is preferred but PCoI and RDP are options as well
Step 2, choose to join the domain to enable seamless user login
Step 3, set the upper and lower limits of how many session hosts should be available.
Define the max sessions per VM. This is the max number of users that connect to one session host before all sessions are handed to the next host.
Tick that you have a valid Win 10 license. If you are licensed for M365 E3 or up, Win 10 Enterprise, or have VDA licenses on CSP with an appropriate Windows 10 pro device, you should be covered.
If we take a look at the advanced properties, we can change the OU that the VM’s will end up in once they domain join and we can also define customer Azure resource tags.
We can define how often a VM should reboot or be reprovisioned from the management settings. This can be changed to reprovision on log off if you like.
Define power optimisations for the VM as well as user session lifetime. Below are the defaults.
The power management feature is something I really like. It allows you to take full advantage of only providing resources when they are needed, in an automated way. So imagine your working day is Monday to Friday 09:00 – 17:00, you likely do not want the desktops powered on, costing money, outside of these others.
I defined my schedule below. The least restrive policy wins. So all f the time, keep all VM’s powered down, except between 09:00 – 17:00, Monday to Friday when I want at least 1 desktop available. This can be set to always off if you wish, then the desktops will power on when a user tries to connect. The disadvantage is the user has to wait about 10 minutes for the desktop to boot.
Then we come to the load balancing. This again is another nice feature. You can define when the VM is too busy to accept new workloads rather than waiting until it has reached 100% saturation. In this case, if the CPU or Memory is at 90%, new user sessions will be directed to the next available desktop.
Review the summary and click submit.
We can see the 3 VM’s deployed in Azure.
Creating a desktop assignment
We have our desktops available, now all we need to do is grant our users access to them.
Click create new desktop assignment
Choose session, remember these multi-session hosts act like an RDSH server rather than a Windows 10 desktop.
Step 1, choose the pod and farm.
Step 2, define a friendly name the users will see when they log in.
Add the user group defined in AD that contains the user accounts that should have access to Horizon.
Review and click submit.
Then we can check ur assignment looks ok.
Logging in
Browse to your Broker address and enter your Active Directory credentials.
Click on the provisioned desktop resource.
When I launched the desktop, it was during a period of time when I had defined that the desktops should be powered down with the power management policies. This message greats you until the desktop has powered on.
We can see the desktop is updating and launching from within Azure.
And you are done! Note the additional application we installed in the base image is available for all users.
Conclusion
I hope you found this blog series insightful and useful.
For me what I enjoyed was the simplicity of the deployment as well as understanding how we can save costs along the way. If you compare this to traditional on-premises infrastructure, you may be surprised at how close the cost differential is when you consider hardware CAPEX, hosting costs, licensing, etc.
Further Reading
Part 1 – Azure Environment Preparation
Part 2 – Deploy Horizon Cloud Infrastructure
Part 3 – Configure General Settings
Part 4 – Deploy Windows 10 Multi-Session Host Image – (This Post)