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

Share on facebook
Share on twitter
Share on linkedin
Share on reddit
Share on stumbleupon

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:

runv

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:

error

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:

ierunning

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”

allowCOM

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.

 Summary

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.

Leave a Reply.

9 thoughts on “A Natural COM Side Effect of RunVirtual in App-V 5.0”

  1. 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.

  2. 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.

    Regards
    Dinesh D

    • 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.

  3. 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.

  4. 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.

  5. 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

    Prakash

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.