Traditionally desktop or app virtualization specialists have been creating a standardized golden image for the virtualization environment. It has been a normal way and almost no one has challenged it. BUT NOW! Welcome to my world. One day me and my colleagues thought, why on earth we are creating the golden image for Windows Virtual Desktop solution? Couple of iterations and no, we didn’t have the answer, so we tried to do it another way and this post is all about it.
Magical golden image
In traditional approach we install the operating system from media. Then applications to the golden image itself. When finished, we prepare the image and copy it again, again and again. We get same type of images whenever we want. Great!
Golden image with Image-as-code
If we bring this traditional approach to the year 2020, we will use Image-as-code to create the golden image. We describe source image, application installation parameters etc. and Azure Image Builder, Hashicorp Packer or similar tool is doing it’s job and we have a thick golden image for use. Then we use it to create hosts. Brilliant!
When we get new monthly updates, we can re-run the image packing process with a new image and we have an updated golden image to use for new hosts or we can replace the old hosts with the new image. Great! Except… If there is something stored locally or if there are personal host pools with workstations that cannot be re-provisioned. We have to update those.
Vanilla image with configuration management tool
Magical golden image provides a static version of VDI base image and you have to update the code every time, you change something in it. BUT, as we are normally managing also other workstations with MEMCM or MEM, we have applications already in configuration management tool for deployment. Could we use always the standard vanilla image from Azure Marketplace to provision the host pool and automate application installation to those?
If we update some software to physical workstations, we can do the same for existing and new Windows Virtual Desktop hosts. We will manage updates same way as for standard physical workstations. At the end Windows Virtual Desktop hosts are only workstations as normal laptops or desktops (yes, Microsoft thinks Win10 Multi-Session is server, but still you can follow the workstation pricipe).
When you are using this option, you must have time for provisioning. After new host is created to the host pool, it’s not ready before MEM or MEMCM has run application deployment etc. This takes time from couple of hours to twelve hours depending of application sizes etc. So be ready to use drain mode to the host before everything is ready. On the other hand, you don’t need to maintain repository, static custom image, shared image gallery, pipelines, specialized customizations for Azure Image Builder or Hashicorp packer. Here is something to think about…
Production team support
Another way to think why this way is the support. Mostly workstation production teams has more knowledge about MEMCM or MEM than code-based implementations. It is much more easier for them to handle all workstations same way with the same tool.
Managing infrastructure with a code is modern and hype currently in 2020 that’s true, but what is the real advantage of it at the end or is there any in this case?
Conclusion
Both way works.
If you use Image-as-code method, you will get images up and running immediately after provisioning those, but you have to maintain IaC and have knowledge to it.
If you can wait less than a day after deploying the VM before giving it for end user, you save a lot of time in the maintaining. Using MEMCM or MEM to deploy applications takes time to complete, but in most cases this time does not matter. You can scale hosts out and in to have more resources if you have prepared for it. You are not paying any extra for compute that are not running in Azure (you pay only for disks and price point isn’t high).
Think before implementing Windows Virtual Desktop: Why, how and with what tools. Happy virtualizations 😉
0 Comments