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.

Scenario

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.

RunVirtual

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.

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.

Management

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.