RunVirtual vs. AppVVE in SP3. Who wins?


With the introduction of RunVirtual as an official feature in App-V 5 SP3, the ability to use it for user targeted packages, and the ability of SP3 to set connection group members as optional, I started wondering whether it would be possible to create a connection group for all your IE (or Office) plugins and automatically launch IE (or any Office Application) inside the connectiongroup by using the RunVirtual Registry key, and still start IE (or any Office application) in a specific Virtual Environment by using the /AppVVE: command line hook switch. What I’m thinking of is a default connection group to start IE in for all standard (non conflicting) IE-plugins and separate packages for a specific Java versions. Similar with Office, one connection group for all standard (non conflicting) Office-plugins and separate packages for special plugins (plugins with conflicting versions, conflicting settings, etc.).
Will this work? What happens when an application is started and set to launch in two different Virtual Environments by a conflict between RunVirtual and the AppVVE parameter?

I assumed that the the scenario I described would work because it makes sense to me that it would. But not having the time to test it, I let it be for a while. Until in march when I attended the European App-V User Group event in Amsterdam. There Tim Mangan gave a presentation about the various ways of launching processes in App-V Virtual Environments. This covered the use of the RunVirtual reg-key and the AppVVE command line hook switch. So I asked him the question about what would happen if I had a RunVirtual entry set for a process and started the same process with and AppVVE hook switch to a different virtual environment. Who would win in this conflicting situation?
Tim’s answer was that probably RunVirtual would win because it was designed to be a catch all function. So this kind of crushed my hopes for my scenario, but because Tim said ‘probably’, I still had a little bit of hope and decided to dig further into this.

After a quick google I found an acticle by the Gladiator (Steve Thomas App-V Guru) called ‘App-V 5: The Case of the RunVirtual Collision’ which described my conflicting scenario and stated that this would lead to a “Spinning Donut” on the starting application and the CPU spiking to 100%. So again this did not bode well for my scenario. My hopes were even less then after Tim’s session. But because Gladiator’s article was Pre SP3, I still had a tiny speck of hope. So on to testing my scenario!

For my testing scenario I created 6 sequences. 3 for testing an IE scenario and 3 for testing an Office scenario. For each scenario I created one dummy sequence to use as primary sequence for my connection group (I do this so I can always target the connection group with the same ID because this dummy sequence never has to change, so it’s ID is consistent, unlike the ID of the connection group itself or of it’s other members which may be updated or replaced) and one sequence that will be a member of the connection group and one the will not. For the IE scenario I chose FlashPlayer 17 (to be in the connection group) and Java 7.67 (to be the separate sequence). For the Office Scenario I chose two random Word plugins I found online, one that added a tab with classic menu’s (Called Classic Menu, this one would be the member of the connection group) and one that added a tab with some online search options (called Power Word, this one would be the separate sequence).
I created the connection groups (ConnectionGroup IE_Plugins, ConnectionGroup Office_Integrations) and deployed them and then Sequences to my client using a full infrastructure setup.
I only tested with RunVirtual entries in the User Registry.
To monitor in which Virtual Environment my processes start I used Tim Mangan’s App-V Manage tool.

First I created an RunVirtual Key for iexplore.exe this points to the ID of the Dummy Package in the IE Plugins Connection group.

RunVirtualRegIE

I then started IE using the default shortcut. In the App-V manage screenshot you can see that iexplore started in the IE_Plugins connection group and that the flashplayer plugin (also part of the connection group) is also started.

AVM-RunVirtualIE

Next I created a shortcut to IE the would start IE in the Virtual Environment of the Java 7.67 sequence.

IE-appvve-Shortcut

As you can see in the screenshots above, the ID supplied to the AppVVE parameter differs from that in the RunVirtual registrykey.

Starting Internet Explorer from the new shortcut lead to disappointing results. IE started slowly (with a “Spinning Donut“) and than closed before loading the homepage.

So it seemed that the Galdiator’s post still applied to SP3 and that my desired scenario was not at all possible, but…. and now comes the interesting bit (hope you still with me:-)).

What I did notice was that I could see in App-V Manage that IE was started in the Java Virtual Environment (before it closed) as you can see from the screenshot below. So the AppVVE command line hook was actually winning contrary to what Tim Mangan told me. Interesting!

AVM-RunVirtualIE-AppvveIE

– By the way in the screen shot you see that IE was also still open in the IE Plugins Virtual Environment. I also tested with IE not already open. This gave the same results.

This lead me, just out of curiosity to try what would happen if I did the same with cmd.exe instead of iexplore.exe. Would it have the same outcome? It probably would, wouldn’t it? But I had to know for sure.

So I created a RunVirtual Entry for cmd.exe to the IE plugins connection group (via the dummy package) and a shortcut with a command line hook to the Java Virtual Environment. After starting both this was the result I got:

 

Cmd-RunVirtual-Appvve

The default cmd.exe is running in the IE-Plugins Virtual Environment and the cmd.exe from the shortcut with the command line hook is running in the Java Virtual Environment. As you can see from the screenshot I can browse the directories specific to the respective Virtual Environments.

So next I tried notepad.exe. Same results! AppVVE wins.

After this I was ready to try my Office Scenario. As with IE I created a RunVirtual Key for WinWord.exe to the connection group and a shortcut to the separate sequence, in this case the ‘Power Word’ sequence. At first it did not seem to work with Word. I had started Word using the default shortcut, which launched it in the Virtual Environment Supplied by the RunVirtual entry and then started Word again using the AppVVE parameter. Although Word did not close when starting with the AppVVE parameter, it did not launch in the supplied Virtual Environment. Instead it started in the Environment supplied by the RunVirtual Key. But then I remembered that when Word is already running it does not start a completely new process when started again. This was backed up by not seeing a new process appear in App-V Manage. Supplying the /w parameter to WinWord.exe forces it to start a completely new Process. After that I got the same results as with cmd.exe and notepad.exe, the AppVVE command line hook takes precedence over the RunVirtual entry.

WinWord-RunVirtual-Appvve

I tested my scenario with Office 2010. I also did some quick testes with Office 2013, and did not find any different results.

There is one other interesting thing I noticed. The Virtual Environment supplied by the AppVVE parameter adds the ability to Word to do a online search from a Word Tab (don’t ask about the usefulness of this, but that’s what is does). When you do this Internet Explorer is started. Normally when you start a process from another process running in a Virtual Environment, the started process runs in the same virtual Environment as the process it was started from. If found this not to be the case when the started application has an associated RunVirtual Key. In that case the started application is started in the Virtual Environment designated by the RunVirtual key. In my scenario I still had a RunVirtual key set for iexplore.exe from my previous test, so when I did a search from the PowerPack tab in Word and IE opened, it opened in the IE_plugins Connection group instead of in the Power Word Virtual Environment. This behaviour can be both an advantage as well as a disadvantage depending on your needs. In my case it was nice to be able to use flash in the started IE but in situations where the started application and the application it was started from have to be integrated the integration will fail because they are not in the same virtual environment. So this is something to take in to account when using RunVirtual.

Conclusion

Who wins?
Well we have clear winner! In the case of a conflict between RunVirtual and the AppVVE commandline hook, AppVVE wins. The process is started in the Virtual Environment supplied by the AppVVE parameter. I only tested with SP3. Whether this was also the case pre SP3, I don’t know, but I think it only works with SP3. According to Gladiator’s article it didn’t work with SP2, but his article only covered Internet Explorer and that still has issues in SP3. See below.

Any Issues?
It does not work with Internet Explorer. When IE is started with both RunVirtual and AppVVE a 100% CPU spike is generated and Internet Explorer closes automatically after a few seconds. I don’t know why this happens because different IE processes can run in multiple Virtual Environments at the same time when using just different AppVVE parameters. I thought it might be caused Dynamic Virtualisation, but I also tested with Dynamic Virtualisation disabled with the same issue as a result.

Any other things worth noting?
If a process has a RunVirtual registry entry associated and it is started from another virtualized process, the started application will run in the Virtual Environment set by the RunVirtual Key. The differs from normal behaviour where processes started from a virtual process run in the same Virtual Environment.
To Launch an application in a separate Virtual Environment it needs to spawn a new process when starting a new instance of the application if is already running. WinWord for instance does not do this by default. If not the application will always remain in the Virtual Environment the already running instance is in.

Can my scenario of one connection group with plugins for an application and starting the application by default in that connection group, while also by exception starting the application in a specific Virtual Environment be applied?
Yes, for any application as far as I can see,  except for Internet Explorer, and that’s a shame because IE is the a prime candidate for this scenario. So hopefully Microsoft will address this issue in a future release.

Update: Please see my comments below with regards to IE 11.

 

Tags: , , , , , , ,

About Casper van der kooij

Technical Lead Application Packaging @ Conclusion Future Infrastructure Technologies, Utrecht, The Netherlands.

4 responses to “RunVirtual vs. AppVVE in SP3. Who wins?”

  1. Dan Gough (@packageologist) says :

    Thanks for providing the detail. Appvve has always taken precedence over RunVirtual and worked for me, so I don’t think anything has been fixed regarding this in SP3 – although I would wager that it all worked including IE until SP2 came along!

  2. Casper van der kooij says :

    Just after publishing my article I realised that I had been testing with IE 9 not with IE 11 :-(.
    So ran some tests with IE 11 and found that IE 11 does not (completely) close in the case of a RunVirtual and AppVVE conflict.
    With IE 11 I found that one iexplore.exe process is started in the Virtual Environment designated by the AppVVE parameter and a second iexplorer.exe process is opened in the Virtual Environment designated by the RunVirtual Key after which the first process (in the AppVVE environment) is closed and another iexplore.exe process is opened the RunVirtual Environment. In the end IE is running in the RunVirtual Environment.
    So in this case RunVirtual is actually winning. Although this is better than a crashing IE I would rather see it start in the AppVVE environment as is the case with other applications.

    B.t.w. All my tests were done on Windows 7 Enterprise SP1.

  3. LongtimeUser says :

    Great in-depth experiment and write-up.

    IE process model is different to other applications – not one process per window, but one master process per user, and then individual windows or tabs take up threads in IE subordinate processes attached to the main process – overall, a monolithic structure. I think it probably works that once 4 or 8 or something threads in one IE subordinate process have been spoken for, a new IE subordinate process opens up with more threads to host more windows/tabs, until it too is filled up…and such subordinate processes shift and balance threads to keep it all going. Sounds like IE11 has just spawned a new subordinate process from the user’s main thread, and it is therefore linked to the master process, and the virtual environment it was started in (off RunVirtual).

    So my guess is that getting App-V to tame IE11 by, say, dividing IE11 into multiple, separate ‘monolithic’ proces structures so it can be in different virtual environments would be a challenge! (parallel universes?)

Leave a reply to Casper van der kooij Cancel reply