Jun 13, 2017 - 9 Comments - Virtual Vibes -

A Natural COM Side Effect of RunVirtual in App-V 5.0

While working with a large financial organisation in London last week, someone brought my attention to how RunVirtual is giving them some interesting side effects they didn’t quite expect when running other local tasks or applications. I wasn’t too surprised by what they were seeing but thought it would be a good idea to share it with you all so we are on the same page.

The Symptom

You deploy RunVirtual for a local process such as Internet Explorer:


You later find that anything else running a programmatic COM call locally to that same process fails with an error relating to ResourceUnavailable: (:) [New-Object], COMException:


The Cause

So you might be thinking why is RunVirtual affecting local applications or tasks as above? Well it is by the very nature of how RunVirtual works. As soon as we create a RunVirtual key for Internet Explorer in this case, we are listening out for iexplore.exe in all shapes and forms. This isn’t just limited user based actions that involve double clicking an Internet Explorer shortcut but also encompasses programmatic calls that may force us to load the process, in this case iexplore.exe. Infact as we run the command we see iexplore.exe is called into action:


As soon as iexplore.exe is loaded RunVirtual jumps in and makes sure it is running within the virtual environment specified in the registry value. Now in this case we are interfacing via COM and anyone who has worked with App-V for a while will know COM is a key integration that we restrict by default, this isolation causes something that appears simple and local to fail due to RunVirtual being provisioned.

The Solution

De-isolate COM.  By taking our target package (in this case an IE plugin) back to the Sequencer and ticking the box that specifies “Allow all COM objects to interact with the local system”


This sets COM to be integrated with the local operating system and hence places no restriction on local processes that call other local processes that end up inside this virtual environment. You can of course use the Deployment_Config.xml to manipulate this setting and my good friend David Falkus breaks this down on his post here.


In summary be aware that when you utilise RunVirtual you have potential to affect the way other elements interface with your target local process. In terms of COM, could it be worth putting into sequencing standards that COM should be integrated for packages that will be involved in a RunVirtual key? Potentially, at least for things like Internet Explorer, it really comes down to the complexity of your environment but is definitely something to consider.

9 Responses to A Natural COM Side Effect of RunVirtual in App-V 5.0

  1. Andrew

    Further to this, you need to specify a common COM setting anyway if you want to use RV with more than one app-v plugin, as you need to be able to maintain a connection group which contains all the app-v addins, which is only possible if COM settings are shared across all those packages.

    13 Jun 2017 - Reply
    • Thamim Karim

      A very good point and one that will ultimately impact COM settings across members of a connection group.

      13 Jun 2017 - Reply
  2. Dinesh

    Hi Thamim,

    I have small query regarding run virtual key.I have two excel addins virtualized,and added excel.exe under the runvirtual key.The default value (appguid_versionguid) under the excel.exe is pointing to one application that is working fine.If i add one more value under the excel.exe to point other app,addin is not getting loaded into excel.Only the default value is getting loaded always.

    Could you please suggest how to use the same runvirtual key for multiple applications.

    Dinesh D

    15 Jun 2017 - Reply
    • Thamim Karim

      Hi Dinesh,

      What you are seeing is expected. RunVirtual only supports a single application reference within the default key. The work around for this is to put the various applications into a connection group and then refer to one of them in the default key, this will in turn load all apps within the connection group.

      15 Jun 2017 - Reply
  3. Raj

    Hi Thamim,
    As you said, if we go with the connection group, we are enabling the interaction with other app-v packages (addin’s) where it really does not require it. It looks like every addin is having a control on other addin’s and also we may expect the conflicts among them. May be it would lead to security or license issues as well.

    Please suggest on this.

    29 Jun 2017 - Reply
    • Thamim Karim

      Hi Raj, you could use optional user targeted packages to address this concern?

      7 Jul 2017 - Reply
  4. Raj

    Hi Thamim,

    I have one more scenario here. I am having one excel addin installed on physical machine but when I use the RunVirtual for the same excel application and the moment I open the excel , it always showing me the virtual addin’s. It looks like my excel application is always loading in virtual environment and it lost the connection with the local addin’s.
    Please could you suggest me how do I overcome this behavior if I want to use RunVirtual concept.

    29 Jun 2017 - Reply
  5. Prakash

    Hi Thamim,

    Hope you are well? We are facing an issue similar to what has been mentioned here. We used alkaneSolutions – Kae Travis , method by creating a dummy Office Suite package (http://www.alkanesolutions.co.uk/2016/05/25/using-runvirtual-present-excel-addins/#comment-10317). We only checked Allow virtual applications full write permissions to the virtual file system and this has worked however now we have come across an application (Morningstar) that requires Allow all COM objects to interact with the local system and we are now stuck. Can you see anyway round this?

    Kind regards


    31 Oct 2017 - Reply

Leave a Reply

Your email address will not be published. Required fields are marked *