IT change management covers a wide range of topics, from application updates or patches to the operating system (OS) through to many other settings that can be altered. In the traditional desktop environment, these tasks can take up a large amount of time and IT resources to keep up-to-date.
A major problem is that being ‘up-to-date’ is a thankless task with no end. It can easily be compared to Sisyphus in Greek mythology, who has to spend all eternity pushing a boulder up a hill in Hades, only to get to the top and have the rock roll back down the hill again.
Desktop virtualisation is one strategy that aims to solve these problems in IT change management: instead of supporting a mixture of unmanaged PCs, an organisation can centralise its desktop images and carry out all the necessary management just once.
While the task of managing the desktop continues, the amounts of resource and time required to carry this out are drastically reduced. Instead of patching multiple systems individually, updates are applied once and everyone receives the benefit.
However, while this theory is very attractive, companies new to desktop virtualisation will have to be careful that they don’t exchange one set of problems for another. This is all based on the change management process and how virtualisation requires a different approach in order to be successful.
The first point to consider is how desktop virtualisation works, as it enables you to run either persistent images, create them from scratch, or run a mixture of both. Depending on the strategy chosen at this point, there can be some problems in making sure that these images are up-to-date and that a change management programme is actually working properly.
At the heart of this is how the central virtual machine image is managed. As all the end-user machines will be based on this single central image, this has to be thought about very carefully. The most common approach to backing up the central image is for it to be snapshotted - a copy is taken at a particular point in time, and if the production image is damaged or corrupted, then the backup can be quickly moved into place.
However, any changes or patches applied since the snapshot was taken will be lost. This, therefore, includes all the necessary patches and security updates for the OS, as well as any applications or utilities that were applied as part of the central image.
With all endpoint users requiring anti-virus, and most using applications such as Adobe Reader that can often be a vector for infection, this represents a large security risk. At the same time, the organisation’s change management process would probably not flag this as an issue, as it would think previous patches / updates applied to the image since the last snapshot were still in place.
For organisations with non-persistent virtual machine images, the best process for keeping virtual machine images up-to-date is to apply the patch to the master image, once the update has gone through the necessary testing and approvals procedures. All the virtual machines that are based on this central image will then automatically be up-to-date when they are next restarted.
With persistent virtual machine images, the patch management process can be more difficult. Once a virtual machine image has been created from the master image, it can develop a life of its own when it comes to updates. Patches installed after deployment, or any changes to the overall make-up of the virtual machine image applied to the deployed virtual machine will be lost with the next deployment.
The approach of updating the master image with changes is also not suitable for these heterogeneous environments. Firstly, it requires more effort and time from the IT team as minor tweaks or changes are made to the master image.
Secondly it also means that settings for individuals or groups of users could not be put in place, as they would be lost each time the master image is recreated. The other problem is that any virtual machines based on this master image that have had their own changes made would effectively be broken when an updated master image is created.
For IT change management purposes, it is therefore important to understand where snapshots compare to both the original master image and the most current version of the virtual machine. This involves checking the status of the virtual machines and whether the right patches have been applied to them.
The change management system may display that a number of patches have been successfully rolled out, but because the virtual machine snapshot has not been updated with these patches, it will be out of date. The change management systems therefore have to be aware that snapshots are in use and then apply any patches required after the snapshot image has been taken.
This process is based on recognising that certain changes are missing from the newly deployed virtual machine, and then the required changes (e.g. patches) can either automatically be reapplied or a prompt received on whether these changes should be reinstalled. This ensures that standardised images like desktop virtual machines will always be up-to-date without having to completely rebuild the image every time, or manually check that patches are installed and updates applied.
Whichever approach a company is thinking of, having this awareness of the IT change management process that will be in place is essential for a desktop virtualisation project to be successful in the longer term.
While it is possible for a VDI implementation to produce power savings and provide some cost savings, only having this full IT change management strategy in place will ensure that desktop virtualisation provides the expected cost savings on desktop management and support that most businesses are after.
By thinking about how to bring all this together, the benefits of VDI can really be delivered and the boulder of desktop support can be turned into a pebble.
