Azure Windows Virtual Desktop service provided by Microsoft offers application virtualization services. Note that most of the management of WVD needs to be done using PowerShell modules. Microsoft Azure Portal does not provide a management pane that could be used to perform WVD-related tasks such as logging off users, adding users, forcefully logging off users, removing users, and so on. Azure Portal also does not provide a way to configure a policy that could be used to reduce infrastructure costs by turning off session hosts based on the load. I have seen many organizations that have implemented WVD forget to build a strategy to reduce the Azure Windows Virtual Desktop infrastructure cost. This is where this article comes in handy. We will provide insights for organizations looking for a solution that could be used to implement auto-scaling to turn on/off VMs based on some conditions.
General implementation of Azure Windows Virtual Desktop
In a general implementation of Azure Windows Virtual Desktop, the WVD admin will add required components such as creating host pools, implementing session hosts in the Azure Windows Virtual Desktop tenant, and so on. For example, if you have 3,000 users who intend to use the WVD solution, you will deploy 187 session hosts provided the maximum session hosts connection limit considered is 16 connections per session host (3,000/16=187). The 16 connections per session host depends on the resources allocated to session host virtual machines. However, if you plan to deploy B-Series virtual machines for session hosts, the maximum connection limit per-session host should not be considered more than 16 connections per-session host. During your sizing of the WVD environment, you must pay attention to the below factors:
- The number of users using the Azure Windows Virtual Desktop solution.
- Size of the Azure Virtual Machine deployed for session hosts.
Session hosts needed vs. extra hosts on
What I have seen that most of the Azure Windows Virtual Desktop admins keep all the session hosts on during the business hours, which in turn, leads to extra cost for Azure Virtual Machines. The idea behind keeping all session hosts turned on during business hours is, of course, to avoid any downtime for the business applications. While your objective is to ensure there is no interruption to the WVD users, we also need to keep in mind that not all the session hosts will be utilized during each hour and not all users will be active in each hour.
Let’s assume you plan to keep all session hosts running from 5 a.m. through 11 p.m. and you want to ensure session hosts are available from 5 a.m. through 11 p.m. to serve any client requests coming in, but not necessarily all of your employees will connect at 5 a.m. Some users might connect at 6 a.m., some at 7 a.m., and then you might see more users connecting from 8 a.m. onwards. So, if only 100 users are connecting to WVD solution from 5 a.m. through 8 a.m. while all session hosts are on it is a waste of money. You simply do not want to have all session hosts running throughout the day. Before you can start reducing the cost for extra session hosts, you need to consider these points:
- You need to find a way to figure out how many hosts are needed in each hour by looking at the number of active users.
- You need to find a way to get average connections in each hour.
- You need to get an idea of how many users remain connected in each hour and if there are any disconnected users in the same hour.
Armed with this information, you can look for an auto-scaling solution for WVD that can help you configure the required parameters. For example, you may not want to force log off users if your auto-scaling strategy does not say to do so. Similarly, you may want to configure the maximum connections per host.
Auto-scaling and Azure Windows Virtual Desktop environment
Note that Microsoft does not provide a custom WVD auto-scaling solution that could be used to turn on or off hosts based on the load. I have also seen that some of the auto-scaling solutions available in the market do not work as expected and cause interruption to the Azure Windows Virtual Desktop service. Some of the auto-scaling solutions forcefully log off users. For example, if there is only one user connected to a session host, the auto-scaling solution can kick that user out and turn off the host. When considering an auto-scaling solution, you need to consider the following points:
- Does the solution provide a way to configure policies for selected session hosts? For example, you may want to turn on auto-scaling for selected session hosts before you plan to implement for all WVD session hosts.
- Can the solution be used to configure the user logoff option and allow you to disconnect the user before turning off the session hosts?
- Can the solution run in audit mode for a few weeks to see what all actions will be taken based on the auto-scaling conditions you define?
- Does the solution provide a way to send emails to Azure WVD admins at different levels? For example, send a warning email when hosts average connections cross 12 and a critical email when hosts connections cross 16 or more.
Important: I have seen some of the auto-scaling solutions considering session hosts CPU utilization before triggering actions for auto-scaling. In my opinion, it is a bad idea to consider session hosts CPU utilization for auto-scaling. Why? Because a user might have an application running inside the session host that might be causing CPU spikes.
In a nutshell, the solution should be flexible enough to configure all the Azure WVD-related auto-scaling options so organizations can configure auto-scaling based on their requirements.
To get the active number of users for each hour, we can either execute PowerShell commands or use Wintellisys WVD Manager. The PowerShell commands below should execute as part of a PowerShell job or Windows Task Scheduler so data is collected every hour and stored in a CSV file for charting purposes.
Import-Module -Name "C:\Program Files (x86)\WindowsPowerShell\Modules\Microsoft.RDInfra.RDPowershell\1.0.1804.0\Microsoft.RDInfra.RDPowershell.PSD1" $TenantID = $GlobalTenantID $UserName = $GlobalUserName $PassNow = $GLobalPassword $HourlyData = “C:\Temp\HourlyData.CSV” $TenantName = “TechGenix” $PoolName = “TechGenixPool” $password = ConvertTo-SecureString $PassNow -AsPlainText -Force $Cred = New-Object Management.Automation.PSCredential ($Username, $password) Add-RdsAccount -DeploymentUrl "https://rdbroker.wvd.microsoft.com" -ServicePrincipal -AadTenantId $TenantID -Credential $Cred $Count = Get-RdsUserSession -TenantName $TenantName -HostPoolName $PoolName $ThisHour = (Get-Date).Hour $STR = $ThisHour+","+$Count.Count.ToString() Add-Content $HourlyData $STR
In the above PowerShell script, which is taken from Wintellisys WVD Manager, you need to be making some changes as listed below:
- Specify the Azure WVD tenant ID, username, and password for the service principal that will be used to connect to WVD.
- Change the Azure WVD tenant name and pool name in $TenantName and $PoolName variables respectively.
- Change the location of the CSV file where the data will be stored.
- Configure the PowerShell script to run every hour by using a PowerShell job or Windows Task Scheduler.
Another way to get above data is to use the Wintellisys WVD Manager, which can provide a number of active users per hour and help you keep the historical data as you can see in the screenshot below:
Wintellisys WVD Manager ships with a built-in cost analyzer that can help you understand how many hosts are needed vs. how many hosts are on during each hour as it depicts in the screenshot below:
As you can see in the chart above, it shows the number of hosts needed and the number of hosts that were on in each hour. It clearly indicates that there were too many session hosts on during 4 a.m. while only a few hosts were needed to serve the Azure WVD client requests.
To help you save cost and to ensure only the required number of session hosts are available, you can design a PowerShell script that looks for the average number of sessions per host, the number of active users in each hour, and a logic whether to turn off or on session hosts. Designing auto-scaling is a tricky part, specifically for WVD solutions. Wintellisys WVD Manager provides a policy manager that can be utilized to configure auto-scaling options as it shows in the screenshot below:
As you can see in the screenshot above, you can configure an auto-scaling policy in either active mode or audit mode and various scale-out and scale-in conditions to help you configure auto-scaling based on your requirements. “VMs in Policy” shows the virtual machines that are part of the policy. The policy will only execute for VMs that are part of the current policy.
Featured image: Shutterstock