We are now moving on to a whole other aspect of VDI, and that’s the virtualization not just of operating systems but the applications as well. There are many benefits to application virtualization including:
Advantages of Application Virtualization
- Less conflicts between one application and another
- Same App, Different Versions: The ability to run different versions of the same application in the same Windows environment
- Keeping the Virtual Desktop Lean and Mean: Keeping your virtual desktop as an environment to merely execute programs rather than store them locally in C:\Program Files
- App-on-a-stick: Application Virtualization is not limited to virtual desktops. Often you carry your applications around on a memory stick and execute them anywhere as they work within their own sandbox
- ThinApps: One key advantage of ThinApp is that the virtualization allows for total encapsulation - in other words, there is no need to install a special client at the destination where the ThinApp will run. A ThinApp is an entirely separate and independent .EXE in its own right. The ThinApp runtime uses a Primary Data Container to hold the ThinApp runtime itself - a read-only virtual file system and virtual registry. ThinApp is popular because unlike some application virtualization it is agent less and clientless. This is seen as being more portable than other solutions. It allows the application to be ported to virtual desktops and terminal service without rebuilding or recompiling the application
- Network Streaming: Most application virtualization products will “stream” apps if delivered over the network – in other words, the client just downloads the files it needs as it needs them. Often these can be configured to be cached – just like a web browser - to speed the application’s launch when it is next loaded by the user
- ThinApp the View Client – If you think about it, one of the challenges of deploying View is that fact a client needs to be installed on the endpoint device. A simple remedy to this situation is to create a ThinApp of the client. It also means that when the client needs upgrading, you can simply publish a new version of the ThinApp
- Play in your sandbox – Most application virtualization tools have a sandbox concept, and ThinApp is no different. The idea is that all the changes a user makes to an application are directed to this sandbox location. So, unlike a conventional Terminal Services environment where end user customization can be difficult, the sandbox allows the user to customize the application to suit their needs. The sandbox is normally included inside the user’s roaming profile, but it can be redirected to a USB location for local use or to a network location - the choice is yours. Additionally, the sandbox can be made read-only – while a user can open the application in their ThinApp session and make changes to their preferences, once the user logs out, the ThinApp returns to its default settings. If something goes wrong with a ThinApp, you could delete the sandbox associated with it, and this would force the re-creation of the sandbox as if the user had yet to run the ThinApp for the first time
- All this and more – You can do all this and more – ThinApp itself is in part a ThinApp, and the installer is just 7MB in size. How’s that for efficient programming!
The diagram below shows a typical architecture overview of the ThinApp system. Each application sits within the ThinApp runtime that provides a virtual file system and virtual registry. As with server and desktop virtualization, the ThinApp-enabled application believes it is running in an unmodified environment - in most cases, applications should work happily within ThinApp. This virtual file system and virtual registry is given the collective name of the sandbox. The sandbox is a read-writable environment by default. As long as users have read-write access to their user profile (where the sandbox is stored), then any changes the users make to the application will be saved. Using the ThinApp “package.ini” file, it is possible to make the sandbox destroy itself every time the application is closed - this effectively makes the sandbox a read-only container, which discards any changes that the user made when the ThinApp was loaded.
When ThinApps are created, everything that makes up the ThinApp is held in what VMware calls the “Primary Data Container”. This holds a virtual file system and Windows Registry – when loaded the ThinApp thinks it can see a real C:\ driver when in fact it sees a virtual C: drive. The whole thing once loaded is referred to as the “Virtual Operating System” or VOS. If you like your ThinApp is running a virtual operating system, inside an operating system which is contained in a virtual machine!
|Want to read more of this guide?
Download the full “Administering VMware View 4.5” Guide (21 Chapters). The full guide contains additional step-by-step instructions and screen shots in each chapter.
This was first published in September 2010