Application virtualization was introduced into the IT industry several years ago to accomplish several goals:
- Give the administrator the ability to instantly install or uninstall an application.
- Improve the reliability of an install over traditional installation methods. Administrators have found simply activating an application using virtualization results in fewer calls to the helpdesk over a traditional MSI or Setup .Exe install.
- Allow some applications to run multiple versions of itself side by side on the same computer at the same time. This ability typically becomes useful when customers try to run multiple versions of Internet Explorer depending on the web site or to allow different applications to run side by side that require different versions of Java. Note: Microsoft does not officially support running multiple version of Internet Explorer using visualization, even its own AppV!
Different companies take one of the following two approaches to Application virtualization:
- Bubble architecture (Microsoft AppV) – This design runs the application inside the process space of another host process (or bubble/envelope). All process reads and writes are handled by the host process to decide what registry data and files they can access or even see. This approach excels in proving a robust secure containerization solution and avoids having to install an performance expensive filter driver. By default, each bubble runs independent of each other. This approach has also been proven to be quite challenging to actually package all of a customer’s applications into their respective AppV packages and getting these bubbles to see each other requires a high level of technical understanding of the technology and the applications being virtualized. While some see this technique as a way to increase security, Microsoft themselves did not design it for the purpose of securing applications from each other.
- Filter driver architecture (Symantec Virtualization) – This design relies on a filter driver that intercepts all registry and file system requests and decides what the calling application will see. This design has the advantage of letting all running applications see different perspectives of what files/registry data is installed. Each application may see different files/registry settings depending on how the application is started or configured. The biggest downside to this approach is that it affects performance even for applications that aren’t virtualized. In tests performed by LoginVSI, simply having a single application active using this technology can negatively impact other applications performance! Additionally, this design originally relied on legacy filter driver technology that will become obsolete by Microsoft as they move to a mini filter model.
We believe many IT departments may also like virtualization for an unstated benefit; they want to be able to repackage their applications to be customized for their environments. In other words these administrators want more control on what actually gets installed on their end user’s workstations without dealing with MSI/MST/MSPs. Customers also like how fast these virtualized packages are to install. An MSI can take several minutes while many of the virtualized packages can be installed in seconds especially if they are streamed, volume mounted (via VHDs) or pre-cached locally.We believe we have a unique third approach to being able to preserve many of the benefits of virtualization while avoiding many of their downsides.
We have developed “devirtualizer” technology that can consume AppV or our own OPK packages and use those packages to install applications natively to the computer as the original application packager intended. Our technology does not require a legacy filter driver, it also does not cause the application to run in an bubble. We simply take all of the registry data and files found in these packages and install them directly on the computer as soon as the process needs them. Combined with Virtual Volumes, the entire installation of most large applications takes place in seconds, this is from having nothing on the workstation to having the application up and running. By pre-caching and pre extracting these packages we find our install times are comparable to the time it takes to import and activate an application using virtualization. In fact, for small packages we tend to be able to install an application quicker than using virtualization since we don’t have the overhead of creating an envelope or importing the application. For remote systems or laptop computers, the package is automatically downloaded before JITI takes over installing the application almost instantly. These systems can be configured to pre cache these packages in the background.
We have also developed our own package format called an OpDesk Package or .OPK. This new package format allows us to extend the packaging technology further to add new features like the ability to handle application drivers or to be able to handle multiple delta versions of the same package. Additionally we still employ application virtualization for packages that need to be isolated from each other. You can create multiple packages that depend on different isolation packages. Isolation is used by exception instead of by default so we can keep all the benefits of our native speed JITI approach and not bog down the system too much. We have also developed our own packing tool called the “OpDesk Packager” that allows you to capture the install of both in-house custom applications or any third party application. To help avoid having to repackage all your applications, you can convert any .XPF packages and .APPV packages directly into our server console.