As you can tell, I have been obsessed with Office Add-ins lately. Shifting gears from troubleshooting, I would like to address the different approaches to virtualizing add-ins with App-V. While the last two articles on the subject could easily be applied to both App-V 4.x and 5.x, my focus today will be specifically on App-V 5 because it offers more options and flexibility in the virtualization of add-ins. As I discuss each method, I will give my thoughts on the advantages and disadvantages of each method.
The Most Obvious: Sequence the Application and Add-in Together
While this method may seem to be the easiest, this method is only viable from a servicing standpoint if you:
- Have only one deployment of the application.
- In the case of Office, everybody will use the same group of Office applications.
- Everybody needs and/or is allowed access to the included add-in(s).
- For App-V 5, all add-ins will use the same COM settings inside the dynamic configuration files.
With this method, we do not likely run into issues with user state data and we do not have to involve any complicated sequencing recipes (other than the ones you would be using anyway – as the case with Office.)
Local Office Brought into Virtual Add-in Package during Sequencing
In this scenario, the add-in is totally virtualized but the parent application (Office App) is native. During sequencing, shortcut extension points were added to the package (dynamic configuration and FB0) so these shortcuts will launch inside the same virtual environment as the add-in. This scenario works best when there is a desire to keep the parent application native to the operating system.
The extension point format in the Deployment_Config.XML points to the local instance using a tokenized path. In the example below, here is a local shortcut extension point for Excel 2010 that is labeled as “Contoso Processing” because it will launch inside the virtual environment of the virtualized Contoso Processing add-in.
<Extension Category="AppV.Shortcut">
<Shortcut>
<File>[{Start Menu}]\Microsoft Office\Excel (ContosoProcessing).lnk</File>
<Target>[{ProgramFilesx86}]\Microsoft Office\Office14\excel.exe</Target>
<Icon>[{ProgramFilesx86}]\Microsoft Office\Office14\excel.exe.0.ico</Icon>
<Arguments />
<WorkingDirectory>[{ProgramFilesx86}]\Microsoft Office\Office14</WorkingDirectory>
<ApplicationId>[{ProgramFilesx86}]\Microsoft Office\Office14\excel.exe</ApplicationId>
</Shortcut>
</Extension>
The problem you may run into when using this deals with user workflow. This particular shortcut will launch this specific instance of Excel, but a regular shortcut to the local Excel will only launch the native Excel (with whatever native Excel customizations are in place.) You will not be able to share user state across the two instances of Excel unless you leverage UE-V or another user state solution.
Local Office Brought into Virtual Environment using “On-the-Fly” Shortcut
Yes, it’s a long name, but it was the best I could come up with! What happens here is very similar to the previous method where the local/native installation of Office is brought into the virtual environment but not using an embedded shortcut. Instead, we are using an “on-the-fly” shortcut solution where the shortcut leverages the following syntax:
<AppName.EXE /appve:<GUID>_<GUID>
This is convenient and quick way to link a local application with a virtual plug-in or add-in. Before you jump to this option, understand there are a few potential issues that could arise. The first will be the provisioning and management of these “out-of-band” shortcuts. Delivery of these shortcuts would have to come outside of the normal publishing block. You also will have to modify these shortcuts whenever a package version has changed. Also user state, registry opacity, and other configuration-relation issues could arise as you have similar issues with this method as you did with the previous one if you are moving back and forth between a local instance and one that has been brought into the virtual environment of the add-in.
Virtual Office Linked with Virtual Package using a Connection Group.
With the introduction of Connection Groups in App-V 5, we now have more flexibility in linking different packages together into a single virtual environment. The most common way of using connection groups to link Office applications with Add-ins is to create one that links Office as a virtual application with the virtual add-in applications.
Once you introduce connection groups into the mix, the order of packages in the connection group is important. This is regardless of how you are deploying these groups (publishing server, configuration manager, or stand-alone.) The connection group order specifies the order in which registry and file system data of individual packages are merged. What this means if Office is first in the connection group and the Add-in package is second, the Office application will take precedence in terms of registry opacity.
Local Office Application Brought into Virtual Package Using Empty package/Connection Group Solution
This is very similar to the above scenario except the assets for the local Office applications are local.
In this scenario, Office is installed locally/natively but there is an empty virtual package that contains local shortcuts to the Office applications. This virtual package is linked with the virtual add-in package through a connection group. The ramifications are combined in that you may encounter workflow issues for users. Connection group order will also be important in terms of user state and registry opacity.
Local Office application brought into the Virtual Add-in Package using “Run Virtual”
If you are working within RDS environments, and have a package that is published globally, you can also take advantage of the “Run Virtual” feature. You basically add process executable names as subkeys of the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\RunVirtual
For example, if I have a locally installed application called MyApp.exe and I would like this application to run within the virtual environment, I would create a subkey called MyApp.exe (perhaps a helper application like Adobe Acrobat that may need to be called from a virtualized web application.) I would then put in as the default entry a REG_SZ value that contains the package GUID and the version GUID separated by an underscore (i.e. <GUID>_<GUID>.
If the package is a standalone package, the process will be launched in that package’s virtual environment. If the package is in a connection group, the process will be launched in the virtual environment of the connection group for which the package belongs.