Troubleshooting virtualized Office add-ins are always fun. Correction: troubleshooting Office add-ins are always fun for people like me – not necessarily normal human beings. Whether you are using add-ins with a local instance of Office or are packaging add-ins with virtualized Office, you need to be to understand how Office knows which add-ins to load and how these will be loaded.
There are generally three ways to virtualize add-ins for Office:
1.) Where Office is installed locally and the Add-in is virtualized - The Office application must have a shortcut/OSD file provisioned in order to be brought into the virtual environment. Starting with App-V 4.6 SP2, the App-V Sequencer has a specific workflow that allows for this.
Be advised that when you do this, you will be bringing in the local instance of Office into the virtual environment in order to load the add-in. What this can lead to is other add-ins which may not be virtualized not loading if the configuration is not set properly for this. Having a clear understanding of your Office add-in ecosystem will help in developing a strategy in advance to avoid this.
2.) Through Connection Groups or Dynamic Suite Composition (Depending on the Version) - You can also take advantage of both the Add-in/Plug-in workflow and the “Expand Package to Local Disk” feature of the sequencer in order to package Office and Add-in applications separately but still connect them into a common virtual environment. 
This method works best (in my opinion) when your strategy is to virtualize both Office and the add-ins. This is also the only way I use Add-ins with Office 2013.
3.) Office and add-ins packaged together into one package (often sequenced using a single pass.) This way is the least common and not always recommended as it may require you to deploy multiple Office packages.
Verify the Add-in Registry Keys
When an add-in is installed, it can be registered to either the user or to the whole machine. When an add-in is sequenced, it will also be virtualized and depending on the registry opacity configuration, will override whatever is locally present. User-registered add-ins go to HKEY_CURRENT_USER while add-ins registered to the entire machine go to HKEY_LOCAL_MACHINE. Whether Office is local and being brought into the virtual environment or Office is virtualized with the Add-in, Office needs to be able to understand the “Load Behavior” of the add-in. This will be found under
HKEY_LOCAL_MACHINE\Software\Microsoft\Office\<APPLICATION>\Addins
Each Add-in appears as a subkey beneath this key. The LoadBehavior DWORD value determines how it will load. This key is the #1 culprit when it comes to Add-ins not working right whether it is a “1st launch-only” issue or an “always-launch” issue. It is a DWORD value. By default, this entry is set to 3, which specifies that the add-in is loaded at startup but an many cases, especially if the add-in was launched during sequencing, you may run into a situation where the value may be set to something else depending on what was done during sequencing. If the value is 0, then the add-in will have to be enabled once the user launches the application. If the package is repaired it will have to be enabled again. The value 1 can be misleading and I encounter this a lot in virtual add-in troubleshooting. Add-ins dialog box indicates that the add-in is loaded after the application starts, the add-in isn't actually loaded. If the application successfully loads the add-in, the LoadBehavior value changes to 0, and remains at 0 after the application closes. The value 2 means If the application successfully loads the add-in, the LoadBehavior value changes to 3, and remains at 3 after the application closes. With App-V this means potential issues in prompts including annoying “success messages.”
LoadBehavior at 3 is good for App-V
Hey, I made a rhyme! If the LoadBehavior value is set to 3, it will always try to load the add-in and if the add-in fails, will set it back to 2. This is what we want in the virtual registry of our App-V package most of the time. You can usually verify/set this in the Virtual Registry tab after sequencing prior to saving the package.
Should I Verify Registry Opacity?
Yes. While you are there you may want to verify your registry opacity settings. Are those Add-in keys set to “override” or “merge” with the local key. If you have local add-ins that you will use alongside of these virtual add-ins, you will want to ensure that the Addin key is set to merge.
What about Outlook Add-Ins?
For Outlook, you will most assuredly need to manually import/add these virtual registry entries during sequencing (or package upgrade) since you do not want to be launching Outlook during sequencing.
Check the Event Logs when Troubleshooting
While the event logs may not have the event handlers registered for office (since it is virtual, you will still see unregistered event ID’s of Outlook (Event ID 45) which will list all of the add-ins loaded and their subsequent load times.
Event ID: 45
Outlook loaded the following add-in(s)
Office 2013 and Mismatched Virtual Subsystem Settings
If you are using Virtual Office 2013 with App-V 5, this is the #1 issue. Given all of the changes with Office 2013 virtualization, one would think the Add-in story would become complicated. It is not. The recommended practices are pretty straight-forward:
On the Sequencing Machine:
1.) Install the App-V 5 Sequencer.
2.) Install Office 2013.
3.) Start a new package.
4.) On the “Type of Application” page, select “Add-on or Plug-in.”
5.) Select the installer for the plugin.
6.) In the “Install Primary” page, select “I have installed the primary parent program” and continue.
7.) Install the plugin and save the package.
8.) Depending on the add-in, you may need to run it during sequencing.
Client Configuration
1.) Copy your Office 2013 to the client machine
2.) Copy the sequenced add-in to the client machine
3.) Modify the add-in’s DeploymentConfig.xml file and modify the following:
4.) Search for:
“<COM Mode="Isolated">”
modify to
“<COM Mode="Integrated">”
5.) Search for:
“<Objects Enabled="true" />”
modify to
“<Objects Enabled="false" />”
The Connection Group will fail if the above changes are not made.
6.) Build a Connection Group document for both Office 2013 and the Add-In. You can do this with stand-alone testing by using the following resource on creating a Connection Group XML document: http://technet.microsoft.com/en-us/library/jj713474.aspx
7.) Enable Package Scripts
Set-AppvClientConfiguration -EnablePackageScripts 1
8.) Add the Office 2013 package; publish it Globally
Add-AppvClientPackage –path <path_to_office_package_>.APPV | Publish-AppvClientPackage –Global
9.) Add the Add-In package; publish it Global
Add-AppvClientPackage –path <path_to_office_addin>.APPV | Publish-AppvClientPackage –Global
10.) Add the Connection Group pointing to the Connection Group document you created earlier. Enable it Globally
Add-AppvClientConnectionGroup –path <PATH_TO_CG_DOC>.xml |Enable-AppvClientConnectionGroup –Global
11.) Launch the Office application the add-in uses.