ra2 studio - Fotolia

Manage Learn to apply best practices and optimize your operations.

Top tips: Testing updates for virtual desktops

Deploying bad changes to desktop images can spell disaster for some organizations. That's why testing updates and being prepared to do a rollback are so important.

Testing updates before you deploy them to virtual desktops and having a rollback strategy are critical to ensuring employee productivity.

New desktop builds need to be tested before they are released. Not adequately testing updates before production means you end up testing in production, which can have ill effects on desktops and employees' ability to get work done. On the flip side, it's important to get testing done quickly. If the process takes too long, you may have a whole new set of updates to test before the last set even moves to production.

Still, it's sometimes hard to know how much testing to do. The type and number of desktops you support affects the kind of testing you must do.

Golden image updates

One of the benefits of technologies such as Citrix Provisioning Server and VMware View Composer is the ability to rapidly deploy updates. You can deliver the same image to a large population of users, which is faster and more efficient than deploying updates individually to hundreds of desktops.

When you deploy a good update to desktops that all share the same image, every desktop works well. But if there is a fault in the update, then you can break every desktop in the organization in one fell swoop. Adequate update testing minimizes the risk of a mass outage and subsequent rollback.

The amount of testing you need to do depends on the scale of the virtual desktop pool you want to update. Updating a pool with twenty users is quite simple, and if the update causes any problems, it is easy to roll those desktops back to the previous image. Rollback is a great feature because it allows you to undo the update just as easily as you did it in the first place. But if you're deploying updates to a larger user population, then the rollout and rollback will take longer.

It may take hours to roll out a new image to a couple hundred desktops; deploying that update to a couple thousand desktops will take quite a bit more time. And it takes the same duration to roll back to the previous image, so scale matters.

It's smart to schedule rollout for off-hours to minimize negative effects on user productivity, but you seldom have a choice about when you do a rollback. An unscheduled rollback affects user's ability to work on their desktops, so the more desktops you support, the more important it is to thoroughly test the update.

Dedicated versus floating desktops

Testing updates for dedicated desktops is very different than testing floating-assignment desktops.

Dedicated pools are easier because you can update and test a single desktop. It is worth testing a user account allocated to every dedicated pool. To do that, update one virtual machine (VM), and then have a worker test the update. Once the test user is happy, you can update some pilot users' VMs.

Many organizations have a group of employees who do user acceptance and put updates through their paces. These users usually have more IT knowledge than other workers, and they are better equipped to report issues before they strike the general population of workers. Once those users can validate the update, it is ready for general deployment.

Floating desktops require a different approach to testing updates, however. There is no way to test a specific desktop in a floating pool, but you can use a mirror pool. It's a copy of the production pool, but it only has a small number of desktops. This is the pool that the tester and then the pilot employees would use to test the update. Again, once the pilot users approve the new build, you can deploy it to the rest of the user population.

Full clone updates

Updating full clone VM s is exactly the same as updating physical PCs. Each VM is a separate and discrete image, so each one needs its own update. The risk you take in updating persistent images is that it's hard to tell what the update will do to user customizations.

On the other hand, if an update breaks one desktop there is chance it won't break other desktops. Full clone desktops are individuals; they need to be treated -- and updated -- as unique objects.

No matter what kind of virtual desktops you support, it's important to remember to keep a close eye on the help desk right after you roll out an update, and always be prepared to do an emergency rollback. A large user population will find issues that even the most careful test users did not.

Dig Deeper on Virtual desktop management

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What are your tips for testing virtual desktop image updates?
This is what I recommend to everyone:

  1. Use VMware View Composer or a similar program to deliver image updates to all computers at once.
  2. Fix any repairs with a simple rollback once the problem is found--following tip #1 means all computers roll back at once, versus an individual and manual process.
  3. Full clone updates should be treated like desktop updates. Manual rollbacks and updates are necessary. Full clone update problems are unit-specific.