Posts Tagged ‘com’

App-V 5: On Java Virtualization Strategies

Throughout the past 15 years, from its origins in Softricity, one of App-V’s primary use cases has been addressing complex version-dependent Java run-time ecosystems. The “Application-to-Application Isolation model” of App-V – particularly using JRE runtimes as a test case – proved much success for those applications and enterprise websites that were married to a specific runtime – and needed to be used by the same user and/or multiple users on the same machine. As Softgrid became App-V, the client engine developed more and more methods of further, optional integration into the operating system via advanced extension points as well as dynamic virtualization (or just-in-time virtualization.)

Fast-forward to today: While the many of the old traditional issues that came with DLL Hell (such as DLL stomping) were rectified via registry-free assemblies and WinSxS, managing multiple JRE runtimes still requires intervention – especially when deployed to pooled session and virtual desktop environments (i.e. Citrix XenApp, MS RDSH/RDVH, etc.) As “JAR hell” as it is often called – appears to be here to stay for a while, JRE isolation is still one of the top use cases for App-V as a result.

Historical Strategies

In the world of Softgrid up until Softgrid 4.1, the strategy choices were simple:

  • Single JRE (Virtualize None): The most desired scenario. This simplified deployments and allowed for JRE to be included in base operating system deployment images.
  • Virtualize All JRE’s: No native JRE images in the base image. All versions are isolated using App-V.
  • Virtualize all but One JRE: In this scenario

In addition, the versions of Java had to be sequenced within the same virtual environment as the parent application. This would eventually start to change with App-V 4.5. In that particular release, DSC (Dynamic Suite Composition) was introduced allowing applications dependent upon Java to be sequenced separately from Java and linked together.


With the release of App-V 5 and its subsequent iterations, the options for Java have become more flexible.  However, since the primary reason for virtualizing Java is to be able to deploy multiple versions of the run-time module to same virtual or physical machine, all options for virtualizing Java are not necessarily on the table. Each option must be assessed on its own merit. The potential strategies for Java are as follows:

Packaged with Application or Browser

This is where the specific JRE middleware is installed alongside an application within the same App-V package. Not a very common solution as it requires the master application to be updated as the runtime needs to be updated. Because of the many issues that come with this, Dynamic Suite Composition was introduced in version 4.5. This was later improved with Connection Groups in V5.

Connection Groups and Challenges

Connection Groups are where two or more applications are sequenced separately and brought into the same virtual environment (essentially a meta-bubble.) This was introduced first in App-V 5 and then drastically improved for 5.0 SP3. This allows for the capability of updating applications and pre-requisite JRE packages independently. Connection Groups for Java run-times can be challenging – especially on RDS systems where many different users are running multiple applications dependent upon the same version of Java. Once a Java Package was initialized, it can only run within one Connection Group at a time. This requires proper planning and potential silo-ing for RDS scenarios.


This is where a designated native application is linked to a virtual environment. RunVirtual (in its many forms) tells a native application to run within the virtual environment of the assigned application (as well as its connection group if the application belongs to one.) RunVirtual is a great solution for those natively installed applications to take advantage of interoperability with a virtual application. The ways you can configure a native application to “Run Virtually” are as follows:

  • The RunVirtual Registry Key: This works great as it is tied to the processes’ executable name. Can be configured per-machine or per-user starting with App-V 5.0 SP3.
  • Configured Package Shortcut: This is a good solution as it travels with the package.
  • Out-of-Band RunVirtual: Where a Shortcut or Command Line contains the /AppVVE or /AppVPID switch or uses PowerShell to run a native process within the virtual environment of specific package.

All of the possible options for launching a native process into a virtual package’s environment (bubble) are found here:

Internet Explorer – A Worthy Separate Discussion

Internet Explorer warrants its own discussion primarily for two reasons:

  • Internet Explorer cannot be packaged and isolated from the native operating system.
  • Internet Explorer, like Explorer, is eligible for supporting primary and secondary virtualization environments through dynamic virtualization.

For those reasons, I segment my Internet Explorer and Java discussions from all other applications when discussing application virtualization strategies with customers.

Internet Explorer, Java, and RunVirtual

Configuring RunVirtual to bring the local Internet Explorer into the Java packages’ virtual environment is a simple way to allow for interoperability – but it can lead to its own issues:

  • RunVirtual via Registry Key: Whether it is per-user or per-machine – this methodology forces IE to only interact with one Java package (or else yield potential issues with RunVirtual collisions. Use this solution if only one Java package will be needed virtually with Internet Explorer for the user (or the machine if configured for the machine.)
  • RunVirtual using command line switches (AppVVE, etc.): This requires a lot of out-of-band shortcut management – but it does give flexibility so long as all other instances of Internet Explorer are configured for RunVirtual in either this manner or though packaged shortcuts.
  • Packaged Shortcuts: Using shortcuts to the local Internet Explorer – either captured via sequencing into the package manifest or configured via dynamic configuration. This method will create a special shortcut that essentially runs virtual for the native Internet Explorer. It also travels with the package and as long as the naming is unique, it will not create two much confusion although it does mean that Internet Explorer must be launched using this specific shortcut to ensure it runs within the specified virtual packages.

When you weigh out the “perceived” complicated options for bringing IE into an App-V Java package by Pros and Cons, you can simplify it using the table below:

IE Options



RunVirtual through Registry Key (Global)

Simple to Deploy.

Does not Travel with package. One Java per IE per Machine.

RunVirtual through Registry Key (User)

Simple to Deploy.

Does not Travel with package. One Java per IE per User

Packaged Shortcut

Travels with package. Allows for multiple Java packages.

Creates Multiple Internet Explorer Shortcuts.

Out-of-Band RunVirtual (/AppVVE, etc.)

Allows for Multiple Java Packages.

Does not Travel with package. Creates Multiple Internet Explorer Shortcuts.


Connection Group with EBIS (Empty Bubble w/ IE Shortcut)

This is where Internet Explorer is treated as a separate package though the creation of an “empty” virtual package containing only an Internet Explorer shortcut. That empty package is then linked to a virtual Java package using Connection Groups. If you want to use Connection Groups to link Internet Explorer with virtual Java packages instead of RunVirtual solutions, this may be the better solution – especially if you will be running both native and virtual Java on the same machine or device.

IE Native w/ JITV of Plug-In – Dynamic Virtualization Only

I have been starting to see this on App-V test matrices and I am a little bit concerned as it adds unnecessary testing variables that can further delay a package’s movement through common UAT (User Acceptance Testing) scenarios. That is not the case.

Dynamic Virtualization (also referred to as JITV – or Just-in-Time Virtualization) allows for virtualization of shell extensions, browser plug-ins, and ActiveX controls for a virtual package within the native processes that are hosting the COM objects. They key item being COM OBJECTS. They all need dynamic virtualization of COM in-process objects. There are some exceptions to some browser plugins that only use HTML scripts. They use an object model completely separate from COM. Not all browser plugins require COM in-proc virtualization. Do you get where I am going here?

Adding One Final (yet significant Variable) – the Legacy 4.6 Client

Running virtual packages containing Internet Explorer in 5.0 side-by-side with Legacy 4.6 packages running Internet Explorer running side-by-side with the App-V 5 client is supported. They did, however, had some initial issues when ran with Internet Explorer 10 and 11 due to issues with Enhanced Protection Mode and some double-hooking issues that were rectified by Hotfix Package 1 for 4.6 Service Pack 3 (


App-V 5: Further into COM and Dynamic Virtualization

January 13, 2015 3 comments

It has been addressed to me by the MVP community that more clarification is needed with regards to the architecture of how App-V 5 implements COM and how that may now differ as a result of the changes in Service Pack 2. The differences are simplified to the difference between the standard COM virtualization subsystem for normal virtualized applications and how Dynamic Virtualization handles COM objects for native processes that do not initially start off running virtually.

COM Virtualization

I have included a visual diagram to represent how the base virtual COM subsystem works to process virtual COM in-process and how out-of-process COM servers are managed in conjunction with the App-V Client Service and the Virtual Services component in preventing COM server conflicts among native and virtual applications and among applications running in different virtual environments.

The COM API’s are hooked by way of the injected App-V DLL. Depending on the COM settings, the Virtual COM service will be responsible for dynamically cloning COM registration within the virtual environment using generated spoofed GUIDS (or CLSIDs if you prefer that term – I use them interchangeably.) It will maintain a per-package (or Connection Group) GUIDS mapping of these spoofed-to-actual GUIDS. It will also be responsible for instantiating the cloned COM server(s) needed.


Enter App-V 5 Service Pack 2 and Dynamic Virtualization

Do not confuse the above with the added support for Dynamic Virtualization (also may be referred to as just-in-time virtualization or JITV.) The basic concept behind Dynamic Virtualization is that it allows the virtualization of shell extensions and ActiveX controls automatically within the native processes which would house them (Explorer.exe and Iexplore.exe) allowing for more tighter integration with the operating system.

Dynamic Virtualization modified App-V to allow:

  • Multiple Virtual Environments (VEs) to be associated with a single process.

  • Processes not running as a virtual process to have VEs associated with it.


App-V 5, through dynamic virtualization, allows virtualization of an in-process COM object implementing a shell extension or ActiveX control from the process that hosts it so long as that process appears under the ProcessesUsingVirtualComponents configuration item within the registry. Dynamic virtualization switches on for a thread that is executing within the object’s code or other code that is called from the object – rather than at the process level with standard virtualization. You can read up more on Dynamic Virtualization in a previous article mentioned here:

A native process never has a package’s virtual environment associated with it by default unless it is hooked by App-V. Without dynamic virtualization, the only way for it to be hooked and associated with a primary VE would be to have a shortcut configured to the application within the package (in the case of App-V 5, also configured within dynamic configuration as being a virtual application.)

With dynamic virtualization, a process can have secondary virtual environments. These secondary virtual environments are differentiated from the primary virtual environment in that they are associated with one or more DLLs that are loaded into the process, and are used for virtualization only when they are dynamically activated and associated with a particular thread of execution. For any thread in which dynamic virtualization has not been activated, virtualization will be controlled by the primary virtual environment, if any.

When a shell extension DLL handler from a particular package is loaded into a native process or a process from a different package, a new secondary virtual environment will be created to associate the shell extension’s package with the process. When a thread of execution enters that DLL, dynamic virtualization will be switched on for that thread only and associated with the correct VE. When the thread exits the DLL, dynamic virtualization will be switched off for that thread, and finally, when the DLL is unloaded from the process, the corresponding secondary VE will exit.

If you want to control Virtual ActiveX controls (huh-huh – cheap pun there) in the old fashioned way for Internet Explorer where you launch a Shortcut to IE within the virtual environment, and not allow any other native instance of IE to launch that control you will want to remove Iexplore.exe from the ProcessesUsingVirtualComponents key within the registry key at HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientVirtualization.

I would advise against turning off Dynamic Virtualization altogether as the dynamic virtualization features work great with the shell extensions that would be leveraged by Explorer.

It’s actually not entirely new to Service Pack 2

Dynamic Virtualization was actually part of the flattened Office 2013 package from the initial release of App-V 5.0. The Integration subsystem included with Office allowed for native processes that needed to load a DLL from the Office package – i.e. MAPI.

Categories: Uncategorized Tags: , , , , , ,

App-V 4 Application Troubleshooting: Breaking Down Virtualization Issues Pt. II

September 2, 2014 1 comment

App-V 4.5 and 4.6 virtualize at the user mode layer. One of the most identifying factors of seeing that a thread stack is that of a virtualized application is the presence of the SFTLDR.DLL file. This is what is injected into every process a virtual application will create. This file is responsible for ensuring proper redirections and translations necessary to make virtualization function properly by:

  • File changes to included virtual directory and file paths are redirected to the VFS
  • Registry changes hooked and redirected to the virtual registry
  • The spoofing of objects
  • The spoofing of COM GUIDS

In addition to the common troubleshooting methods such as disabling local interaction and disabling object spoofing, you can also take things further by disabling various virtualization components using the System Guard Overrides in App-V 4.x. These are not meant to be solutions but isolation factors in case you need to modify mappings. Many of these can be set at the registry level affecting the entire client or at the application level using the OSD file.

All of the registry values mentioned are located under HKLM\SOFTWARE\Microsoft\SoftGrid\4.5\SystemGuard\Overrides:

Disabling Virtual Services

You can disable virtual services on a per package basis by adding in the <VIRTUAL_SERVICES_DISABLED> tag under the <POLICY> XML element in the OSD file. You can disable the subsystem for the entire client by going adding the DisableVirtualServices DWORD value with a value of 1. If this is enabled, the sftldr.dll will not hook the service APIs.

Disabling the Virtual Registry

You can disable the virtual registry on a per package basis by adding in the <VIRTUAL_REGISTRY_DISABLED> tag under the <POLICY> XML element in the OSD file. You can disable the subsystem for the entire client by going adding the DisableVreg DWORD value with a value of 1. If this is enabled, the sftldr.dll will not hook the virtual registry calls.

 Disabling the Virtual File System

You can disable the virtual file system on a per package basis by adding in the <VIRTUAL_FILE_SYSTEM_DISABLED> tag under the <POLICY> XML element in the OSD file. You can disable the subsystem for the entire client by going adding the DisableVFS DWORD value with a value of 1. If this is enabled, the sftldr.dll will not hook virtual file system calls.

Finally, if you are really interested in going to the extreme . . .

You can disable ALL hooking. Can be useful when you are launching an application that is locally installed but still being brought into the virtual bubble. This allows you to turn it on and off if troubleshooting odd behavior. This is done at the client level which is why it is definitely only a troubleshooting option. You can disable hooking by adding in the registry value DisableSftldr DWORD value with a value of 42. Why 42? Well because that is the answer to everything in the universe. This basically makes the sftldr.dll (which is the primary hook DLL) dormant. MAVINJECT32 (or MAVINJECT64 if a 64-bit system) will still inject this DLL though. It will just remain dormant. This is a last resort.



Categories: App-V Tags: , , , , ,

App-V: On COM+

November 7, 2013 4 comments

Throughout the history of App-V and Softgrid, you have likely read from many sources that COM+ cannot be virtualized. Many tools, including the App-V sequencer, contain detection logic that will also notify you of the presence of COM+ components when you are attempting to sequence an application.

COM+ evolved from DCOM (Distributed Component Object Model) and has historically been used to develop components that leverage transactional technologies including SOAP, JIT (Just-in-time) activation, queued components, and more. If you want to dive into this further, you can find some good developer references are here:

Be careful not to confuse COM+ with an out-of-process COM server, which can be communicated with by enabled local interaction in the virtual application in 4.x or configuring out-of-process integrated COM in the deployment configuration of an App-V 5.x application.

For an application to be able to use COM+ Services, they will need to be configured within the COM+ Catalog. One easy way to do this is using the COM+ Component Services Snap-in that comes with Windows where you can configure most of the settings for COM+. Since Com+ actually generates dynamically at run time not during the actual installation, the sequencer is not able to process it, therefore is cannot be captured into a static state like other installation assets. When COM+ came on the scene in Windows 2000 with distributed transaction servers, application virtualization was not taken in to consideration.

When Microsoft developed Server App-V, the Server App-V sequencer was designed to capture COM+ components created by the application installer along with other elements such as local groups and WMI. Since there is state separation and not isolation, COM+ is not sandboxed, but laid down during deployment through its normal registrations so it can function normally at run time.

Remediating COM+ Limitations with App-V

If your sequencer happens to detect and notify you of a COM + component, it is telling you that this application may not function correctly as expected with the package as-is. Does this mean that the application cannot be virtualized with App-V and delivered via an App-V delivery system? Not necessarily. Like other components that cannot be virtualized (such as drivers,) it does not necessarily mean that you are completely out of luck. In fact, there are possible remediation options. And with App-V, we have more options to implement these remediation fixes. In a sense, you can package the component to be laid down during deployment in a similar manner (but not identical) as it is with Server App-V.

Once you are made aware of a COM+ component within an application, you will need to install the application natively on a test machine. Then you will need to launch the Component Services management console (HINT: I am always confused as to which operating system launches this so I just launch DCOMCNFG and it always launches it.) You should likely find the component or components within the COM+ Applications folder under “My Computer.”  


Once you locate it you can then right-click the component and select “Export.”


This will launch the COM+ Application Export Wizard.


You will then give the path and name to the destination MSI file you want to export this application to. 


Accept defaults and select ‘Next’ then ‘Finish’.

Now you will need to either re-sequence the application or update the existing package and during sequencing or updating, add the MSI file to the package. In the case of a V 5 package, I would usually add it into the scripts folder.

If you are using App-V 4.x, you will want to edit the OSD file and add in a script that will install the Copy out the MSI file and run the installer. You do this by adding the following beneath the <DEPENDENCY> tag.


        echo off n

       if exist C: goto end n

        mkdir n

        copy /y “q:mymsi.msi ” “C: ” n



        echo off n

        if not exist C: goto end n

       C:mymsi.msi /quiet n

        del /f /q C:mymsi.msi n

        :end n


Now, let’s be realistic. For the above to work, you must accept two siginifcant caveats. 1) The user executing the application will need to be a local administrator. This is often a deal-breaker. 2) The user will have to encounter a delay upon launch due to the installation.

App-V 5.x

Enter App-V 5 and its enhanced scripting model. On either a global publish or add package event, you can add deploy the component in a secure manner as those events will execute under the context of the SYSTEM account. You can place the MSI and the scripts installinguninstalling it into the embedded scripts folder inside the package. HINT: Since the script event only allows for one command element, my advice is to but all of the installation commands into a batch file or PowerShell script and call that script for the event. Since the scripts and package root directory in the package are automatically searched, you do not have to worry about specific paths.



        <Arguments>-F deployComPlus.ps1</Arguments>

        <Wait RollbackOnError=”true” Timeout=”30″/>


<Arguments>-F removeComPlus.ps1</Arguments>

        <Wait RollbackOnError=”false” Timeout=”60″/>


In the interest of full disclosure – with regards to this working seamlessly, I am 3 for 4 as I write this. In my opinion, .750 is a good batting average! Understand that this is meant to be an option for remediation as COM+ still technically cannot be virtualized.

App-V: On COM Isolation and Interaction

September 11, 2013 8 comments


Through the history of Windows, the COM (Component Object Model) has been integral to application development the as an interprocess communication mechanism. The roadmap from DDE (Dynamic Data Exchange,) to OLE (Object Linking and Embedding,) to OCX (OLE Custom Controls,) to ActiveX – and so on – allowed and continues to allow multiple languages and development environments to develop applications on this language-agnostic platform.

Because COM facilitates communication channels and data exchanges between applications, it requires both significant consideration and planning when determining the feasibility of application virtualization. App-V has its own virtual COM subsystem which is designed to isolate the COM interactions from the local operating system. The primary way it does this is through GUID spoofing.

COM uses CLSIDs (Class Library Shell Identifiers) to identify all of its components and interfaces. These are labeled using GUIDs just as many other things are in Windows  Different component types are identified by class IDs (CLSIDs), which are Globally Unique Identifiers (GUIDs). Each COM component exposes its functionality through one or more interfaces ({7312498D-E87A-11d1-81E0-0000F87557DB} is my favorite because it is “blur.”) The different interfaces supported by a component are distinguished from each other using these identifiers. One of the strengths of App-V is that it prevents COM conflicts among native and virtual applications and among applications running in different virtual environments. App-V is also able to isolate native and virtual COM servers within a virtual environment.

When App-V hooks into a process, the virtual COM subsystem is able to intercept and virtualize COM object instantiations by dynamically cloning COM registration within the virtual environment using auto-generated CLSIDs and start instances of the cloned COM server. The GUID mappings will be maintained throughout the life of the process. While the hook model is different between App-V 4.x and 5.x, the overall process is very similar. When you combine applications into multiple virtual environments (DSC, Connection Groups) or package multiple applications together into a single package, all of these applications will still be able to communicate with each other at the application level through COM.

Basic Planning

For the majority of applications, you will likely only need to consider COM at a high level when planning. I like to use scenarios and I often do when I am explaining this to customers.


In the example above, we have a simple scenario. We have Application A (Word) and there is an embedded object type of Application B that can be inserted and modified leveraging the controls of Application B. Oldest and most known method as it goes all the way back to OLE. In the world of App-V this may still be needed with virtual applications. How do we facilitate this?

1.)    If your plan is that Application A is virtual and Application B is virtual – then you will have to either:

          Package Application A and B together in a single sequenced virtual application package

          Package Application A and B separately but join them via a unified virtual environment (using DSC with 4.6 or Connection Groups with 5.x.)

2.)    If your plan is that Application A is virtual and Application B will be locally installed – then you will need to:

          Configure COM integration/interaction with the local operating system. The method varies depending on the version of App-V you are using.

3.)    If your plan is that Application A will be local and that Application B will be virtual – then you will have to do one of the following:

          Create an extension point (shortcut) to the local application (A) within the configuration of the virtual application (B) and will have to launch the local application using that extension point so it will be hooked.

          Create an extension point (shortcut) to the local application (A) within the configuration of an otherwise empty virtual package. Bring that package and the virtual application (B) into the same virtual environment using DSC or a Connection Group (depending on what version you are using.)

          Use the “RunVirtual” registry key if you are using App-V 5.0 to allow the local process (A) to operate inside the virtual environment of the virtual application (B.)


Because some applications may still need to communicate with the local operating system, there may be the need to adjust and fine-tune COM behavior for certain applications (as in the case of #2 above.) App-V historically has had ways of doing this.



This is a tag in the XML configuration (OSD file) of an App-V 4.x application. Whehn this tage exists and is set to TRUE, this means that BOTH object/eventing virtualization (spoofing) and COM GUID virtualization (also spoofing) are turned off. This DOES NOT mean the virtual COM or the virtual object subsystems are turned off. The objects will still be looked up in the virtual environment, but if not found, App-V will revert to the native OS and look there as well. This is why it is usualy a fairly safe thing to implement. The primary App-V 4.x hook DLL (SFTLDR.DLL) is still injected with all of its subsystems.

To enable local interaction, the OSD VIRTUALENV element is configured as follows:




Objects/Eventing will be discussed more in detail and in a forthcoming post.


App-V 4.x: Disabling and/or Micromanaging Virtual COM

You can manage COM in more detail within App-V 4.6 by configuring the client registry. This is generally not preferred as it globally affects the App-V Client where LOCAL_INTERACTION_ALLOWED applies only to the application package. If you want to disable the Virtual COM subsystem, you can navigate to the following registry key and set the following value:


Value: DisableGuidMapping

Data Type: REG_DWORD

Value: 1

Outside of troubleshooting, I find it illogical and dangerous to disable this as a solution to any virtualization problem. I would only advise doing this as a troubleshooting step. Once you realize what may be happening you can simply apply a more granular approach to permanently fixing the solution by excluding COM GUID spoofing for the troublesome application. You do this through COM exclusions. First create a subkey called ComExclusions beneath:


Then create a value called “Exclusions” with a data type of REG_MULTI_SZ and then you will list all of the CLSID GUIDs that you want excluded on each line.

The App-V 5.0 Virtual COM Subsystem

COM integration in App-V 5 does out-of-process (its own process) and in certain cases – in-process (within a process) COM registration (Office 2013 Click2Run.) COM is also handled a little more granularly in the dynamic configuration files in App-V 5.0. This is to encourage more handling of COM through configuration policy on a per-package or per-connection group basis. Within this policy, you can set one of three modes:

  • Off
  • Isolated (Virtualized)
  • Integrated (through in-process or out-of-process registration.)

The overall effects are outlined in the following boring chart:


 COM Mode in XML

 OS Integration

 COM Virtualization

     <COM Mode=“Off”>


 No integration


     <COM Mode=“Isolated”>


 No integration

 On – w/ GUID Spoofing

     <COM Mode=“Integrated”>

      <IntegratedCOMAttributes OutOfProcessEnabled=”false” InProcessEnabled=”false” />


 No integration

 On – no GUID Spoofing

     <COM Mode=“Integrated”>

      <IntegratedCOMAttributes OutOfProcessEnabled=”true” InProcessEnabled=”false” />


 Integrate out-of-process

 On – No GUID Spoofing

     <COM Mode=“Integrated”>

      <IntegratedCOMAttributes OutOfProcessEnabled=”false” InProcessEnabled=”true” />


 Integrate in-process

 On – No GUID Spoofing

     <COM Mode=“Integrated”>

      <IntegratedCOMAttributes OutOfProcessEnabled=”true” InProcessEnabled=”true” />


 Integrate both

 On – No GUID Spoofing


I felt it important that you get a sense of all of the possible permutations of COM policy configuration. Especially if you are toggling the sequencer defaults in the “Advanced” tab. All this does is set the default policy in the dynamic configuration file (deployment_config.xml) generated by the sequencer.


When “Allow all COM Objects to interact with the local system” is turned off, the COM policy will default to:

    <COM Mode=”Isolated”>


When turned on (checked) it sets it to:

    <COM Mode=“Integrated”>

      <IntegratedCOMAttributes OutOfProcessEnabled=”false” InProcessEnabled=”false” />



COM Mappings and Exclusions in App-V 5.0

COM GUID Mappings are stored in a COM Class Maps located in the following registry locations:

Per User:


Per Machine:


These are helpful when troubleshooting COM. Like 4.6, you can also add individual exclusions within the registry by adding the GUID as a REG_SZ value in


Use the value itself to give a description for humans to read 🙂 For example:

   Value: HKEY_CLASSES_ROOTCLSID{7312498D-E87A-11d1-81E0-0000F87557DB}
   Data Type: REG_SZ
Data: Blur

Categories: Uncategorized Tags: , ,

App-V: On Virtualizing Multiple Excel Add-ins

September 4, 2013 11 comments

Yes, I’m still obsessed with the subject of add-in virtualization. I felt it also necessary to ensure that there was a discussion of add-in types and multiple Office add-ins (particularly Excel) before I finally leave this topic of discussion. Have you ever noticed that when you are managingloading add-ins in Excel that you have multiple distinct types of add-ins. The two most common types are COM add-ins (common format for 3rd-party applications) and Excel Add-ins or what we refer to technically as Automation Add-ins (VSTO, XLAM add-ins.)


COM Add-Ins

COM add-ins act as in-process COM servers (like an ActiveX DLL) that is built off the IDTExtensibility interface. These are pretty much event-driven and present themselves to the user in the form of custom menus, commands, etc. When a COM Add-in is installed on a user’s system, registry entries are created for the Add-in. In addition to normal COM registration, a COM Add-in is registered for each Office application in which it runs. COM Add-ins used by Excel are registered in the following registry key:


For example, if I have an Add-in called “Data Transfer Excel Add-in.” it would register in a key similar to the image below:


NOTE: Do not get confused. This registration may be used with the other add-in registrations that Office applications may use (in the HKLM or the HKCUSoftwareMicrosoftOffice<VERSION><App>Addins key.) That can also be a source of troubleshooting sometimes.

Dynamic Configuration is important when leveraging an add-in when it comes to COM settings. If the Add-in will be packaged with the application, it should remain isolated – which is the default. If the add-in is virtualized but Office is locally installed, then the COM add-in must have its COM mode configured as “Integrated” with in-process registration. If you are linking the add-ins with a virtual instance of Office via a connection group, this is also recommended (using the element “<COM Mode=”Integrated”>”)

NOTE: LOCAL_INTERACTION_ENABLED set to TRUE in the 4.6 OSD file achieves this same result.

Automation Add-Ins

Automation Add-ins build on COM Add-ins in that functions in Automation Add-ins can be called from formulas in Excel worksheets. While COM Add-ins must be in-process COM servers that support the IDTExtensibility2 interface; however, Automation Add-ins can be in-process or out-of-process COM servers and implementation of IDTExtensibility2 is optional. Understanding what type of COM server will determine how the add-ins COM configuration may need to be configured in the applications dynamic configuration file.

Order of Add-Ins

When you make additions to the list in the Add-Ins dialog box or when you select and clear Add-ins in the list, Excel stores your changes in the registry. First, Excel uses the following registry setting to determine whether or not an Automation Add-in in the Add-in list is loaded:

Key: HKEY_CURRENT_USERSoftwareMicrosoftOffice<VERSION>ExcelOptions

String OPENx (where x is the numerical order.)

Sample Value: /A “ServerName.Classname”


Note: The /A switch denotes it is loading an automation add-in *AND* unlike COM Add-ins, automation add-ins are loaded on demand so the LoadBehavior registry key is not necessary for these types of add-ins.



When an Automation Add-in that is listed in the Add-Ins dialog box is cleared, a subkey with a name equal to the Add-in’s Program ID is created in the following registry key:

HKEY_CURRENT_USERSoftwareMicrosoft<VERSION>ExcelAdd-in Manager

This registry setting ensures that Automation Add-ins that you have added to the Add-ins list are retained in the list even when you have chosen not to load them. Both the Add-in Manager and OPENx registry settings need to be managed properly when virtualizing add-ins.

Caveats when Virtualizing Multiple Add-ins with App-V

When Excel loads these automation add-ins it will expect to see a ordinal series of OPEN entries in the registry (OPEN, OPEN1, OPEN2, OPEN3, etc.) If it is the first add-in to be installed, the registry value created will be “OPEN.” When the second add-in is installed, it will register “OPEN1.” The third add-in installed will then register “OPEN2” and . . . well, you get the idea.

So here is the problem that often arises: Let’s say you are virtualizing three Excel Add-ins separately and you want to link them with a virtualized Office package (or even linking local Office by pulling into an empty package and linking that with these three add-ins.) Chances are the first time you do this, you will fail – as the case with many of us.




If I sequence all of these add-ins separately and link them all with Office through a connection group, I have the following factors to consider with regards to these overlapping OPEN values:

  • Registry opacity within the add-in package
  • Resultant registry opacity upon Connection Group deployment

During sequencing, the normal behavior to determine default registry opacity goes as follows:



This of course, can be adjusted using the virtual registry tab within the sequencer. If you virtualize each add-in separately (which is normal) and add the add-ins into Excel with each sequence, you will find that each one appears as an OPEN registration. When you combine the add-ins together, you will likely find only one of the add-ins working upon first launch.




Another problem to avoid but one that is less likely to occur is to ensure that your OPEN registrations are in a direct sequence (OPEN, OPEN1, OPEN2, etc.) They have to be consecutive. If you have OPEN, OPEN3, OPEN5, etc. configured then you find Excel stops loading after the first one because OPEN2 is missing.

What I am Currently Doing

I take advantage of the knowledge of knowing that when you use Connection Groups, the number one entry in <appv:packages> section of the Connection Group XML descriptor document takes precedence. So if I were to employ a connection group that contained a local instance of Office, I would simply import a custom REG file containing the OPEN registrations in the correct order into an empty package (during sequencing) that also contains the shortcut extension points to the local Office applications. I then ensure that the empty package is at the top of the order within the Connection Group.


  <appv:Package DisplayName=”Local Office” PackageId=”<GUID>” VersionID=”<GUID>”/>

  <appv:Package DisplayName=”Add-in #1” PackageId=”<GUID>” VersionID=”<GUID>”/>

  <appv:Package DisplayName=”Add-in #2” PackageId=”<GUID>” VersionID=”<GUID>”/>

  <appv:Package DisplayName=”Add-in #3” PackageId=”<GUID>” VersionID=”<GUID>”/>




You have to ensure that the resultant virtual registry used by the parent Excel application has a correct OPEN sequence of registrations. You also have to ensure that the opacity will not conflict with any local registrations. Keeping these things in mind, I have the following recommendations when I am devising a add-in strategy for my customers.

Virtualize NO Excel automation add-ins.


Virtualize ALL Excel automation add-ins. Use Connection Groups to bridge a local or virtual Excel instance or package everything together if necessary,