Nov 03, 2016 - 22 Comments - Virtual Vibes -

Real World RunVirtual and APPVVE with App-V 5

Hi All,

It’s been a while since I last posted as I have been really busy working with clients over the last few months. I just wanted to take this opportunity to share with you a real world example of how I have recently used RunVirtual and APPVVE to enable a client to have a more flexible experience with App-V.



At this client I was working with a team of developers who used a locally installed application called PowerDesigner to develop data models against a locally installed Sybase 64 bit database. However the developers wanted to also be able to test their data models against Sybase 32 bit on the same machine. Of course it wasn’t technically possible to have both 32 and 64 bit versions of Sybase installed locally on the same machine so they asked me if App-V might help…

App-V Delivery


The first step was to package and deliver Sybase 32 bit as an App-V package to the developers machines. However this on its own would mean launching PowerDesigner locally would still only ever interact with Sybase 64 bit which was also locally installed.



By provisioning the RunVirtual registry key on the machine as above we were able to dictate that the App-V client listens for PowerDesigner.exe and intercepts its launch to direct it into the virtual environment of the Sybase 32 bit App-V package. This would give the local PowerDesigner application full sight of the Sybase 32 bit and enable the developers to work with it. However a side effect of this approach is that PowerDesigner would lose sight of locally installed Sybase 64 bit. As RunVirtual operates on a process level there would be no flexibility in launch, PowerDesigner.exe would always launch in the bubble of Sybase 32 bit and developers would not be able to switch to using 64 bit which was something they wanted to do.

In these initial stages we provisioned these keys manually on the machine however we also wanted a better way to manage connectors, if we stuck with RunVirtual as a solution we may have chosen to use Group Policy Preferences to write this in, or even used a script within the Sybase 32 bit package to write this down. However the requirements called not only for something manageable but a solution that would allow flexibility between using local Sybase 64 bit and virtual Sybase 32 bit so our attentions turned to APPVVE.



By removing the RunVirtual registry key we were able to implement APPVVE by provisioning a separate shortcut with the parameter to launch PowerDesigner.exe inside the bubble of Sybase 32 bit. We also left the standard shortcut for PowerDesigner.exe which would of course only see the local Sybase 64 bit, this gave users the flexibility of launching with visibility of Sybase 32 or 64 bit depending on what they were developing or testing. In contrast to RunVirtual which is more a blanket interception of process which is great for ‘user unaware’ scenarios, APPVVE gave us the granularity in a ‘user educated’ scenario where they would intentionally use one shortcut over another for a given outcome.

We initially provisioned the additional APPVVE shortcuts manually on developers machines but as the solution became popular we required a more manageable way to deliver them. We also hit another management related issue when we upgraded Sybase 32 bit:


As illustrated above, whenever the Sybase 32 bit package was upgraded or patched we would end up breaking our APPVVE shortcut across the developers machines. This is because the APPVVE argument uses both package GUID and version GUID to understand which virtual environment to launch within, upgrades to Sybase of course would change the version GUID and subsequently the APPVVE shortcut would fail to resolve and would launch PowerDesigner.exe outside of the bubble. The inability to use a wildcard for version in the APPVVE switch meant we needed to find another solution to make it less sensitive to version changes.

The concerns around general implementation of APPVVE and handling of updates to packages led us to find an overall more manageable solution for delivery.



The final phase of refinement led us to remove the dependency on manual delivery of shortcuts and removing the sensitivity on updates breaking the APPVVE connections. We achieved this by the following steps:

1. Delivering a stub package which delivered the shortcut to PowerDesigner to the local machine. We achieved this by sequencing a dummy package with a folder and file in the VFS, in the package editor we then added a shortcut which pointed to the local PowerDesigner.exe in C:\Program Files. Interestingly when this package is delivered to the machine, the App-V client knows to add the APPVVE parameter to the shortcut as long as it finds PowerDesigner.exe locally as expected. It automatically adds on the APPVVE switch to reference the package so there is no need to know this upfront.

2. Delivering a connection group that included both the stub package and the Sybase 32 bit package. We made sure the connection group was set to ‘use any version’ for the Sybase package so it would not be sensitive to updates.

The combination of the above meant that when a user needed the ability to launch PowerDesigner with Sybase 32 bit they would call the help desk and request both the Sybase 32 bit package and the relevant stub connector package. The stub package would deliver them a shortcut with the APPVVE switch, which refers to the stub itself. As the stub would be in a connection group with Sybase 32 bit, PowerDesigner would see the virtual environment over the local install of Sybase. Whenever Sybase 32 bit is updated, the APPVVE shortcut would continue to work as it only ever refers to the stub package.

Although the approach above might appear quite complicated it worked really well for my client who arrived at a solution that not only made the delivery of APPVVE ‘connectors’ easier to manage but also removed the sensitivity of updating the dependant packages. For the software deployment team it also made a lot on sense as when the relevant request came in they could deliver the equivalent connector stub package to achieve the desired behaviour.


22 Responses to Real World RunVirtual and APPVVE with App-V 5

  1. RichT

    Great blog. I’ve used that method for IE,word,excel add-ons etc. As the Runvirtual key doesn’t provide flexibility where more than one app needs to launch in the word bubble for instance

    3 Nov 2016 - Reply
  2. Irfan Kucuk

    Really interesting to see a connection group used to circumvent the limitations of the APPVVE Parameter. Excellent Article!

    3 Nov 2016 - Reply
  3. manju

    Thanks for sharing.Very interesting Article..

    3 Nov 2016 - Reply
  4. Raj

    It’s a great blog. Thanks for the work around.

    I have a locally installed application, which has multiple dependencies (add-on / plug-in) and needs to be App-V’ed. So will the above mentioned scenario suffice my requirement???

    3 Nov 2016 - Reply
  5. Rory

    Cool story, bruh! 🙂 First time I noticed my sequenced app automatically used appvve when pointing to a local app I did a double take. Thanks for sharing!

    3 Nov 2016 - Reply
  6. Stan

    I use a dummy stub package referenced by RunVirtual and have that stub package part of whatever Connection Group I need.

    4 Nov 2016 - Reply
  7. Kay Tomas

    Great blog! Does anyone know why “iexplore.exe” hates to be involved with app-v? Other scenarios with local installed applications with runvirtual og appvve works like a charm. If you do this with Internet Explorer the browser does not work properly after the first run. We still need to use IE11 in our environment but virtual plugins and IE is not actually friends!

    4 Nov 2016 - Reply
    • Dan Gough

      IE 11 needs its first launch per user per machine to happen outside the virtual environment. It’s a bug, this issue never existed with IE10 or earlier. Once sufficiently motivated I may get to the bottom of this one as it doesn’t appear that Microsoft are interested in fixing it! Here’s a workaround I have used before:

      4 Nov 2016 - Reply
      • Thamim Karim

        Man, I thought this would if been fixed by now. Thanks for clarifying the current state of play with this bug Dan.

        5 Nov 2016 - Reply
      • Kay Tomas

        Thank you for clarifying Dan! 🙂

        7 Nov 2016 - Reply
  8. Trentent Tye

    An alternative to using the /appvve switch is to use powershell to launch your package. If you use the package name it will open the newest published package on the system so you don’t have to mess with version GUID’s whenever a package is updated.
    Start-AppvVirtualProcess -AppvClientObject (Get-AppvClientPackage *APPNAME*) cmd.exe

    6 Nov 2016 - Reply
    • Thamim Karim

      Thanks for sharing, a valid alternative approach! Also great work around for XenApp stripping out the APPVVE switch…

      8 Nov 2016 - Reply
  9. Alex Sweserijnen

    Would two user accounts each with it’s own CurrentUser RunVirtual setting also work?

    8 Nov 2016 - Reply
    • Thamim Karim

      Yes, this would work also. Would just need to ensure that Sybase was published to the user.

      8 Nov 2016 - Reply
  10. Marco Schmitz

    Great solution, thanks for sharing.

    24 Mar 2017 - Reply

Leave a Reply

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