Sequencing Java – The Definitive Guide Part 2
(Problems with App-V 5.0 SP2)

In Part 1, I discussed the reasons for virtualising Java along with some of the common problems, with a recipe to ensure the virtual Java instance is suitable isolated from any local installations. This part discusses how the new App-V 5.0 SP2 functionality negatively impacts the usage of virtualised Java plugins in a typical enterprise environment.

As of SP2, App-V 5.0 handles Browser Helper Objects and ActiveX controls differently – if the package is published globally (i.e. per machine) rather than per user, these components are locally integrated so that the native Explorer and Internet Explorer processes can see them without having to launch these processes inside the virtual environment. On the one hand, this is great new functionality, meaning you can now virtualise your primary instances of Adobe Reader, Flash Player, etc. On the other hand, there is no obvious way of disabling this functionality on a per-package basis. One of the selling points of a virtualisation solution is that you can deploy applications without fear of messing up anything that is locally installed. By beginning to integrate components locally, App-V is beginning to cross over into the dark side! This new functionality works for the relatively simple ActiveX controls mentioned above, but for some reason it does not work with Java possibly due to its more complex launch process, where in addition to having multiple CLSIDs registered for the plugin, there is an additional Browser Helper Object ‘SSV Helper’. As far as I can gather, this is responsible for  stepping in to deliver the highest available plugin version unless a specific version is requested (hence the acronym Secure Static Versioning). However, after virtualising Java 6 and publishing globally to a machine that has Java 7 installed (which is a typical usage case), then the Browser Helper Object from v6 ends up overriding the locally installed version:

Java 6 SSV Helper Add-on

Ignoring App-V for a moment, if you install Java 6 on top of Java 7, you often see a UAC prompt upon the next launch of the Internet Explorer due to ssvagent.exe wanting to run (I assume it is trying to update settings to re-register Java 7 as the default plugin). Exactly the same thing happens when layering the virtualised Java 6 on top of the local Java 7. This is what is shown after attepting to launch the local Internet Explorer:

Java UAC Prompt

This is a really annoying one, because if the user does not have admin rights, that prompt will appear every time they open a new browser tab until an admin comes along and authorises it. In addition another new security prompt appears, but this one can be got rid of via the checkbox:

Internet Explorer Security Prompt

The proper solution to this would be to modify DeploymentConfig.xml to disable the subsystems related to ActiveX controls and Browser Helper Objects, but unfortunately I have not yet been able to figure out how to do this.  I’ve tried using the tag element names from the internal manifest and putting them in the config file, but it failed to import every time due to invalid XML. Either I am doing something wrong, or the new elements have not yet been added to the config.xml schema! The current workarounds for this are:

  • Ensure all Java packages are deployed per-user rather than per-machine / globally published. This way the problematic components will not be integrated locally. Bear in mind that if you are deploying via the MSI produced by the sequencer, that this publishes the app globally.
  • If this is not feasible then sequence the Java plugins using App-V 5.0 SP1. Bear in mind that the MSI packages produced by the SP1 sequencer do not install without one of these workarounds:
  • Reinstall the local Java version each time after publishing a virtual instance.
  • Alternatively, these new App-V 5.0 SP2 features can be switched off – but this is a last resort as it affects all packages on the system.  This setting disable Shell Extensions, Browser Helper Objects, and Active X controls, and must be set before publishing the application:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Virtualization "EnableDynamicVirtualization="=dword:00000000

  • Similar to above, there is another setting that controls which processes are able to integrate with these new dynamic virtualisation features. If you want to keep the shell extensions working in Explorer, and just disable the Internet Explorer stuff, you should be able to do this by removing iexplore.exe from the following multi-string value:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Virtualization "ProcessesUsingVirtualComponents"= REG_MULTI_SZ

If you’re feeling experimental, some additional (and brutal) workarounds I have thought up but not yet tested are:

  • Running a PublishPackage script to launch the command <Java Install Dir>\bin\ssvagent.exe -new -high. This should prevent the UAC prompt by running the command pre-emptively.
  • Running a script to temporarily switch the EnableDynamicVirtualization setting off then on again after importing the package.
  • Running a PublishPackage script to reinstall the local Java to overwrite any unwanted settings coming from the App-V package.
  • Replacing the manifest in the virtualised ssvagent.exe to change the requested execution level to asInvoker. This way it would not show a UAC prompt, and could either fail gracefully or horribly when it finds it’s unable to do what it wants to do.
  • Delete the SSV Browser Helper Object from the virtual package. The keys appear to be located under HKLM\SOFTWARE\Microsoft\Windows\Explorer\Browser Helper Objects. This should stop it being integrated locally, but the downside is that it will not be available within the virtual environment either, where it may be needed – in fact a virtualised Java 6 might even then start using the SSV Helper from a local Java 7 installation which could have unwanted effects.

Additional Issues Using App-V 5.0 SP2 Alongside 4.6.x

An additional issue has come about, regarding using App-V 5.0 SP2 & 4.6 on the same machine.  Basically, if you had any 4.6 sequences with shortcuts to Internet Explorer, installing 5.0 SP2 breaks them. This is due to the new dynamic virtualisation features, it appears that App-V 5.0 steps in where it isn’t wanted and Internet Explorer does not launch in the 4.6 virtual environment.  The original post in German from Sebastian Gernert can be found here, and a translated page here.

Click here to continue to Part 3!

4 responses on “Sequencing Java – The Definitive Guide Part 2
(Problems with App-V 5.0 SP2)

  1. Deepak

    Hi Dan,

    I am having a different but similar issue related to Java sequencing.

    For one of our in house applications we require a older version of java where as we have higher version of Java native installed on a machine.

    We sequenced older version of java & established a connection group with our in house url. Our in house app site now works fine. I noticed that the older java now rewrites the native classes registry of FTA say example ‘JNLP’.

    Now when I browse for some website through IE, it tries to open JNLP files & looks into App-V java instead of the native. The new website then gives me a message saying java installed is old one and crashes out.

    Re-installing native java again resolves this issue but is there any way to avoid this during sequencing? Microsoft suggested to disable JNLP FTA from the deploymentConfig.xml but I’m vary about that idea.

    1. If you followed my recipe in Part 1, I recommend to delete these file associations during sequencing for precisely this reason! You can either do that, or disable them via the config file as Microsoft suggests.

      If you have a web apps that need to open both local and virtual Java versions by the .jnlp file association, then that is not an easy fix. A filetype can only be registered to open with one application at a time. You might be able to use a pre-launch script to modify the .jnlp file association on startup, but this wouldn’t be a robust solution.

      It is recommended to remove the file associations with .JAR and .JNLP files unless this package is going to be the main version of Java. If a local version of Java is installed we do not want this virtual package to override its file associations. To do this, delete the following registry keys:

      [-HKEY_CLASSES_ROOT\jarfile\Shell]
      [-HKEY_CLASSES_ROOT\JNLPFile\Shell]

  2. Hi Dan,

    Thanks for these two great extended discussions of sequencing Java.

    Has anyone developed a similar recipe for Sequncing Java 1.8?

    Thanks,

    Doug

    1. I sequenced early version of 8 and they were exactly the same as 7. I believe later versions do not have the medium security level any more so you have to use the exception list for unsigned applets, but this was best practice beforehand also.

      The only thing I know to be broken is the script that automatically extracts the MSI from the exe no longer works with the recent Java builds!

Leave a Reply