The fresh flavor that lasts and lasts……that’s goal behind one of my customer’s latest desktop projects. This customer has been working the View3 pre-release code for some time now. Using View Composer, we now have the capability to very easily, and programmatically refresh a user’s desktop back to the original golden master image state. View Composer supports three primary operations after initial linked clone creation:
1: Refresh – A Refresh takes a desktop back to the original state of the master
2: Recompose – A Recompose takes a linked clone and re-homes it if you will, to a new parent image (think instant OS updates or software rollouts)
3: Rebalance – A rebalance takes all the linked clone VM’s in a pool and re-balances them across a set of LUN’s
For the sake of this conversation, we will focus on the Refresh operation.
My customer’s goal is to maintain the integrity of their corporate desktop image deployed to users. Over time, their user’s have a particular habit of destroying their desktops. So much so, that they had to put in place a mandatory, ongoing re-imaging program so that all desktops never go more than six months without a re-image. This policy has had some very positive results in terms of reduced help desk calls and time spent just sustaining a rotting OS. That said, the effort required to sustain an perpetual, semi-manual re-imaging program is substantial.
Enter VMware View Refresh. Right now, they have rolled out a program for a set of 50 users to see how well it would work to refresh a user’s desktop much more aggressively (every 5 days to start). This means that after a linked clone is created and the user begins to use the VM, the VM will automatically refresh every 5 days back to it’s original state (configured in the desktop pool settings…screenshot to come). The goal is to make this a highly seamless event for the users. With View Composer’s User Identity Disk, C:\Documents and Settings\ is redirected to another, persistent (thin provisioned) .vmdk that is presented as the D: drive. This is configured when you create the pool as shown below:
Based upon our initial tests, this is working really well. We can refresh a user’s desktop without them ever knowing, as the next time they log on their profile is completely intact. Currently we are testing all of their applications to ensure this will work across the board. I am sure we will find some applications that do not, gasp!, save their preferences in the user’s profile (something TS/Citrix admins deal with constantly). For those applications, our plan is to ThinApp the application and set the User Sandbox to live in the proper, user’s profile directory. We have also found that we need to re-register each VM with the anti-virus console after a refresh operation which we are now achieving through a post-sync script.
I’ll be sure to keep everyone posted on our progress and experiences. It’s certainly something to consider and explore. Let me know what you think! Until then, I wish you a very minty fresh desktop experience! 🙂