VMware View – Persistent / Non-Persistent

We are struggling with how to implement VMware View. If you use a persistent pool, you waste resources by having resources provisioned for users who aren’t doing any work at the time. You also run into problems maintaining the user profile – you can use a dedicated user disk, but how do you ensure a good backup? It’s also an administrative annoyance having to disconnect and reconnect user data drives. On the plus side, users can be given admin rights to install applications

With a non-persistent pool, desktops are spun up as needed based on demand, and they can be destroyed automatically when the user logs off. You are forced into using roaming profiles with folder redirection, which creates its own set of administrative difficulties. Users aren’t able to install applications as nothing is persistent, so the administrator has to install all apps inside the pool template. Alternatively, you can use application virtualization and try to ThinApp an application. However, my experience with ThinApp has been less than impressive. When it works, it works quite well. When it doesn’t work, it’s a baffling ritual of hocus pocus trying to get the app to work. In the end, it just doesn’t work for the majority of our software because the vendor won’t support ThinApp. When you call a 3rd party vendor for support for a problem and try explaning that it was installed via ThinApp, the call will often end with a statement that ThinApp isn’t supported.

Refusal to support ThinApp does sound a lot like when vendors refused to support apps installed in a VM – they eventually came around. But until that point, we’re stuck with what the vendor is willing to support.

Leave a Reply

Your email address will not be published. Required fields are marked *