Testing Azure/WVD Compatibility, Performance and Availability with Login Enterprise

September 3, 2020

You may be asking yourself:

“How many sessions can I get on my Azure/WVD host pool?”
“Will the latest Windows 10 image in Azure support my line of business applications?”
“What is the experience like for my remote users connecting to my Azure/WVD host pool?”

Lately, I’ve been doing a bunch of performance testing with Windows 10 Enterprise multi-session, which is a prevalent image to use in Azure Virtual Desktop (formerly Windows Virtual Desktop). I’ve been able to discover performance scalability for knowledge workers using a variety of M365 apps and other popular productivity apps. This helps any organization to understand how many instances they may need to support their user population without over/under provisioning this pay-per-use model. I’ve also been able to compare the performance and scalability of these Azure instances to help me understand how many sessions per virtual core I might get.

Questions you may find yourself asking about Azure/WVD Compatibility, Performance and Availability

There are also a couple other features in Login Enterprise I’ve been using a lot of lately, and those are the image compatibility tests and continuous testing. Image compatibility testing runs through a workflow one time to determine if the apps in that image still run, and run as expected. The continuous testing helps me to determine how fast my instances run when connected from outside Azure and also helps in resolving any issues with availability or WAN performance.

When testing Azure Virtual Desktop (AVD), I have two basic ways that I will conduct my pre-production and production testing.

1. First, the pre-production testing includes compatibility testing and load testing, which will happen on an internal virtual network configuration.

Pre-production testing and configuration

2. Continuous testing is something I test once my image is deployed into production, and connects publicly from a Login Enterprise launcher somewhere on the world-wide-web, to the multi-session host in AVD.

Production testing configuration

Testing Setup in General

Whether pre-production or production testing, some things are the same between the two.

1. The virtual appliance can be installed into your Azure resource group: here’s how.
2. The applications used for both are the same
3. The tests are mainly setup the same including hosts and application workflows

The most significant difference between pre-production and production testing is the launchers and connectors.

For pre-production, the launchers reside in the private virtual network and connect to the session host using the Microsoft RDP connector. Sometimes you may need to open up the network security group for internal RDP.

For production testing, the launcher will be located somewhere publicly, outside of the Azure domain. To set up this launcher we choose a custom connection and use the AVD connector. The AVD Connector is currently in beta and allows the launcher to launch a session using Microsoft’s Remote Desktop Client to establish a connection to resources in AVD.

Pre-production Testing

The first two steps to making sure my Win 10 hosts are ready for production is to do an image compatibility test and then a load test.

The compatibility test will tell me if a recent update has caused any issues with my locally installed or web-based applications. Several things can change in an image that you might want to test compatibility for, so running this test regularly and comparing your tests before and after the updates can help you resolve any issues that may manifest in production.

The load test, like the compatibility test, will tell me how much a recent update to my image might lose or gain performance and scalability. If the image update uses more CPU, Memory, or Storage, then you will get fewer sessions per server instance. Being able to compare these new tests against your gold-image baseline performance can go a long way at knowing when to allocate more compute instances to support your host pool. Conversely, if optimizations save you a great deal of compute and storage performance, then you might be able to reduce the cost and size of your host pool.

One of the biggest reasons why I confine my test environment to the private network in Azure is to eliminate any variables that might distract me from finding the true compatibility and scalability of my solution. Because the WAN, brokering, connection protocols, etc., can have an impact on user experience, it is essential to first understand what the solution is fully capable of before introducing any other layers in the technology stack. Once I am sure that my compatibility is on-point and my performance is well-tuned, then I can try connecting from a public location. Another reason for keeping pre-production testing confined to an internal network is because scalability testing requires a lot of sessions, and it is much easier and accurate to do this using an internal network.

Production testing

Once you are confident you have your AVD solution fully compatible and fully tuned for performance, you are now ready to continuously test the solution for any changes in availability or performance. The testing is critical because the virtual users and their sessions act as a real-time monitor and can alert you to the slightest changes in performance or availability before the real human users feel the difference. This can also help to monitor your solution when users are typically offline since these continuous tests occur 24x7x365.

When continuously testing, you only need 1 or 2 users per geographic region. The testing gives you insight into the user experience globally while not putting too many users on the system in such a way that they create a load or burden on your AVD host pool or session brokers.

I hope this quick review of testing has been useful and that it makes sense. If you have any questions or comments about the best strategies for testing compatibility, scalability, or performance of your AVD solution, please contact us.