Application Virtualization Guidelines Part 2
- Published: Wednesday, 27 January 2010
In this first article I started with describing application virtualization guidelines and best practices. This second part article continues with those guidelines.
- Consider carefully middleware
Applications virtualized are running in separated layers. Those layers cannot communicate with each other. Therefore packaging an application that require other applications to function properly (think of Oracle clients, Java Runtimes, Office applications and so on) should be considered carefully. With the latest versions of application virtualization product it is possible to specify that application in a separate layer can be called in another virtual layer. With this new feature there are three possibilities for middleware applications:
- Middleware available in the operating system layer
With this methodology the (default) middleware is installed physical in the operating system layer. Because the OS layer is always readable the middleware application will be available for all virtualized applications. However updates and fixes for the middleware need to performed on all systems (and will require an Electronic Software Distribution system).
- Create a separate package for the middleware
The required middleware will be virtualized in his own package (virtual layer) and will be called by the applications which need the middleware. This makes upgrading/patching the middleware really easy and is the preferred method. Unfortunate the application linking is just introduced and there is a possibility that this solution does not function for all applications.
- Include the middleware in the same package
Including the middle in the same package ensures that the application can use the middleware application. However if many middleware is being used all the packages should be upgraded in the case of a patch/hotfix of the middleware application. If the application linking does not work, this is the alternative to achieve a virtualized application.
- Install all components of the application
Several applications have different components that need to be installed. When installing those components it is often possible to select the option "Install on first use". Change this "Run from my computer" or "Not available", otherwise the user will get an error if the installation source is not available or the changes will be added the User Settings file (causing enormous user settings files).
- Revert the Snapshot to the default configuration
It is a best practice to revert the machine to its initial state:
Whenever errors occur which are related to virtualization process
Whenever you need to start a new sequence
Whenever you need to start a new native installation
- Disable "Auto Update" features
Some applications have the ability to check a web site or a server for the latest application updates. This feature should be turned off, as version control should be performed by upgrading the package in a controlled way by the IT department.
- Package as much as possible in single pass of the installation phase
Package as much as possible in a single phase. Do not stop the record/monitoring process after each installer, unless the application requires a reboot. When dialog pops-up for reboot carry out that task, followed by stop record/monitoring step. The following application can be installed by selecting begin monitoring again.
- Leave User Access Control enabled
If the virtualization application is being used on a Windows Vista workstation with the User Access Control (UAC) enabled, the UAC feature should be turned on when creating the virtualized application. This feature should be enabled prior to beginning the virtualization process. If UAC is disabled during the virtualization process there is a possibility the application can fail or gives an error.
For Microsoft App-V (formerly known as SoftGrid) the following additional guidelines should be followed.
- Install the application on the App-V partition
It is recommended to install the application to the SoftGrid partition to reduce redirection complexity for the SystemGuard. The extra layer of complexity will introduce a minor App-V overhead which can result in minimal reduced execution speed of the application. App-V can however handle exceptions to these installations. So applications that do not function installed on the App-V partition and applications which automatically install to C: can still be sequenced.
- Use the 8.3 Naming Convention for the application folder
It is a best practice to install every application in his own folder (for example Q:\WinZip10). Within App-V this is called the asset folder. Because App-V is relying on the 8.3 naming convention the asset folder name must be named based on the 8.3 naming convention. When using long names it can happen that two applications are using the same asset folder name, logically causing issues between those applications. After the asset folder long names are fully supported.
- Sequence to a folder in the root of the drive, not to a subdirectory.
It's required to sequence to a folder in the root of the App-V drive (asset folder). For example Q:\Winzip10 is correct, while Q:\ and Q:\Temp\Winzip10 are incorrect. When the sequence exists of multiple part, install each application in a subdirectory of the asset folder.
Although application virtualization is solving a lot of issues in comparison with the traditional MSI packaging, there are several rules and guidelines that should be taken into account before you start virtualizing applications. In this article I described bundles those guidelines and best practices so you can use this as the basis for application virtualization projects/tasks.