Change Management in VDI is crucial

In a VDI environment, change management is crucial. You want to be able to sufficiently test your changes before putting them into production. Especially since any change could potentially break some part of your environment. Think of possible compatibility issues between installed applications or other problems that potentially flood the helpdesk with questions. That is why you want to follow processes to implement changes. Every task someone undertakes goes through one step of the process.

What about changes you can’t control?

Your Azure Virtual Desktop (AVD) environment runs on Azure, a cloud infrastructure managed and maintained by Microsoft. You can’t control when and why they make changes. These changes may be security updates, or the introduction of new features, or others such as bug fixes. Microsoft regularly makes such updates without your prior knowledge. As we all know from experience, any change carries a risk, you want to avoid them destroying your production environment. That’s why they added the switch for “Validation Environment” to the host pools (A boolean that you can turn on or off). Microsoft will then first apply their changes to the “Validation Pool(s)” before they go into production.

How does this work?

The idea is to create a small host pool configured as Validation Pool. This validation pool is as close as possible to your production pool in terms of configuration and setup. The users who work daily on the validation pool are a small representation of the company, not (just) IT staff. They go about their normal duties and if they encounter any issues, it is checked to see if those issues are related to recent changes. In this way, potential problems can be solved before they go into production.
I would also use this validation pool for changes made by the company itself. Each image or application update is then first applied to the validation pool before it goes into production.

Problems with transparency

To my knowledge, there is no transparency from Microsoft about when these updates happen, what kind of updates they are, or how much time elapses between updating the validation pool and the production pool. But if you see a problem that only occurs in the validation pool and you can’t fix it yourself, it’s a good idea to contact Microsoft.


Always create a test and a production host pool, keep them almost identical, set the test pool as “Validation Environment” and make all changes in your Test Pool first. And of course, make sure that users actually use that test pool.