The transition from physical to virtual desktops can disrupt patch management, so it is important to revisit your patch management strategies when you deploy VDI.
The first consideration involves how you've configured your virtual desktops. Many VDI products offer administrators a choice between providing a dedicated virtual desktop to each individual user and
Patching personal vs. shared virtual desktops
The impact of a bad patch will be widely felt.
If you use personal -- or persistent -- virtual desktops (where each user is assigned their own, unique virtual desktop), then you can approach patch management in much the same way as you would in a physical desktop environment. The virtual desktop is merely a form factor, and the patch management software does not know or care about the virtualization layer.
In environments in which users share a centralized virtual desktop image (or nonpersistent desktops), patch management becomes an exercise in image management. You can't simply apply operating system patches to the virtual desktops, because the virtual desktops are intended to remain the same after the user logs in and out. Instead, patch management involves updating the shared virtual desktop image.
This increases the importance of patch testing. After all, if a patch breaks a desktop image and that image is shared by a large number of users, the impact of a bad patch will be widely felt. Administrators should test patches in a lab environment before applying them to a shared image. It is also important to retain the last few previous versions of shared images. That way, you can easily revert virtual desktops to a previous state (by putting in place an older virtual desktop image) in the event that a patch causes unanticipated problems.
Another important consideration for virtual desktop environments is application patching. Once again, if each user is assigned to a persistent virtual desktop, you can probably handle application patching much like physical desktop environments, assuming that the applications are installed directly to the virtual desktops.
Things get a little bit more interesting, however, when you bring shared virtual desktop images into the picture. Yes, patch management strategies for applications can be handled in a manner similar to that of operating-system-level patch management. However, there is one additional consideration you should take into account.
Many applications include self-updating mechanisms. Rather than rely on a centralized patch management system, these applications periodically prompt users to deploy updates or reboot in response to an update that was automatically deployed.
In a physical desktop environment, these types of updates can be disruptive to users, but with VDI, where desktops are based on a shared image, they can become really annoying. If an application prompts a user for an update or attempts an automatic update, one of two things may happen.
One possibility is that the update fails because the user does not have sufficient rights to deploy the update. In this situation, the user will keep receiving update prompts until an administrator eventually updates the shared image.
The other possibility is that the update will be applied but will be removed when the user logs out of the session. Again, the user will be indefinitely prompted to deploy the update until an administrator eventually brings the shared image up to date.
Of course, some organizations virtualize applications rather than install applications directly onto virtual desktop images. Depending on which application virtualization software you use, you may have to repackage an application every time the application needs to be updated.
Patch management can involve significantly more work in a virtual desktop environment than in a physical desktop environment, and it varies depending on the way your VDI is configured. In any case, it is important to thoroughly test patches before applying them to virtual desktops.
This was first published in February 2014