Not quite a 'who done it' murder mystery, more why does this keep happening?'. I've been working within an Azure environment lately and one of the issues I have encountered was logging into an Azure Virtual Desktop (AVD) session only to find that all my installed apps and tools had mysteriously disappeared. I'd assumed that once I'd gotten all my tooling in place I was good to go for the remainder of my testing time, however that wasn't to be the case.
Why do applications vanish?
The cause often lies in the way the environment is designed, not user error as I had incorrectly assumed. After some research, I found that there is a number reasons why my tooling had disappeared between AVD sessions. These are:
Ephemeral OS disks:
Some AVDs are configured with ephemeral OS disks. These disks are recreated from the base image whenever the VM is redeployed or restarted. Any software installed after deployment will not persist. This means the next time you log in, it’s like nothing was ever installed.
Pooled session hosts:
In a pooled AVD environment, you may not log into the same session host each time. You might install an app while on Host A, but when you reconnect, you end up on Host B, where that application doesn’t exist. Unless the application is baked into the master image, the software will not persist.
Reset or rebuild policies:
Some organisations configure their AVDs to automatically reset hosts to a clean state at logoff or reboot. Great for ensuring consistency and security, but rubbish if you've already installed and licensed a heap of software as the session is wiped at the next reset.
The solution:
Just use a standard VM within the enviroment. Deploying a standard Azure Windows VM and then allow access via RDP. With this approach, you can install the required applications or tools and then they will persist across sessions as the VM behaves like a traditional machine rather than an ephemeral pooled session host. This makes it easier to manage specific user needs without the complexity of rebuilding AVD images. However, the trade-off is that this adds an extra cost to the subscription and then you need to ensure that you keep on top of patching and maintenance. can rise quickly if many users require dedicated VMs, and there is added administrative overhead for patching and ongoing maintenance.
Next time your going to be spending a lot of time testing in an Azure based environment, insist on the VM route, otherwise your in for a lot of frustration a world of pain.
