VMware View 5 Essentials Training guides you from VDI basics, through app virtualization, to monitoring & troubleshooting and more.
This View 5 training video features instructor Brian Knudtson explaining exactly how ThinApp functions, how it virtualizes applications, and the virtual file system and virtual registry. The video is transcribed for you below to be used for note taking, studying, maybe even scrapbooking.
About View 5 Essentials Training
Brian Knudtson and Lane Leverett put together this View 5 course to give IT pros a resource for the core concepts of VDI, View’s components, and installation & configuration while managing user profiles and data.
Brian Knudtson: Let’s start by talking about how ThinApp virtualizes our Windows applications. Just like ESXi does for our hardware and operating system, ThinApp provides a layer of virtualization between the OS and the application. This has the advantage of taking the application and partially isolating it from both the OS and other applications that are running.
We have the ability to modify how isolated the application actually is. Because in some cases we don’t want to completely disassociate it from the OS or other applications, while in other situations we may want to completely isolate it. The ThinApp package itself runs in user mode. This has the benefit of not needing to have administrative rights in order to run an application. This does, however, put limitations on some of the applications that can run within the ThinApp bubble, mainly anything that would need administrative rights.
When an application is launched within ThinApp, it creates a bubbled environment that the application runs within. I like to use the bubble analogy because a bubble is a semi permeable membrane that allows some stuff to pass back and forth between it, while holding other things back.
Within this bubble, there’s a virtual file system and a virtual registry that the application uses to run. The folders, files, and registry keys that exist within this bubble can replace or merge with the OS’s file system and registry. We have the ability to determine which ones we’ll replace and which ones we’ll merge, but generally speaking, if it’s defined within the virtual file system or virtual registry within the bubble, it’s going to mask whatever may exist on the operating system.
In some use cases, we actually want to explicitly block access to certain registry keys within the operating system, even though we may not be providing a value within the bubble. As the user uses the application within the bubble, changes will need to be made to the file system and the registry. These changes are kept in a sandbox location, but it’s specific for that user and that application.
We can define where the sandbox location is going to be while we’re building the package if we keep the sandbox on a location that will always be available to the user, no matter what desktop they’re logged into. Whether it’s a non persistent or persistent virtual desktop, or even a physical desktop, it doesn’t matter to ThinApp. Any changes the user makes within the application are stored in the sandbox, so as long as a user can access their sandbox location, they’ll maintain those customizations as they roam from desktop to desktop.
While we’re creating the ThinApp package, we’ll define the permeability of the bubble, both at the file system and the registry level. One of the major advantages of ThinApp is the ability to package the application once and then deploy it across multiple different Windows operating systems. The most important thing to keep in mind here is that if we want to deploy it to a certain operating system and above, we need to package it on that lowest level of operating system that we would want to deploy it to. This will come into play when we talk about the best practices for our packaging machine.
When packaged, a ThinApp application actually exists as a single executable file or as a collection of files, depending on how we define the package. This makes it highly portable and simple to access. Each individual executable that makes up the application can become an entry point to the ThinApp package. These entry points will be represented by individual, executable files and provide access into the bubble.