Last year I’ve been doing a lot of VMware Horizon Cloud and DaaS onboarding projects and implementations. In many cloud solutions, finding a good mechanism to update the Gold Images used for the desktop pools can sometimes be challenging.
In this blog I will explain how to do this in a quick, predictable and automated manner!
VMware Horizon Cloud
VMware Horizon Cloud is a cloud-based platform which delivers hosted virtual desktops and apps from anywhere to any device. The Horizon Cloud environment is hosted in the VMware Data Centers and customers can access their resources via the internet, VPN and/or MPLS connections, as if it where a branch office in their environment.
With the Horizon Cloud service, there are two options for creating Golden Images:
- A VMware image; Customers can agree in accordance with VMware which template image(s) of certain OS types VMware will make available. VMware will install the following components on these images:
- VMware DaaS Agent, VMware DaaS Health Agent and the VMware Horizon View Agent. With Horizon Cloud version 18.1 these agents are installed with a Single Installer.
- VMware Tools
- VMware OS Optimization Tool (OSOT). This tool (stand-alone executable) helps optimize Windows 7/8/10/2008/2012/2016 systems for use with VMware Horizon View, Cloud and DaaS. The optimization tool includes customizable templates to enable or disable Windows system services and features, per VMware recommendations and best practices, across multiple systems. Since most Windows system services are enabled by default, the optimization tool can be used to easily disable unnecessary services and features to improve performance.
- Your own image; Customers can create and upload their own image to a VMware FTP. Before uploading the image(s), customers need to ensure the image is properly configured. This includes the required components mentioned in option 1. Running the VMware OSOT is considered a Best Practice, but it’s not required. You can also consider this as a guidance to help optimize the OS. After the image installation is complete, customers need to export their image as OVF file before transfer it to a VMware FTP.
Whatever option you take with creating the Golden Image; what’s the best way to maintain and update these images? A few options are listed below.
Please note: The options describe how to update and maintain images for non-persistent (stateless) VDI and RDSH farms. Persistent (stateful) desktops are managed differently, meaning you’ll have to make sure the changes are done on every VM by using a Deployment Tool, much like traditional FAT clients are managed. Another option is to move or delete the existing VM’s and enroll new VM’s which are based on the newly created Golden Image.
Option 1: Manual updates
Customers can decide to just edit the current image and perform manually the updates you need, for example download the latest Windows Updates and install or upgrade applications. Horizon Cloud customers who run version 18.1, can use the duplicate function to duplicate their image to a new version, wether this is an instant clone or traditional clone.
Customers which have previous version of Horizon Cloud 18.1, can only duplicate instant clone images. Traditional clone images need to be revered to a desktop before making modifications.
Once the duplication or reverting to desktop process is complete, you can connect to the VM and make your modifications. You can either do this via RDP from the local network, or open Console Access from the Horizon Admin portal or Helpdesk portal. When the maintenance is complete, you can logoff and convert this VM to an new image and update the desktop pool or RDSH farm(s).
Whilst this is a very fast way to update your image; For production environments, I always recommend customers to only use this update process for ad-hoc security updates. Updates which need to be installed as soon as possible, to mitigate security risks.
In all other cases, the recommendation is to not use manual updates. Manual steps are a basis for human errors, high labor costs and always result in higher number of incidents from your customer after an update cycle.
If you manual update your image every update cycle, you might end up with an image that’s not working for you anymore.
In the below illustration you see a manual updated image. In the second version there is an application error which is not noticed immediately. In the third and fourth images other applications show errors. It is now much more difficult the understand where the problem is originating from, this results in more troubleshooting time. You will have to edit or duplicate an image in order to solve the problem.
Option 2: Upload new image
Another option to update your Golden Image in the Cloud is to create a new image on-premise. When the installation is complete, convert this to an OVF file and upload the image to the VMware FTP. Repeat these steps with every update cycle.
As you can imagine, this involves some manual work as well and can be time consuming. In addition, you are depended of VMware with every update cycle; you will need to create a new GSS ticket each and every time.
Option 3: Golden Image desktop pool
Best practice is to have a day-zero image of the operating system. The first image version you create. This image is also called a Vanilla Image. The Vanilla Image is nothing more than a next-next-finish-reboot image, with only the required agents installed and eventually with some Windows Updates slipstreamed into it. No applications or customer specific components are installed.
Convert this Vanilla Image to a Golden Image. Next, you create a Golden Image desktop pool with a persistent desktop type. Assign the desktop pool with the created Golden (vanilla) Image.
Configure this desktop pool to create VM’s in a “Staging OU” in Active Directory. For creating new Golden Images, it’s always a good practice is to create a Staging OU. This is an OU which has the setting “Block Inheritance”, which means there are no other Active Directory Group Policies applied. This ensures we are installing a clean image with no additional settings other administrators might have set on parent OU’s.
After the configuration is complete, we expand the newly created desktop pool by one.
The new VM will now be created.
This is an important step: Make sure your Deployment Tool picks up the newly created VM automatically – for example using a startup script in GPO – so this installs the customer applications, applies tuning best practices and the latest Windows Updates. Some examples of deployment tools are: Microsoft MDT, SCCM, LoginAM or Ivanti (RES) AM.
After the installation is complete; convert this VM to a new Gold Image.
This image can now be used in desktop or RDSH farms presented to the end-users.
The following illustration shows the complete procedure:
To sum up, the steps that are involved are:
- Use an image that’s made available by VMware, or create an on-premise vanilla image and upload this to the VMware FTP.
- Convert this vanilla image to a Gold Image
- Create a Gold Image (Persistent!) desktop pool
- Increase the pool size by 1. This enrolls a dedicated desktop in the Gold Image desktop pool and Staging OU.
- Let a Deployment Tool of choice automatically pick up the newly created VM.
- Install and configure Windows Updates, applications and tuning best practices to the newly created VM, using the Deployment Tool in the previous step.
- After installation is complete, convert the VM to a new Golden Image
- Update/Refresh the non-persistent desktop pools or RDSH farms with the newly created Golden Image
- Repeat steps 2-8 with every update cycle.
The preferred update method described is used for the predictability, stability and consistent way of creating images. In the begin process it takes more time to setup, but there are many advantages except predictability and stability. For example, if you set it up correctly, you do not need to have access to Deployment Tools for updating the image, nor do you need a 3rd party Cloud Provider to activate the image. All management is done within the Horizon Cloud Admin portal, which means this update process can be done by any other IT staff members as well.