Sequencing Java – The Definitive Guide Part 1
(Introduction and recipe)

Java is a necessary evil in today’s enterprise desktop. It is required by various business critical applications, yet it is the number one target for malware, made worse by the fact that people don’t always apply the latest security updates because they have an application that depends on an older version (or more commonly, are simply not bothering to regularly test their applications with each new release hoping that nobody notices!).

A great solution to this is to use App-V to virtualise older Java versions then link them to the applications (or browser shortcuts) that depends on them. Then the locally installed Java version can be kept up to date, or even removed entirely. There are a few problems that I have commonly seen with this:

  1. The solution does not always work as intended. Mostly the browser opens in the virtual environment with the desired version of Java, but sometimes it can ignore that and open the locally installed version. Sometimes the browser can hang or crash. Also to make it more complicated, these issues seem to affect some users and not others.
  2. App-V 5.0 SP2 now virtualises ActiveX control and Browser Helper Objects and presents them to the local Internet Explorer. Unfortunately this causes issues when we are virtualising legacy plugins and do not want the native browser to see them!
  3. Once the browser has been opened in the virtual environment with a legacy Java version attached, there is nothing to stop the user continuing to use the browser window to go about their daily business, where they are an open target for malware.
  4. There is no automatic redirection taking place, so the users have to remember which links they can get away with simply typing in and which ones they have to dig around in the start menu for. ThinApp has a solution for automatically redirecting URLs to specific packages, and there are third party solutions to the problem such as Browsium Ion, but nothing available to solve the problem for App-V.

This post is about solving the first problem by showing the results of my testing and sharing what has now become my standard recipe for sequencing Java.

The two main causes of the complications described in the first point above are:

  • If Internet Explorer is already running outside the virtual environment, attempting to open a new page can sometimes pass the request to the already running process rather than creating a new Internet Explorer process inside the bubble.
  • Insufficient isolation causing Internet Explorer to see multiple versions of Java, and in some cases attempt to load the latest rather than the desired legacy version.

Ensuring IE Gets Loaded Within The Virtual Environment

This one is pretty simple, and was originally shown to me by Colin Bragg (unfortunately the original blog post seems to have vanished). Add the –noframemerging parameter to the Internet Explorer command line, e.g:

C:\Program Files (x86)\Internet Explorer\iexplore.exe -noframemerging http://javatester.org/version.html

This forces IE to open in a new process inside the virtual environment.

Ensuring IE Loads The Correct Java Version

Sometimes even when you employ the trick above to ensure IE is running inside the bubble, certain conditions can cause the browser to load the locally installed version instead of the virtualised one. This is down to the virtual instance not being sufficiently isolated so that it actually sees both versions of Java.

Here are a couple of blog posts that describe the issue each with different solutions:

http://stealthpuppy.com/juggling-sun-java-runtimes-in-app-v

http://blogs.technet.com/b/virtualworld/archive/2007/08/14/troubleshooting-softgrid-with-process-monitor.aspx

I performed some tests to first of all reproduce the problem reliably, then to see if the proposed solutions above fix the problem. To test this out, the Java test page at http://javatester.org/version.html was used. This uses the deprecated <applet> tag, and in all instances tested, the virtualised Java runtime was loaded rather than the locally installed version.

Then to test the results using the <object> tag, a customised html file was used using the Java class file from javatester.org:

http://javatester.org/JavaVersionDisplayApplet.class

With a locally installed Java 7 and virtualised Java 6, at first this worked in the same way, loading Java 6 in the bubble. However, after launching the local Java 7 just once, the results changed. On Windows XP, Java 7 was loaded in the virtual environment instead of v6, and on Windows 7, Internet Explorer stopped responding. The java_version attribute is the important one here, and it accepts the following input types:

  • Selecting a specific version:
    • <param name=”java_version” value=”1.5.0_11″>
  • Selecting the latest version from a particular family:
    • <param name=”java_version” value=”1.5*”>
  • Selecting the latest version available with a defined minimum version:
    • <param name=”java_version” value=”1.5+”>

The value of 1.5+ was making Internet Explorer attempt to load the locally installed v7 instead of the virtualised v6, which in some tests caused the browser to hang. If a value of 1.6* was specified, the virtualised Java 6 loaded correctly.

Bringing up the virtual copy of the Java Control Panel highlighted the problem further by showing two versions of the Java plugin active:

Multiple Java versions

I tried the isolation techniques in the posts above but unfortunately could not get them to work to fix the problem reproduced as above. I even wrote a script to generate a huge number of future proof CLSID values and combined the registry entries from every available version of Java into a mega-anti-JRE but it still did not help.

The solution for me was not to be found in the registry at all, but in the config file deployment.properties. The folder hosting this file was not in the VFS of my virtual package, so when Java was launched it was writing this file to the local file system, where it was being shared with the local Java install.  This is why everything worked fine until I launched the local Java, after which it always went after the latest version. This also explains why some users suffer from issues and some do not!

Important points of note about this file:

  • The file is located in a different place on different operating systems:
    • Windows XP: %APPDATA%\Sun\Java\Deployment
    • Windows 7: %USERPROFILE%\AppData\LocalLow\Sun\Java\Deployment
  • If you installed Java via the vendor exe, this extracts the MSI to the locations listed above. If you install via the extracted MSI, this folder structure is not created and therefore not captured.
  • If you launch Java via the browser, Java Web Start, or the Java Control Panel, it will re-create the folder structure and create a new deployment.properties file.
  • The AppData\LocalLow location is excluded by default in App-V 4.6. It is not actually in the exclusion list, but removing the %CSIDL_LOCAL_APPDATA% exclusion (which equates to AppData\Local) also covers this folder.  Nothing needs to be changed in App-V 5 as Root\VFS\LocalAppDataLow is included by default. No changes are required on XP either, as %CSIDL_APPDATA% is also included by default.
  • You don’t necessarily need to capture the deployment.properties file (unless you want custom settings in there) as it gets recreated automatically. All you need is for the Sun folder to exist in the VFS to ensure that read/write operations are contained within the bubble rather than redirected to the local file system.
  • It should be possible therefore to create a universal package by sequencing on Windows 7 32-bit and creating dummy folders %APPDATA%\Sun and %USERPROFILE%\AppData\LocalLow\Sun whilst monitoring (because 64-bit packages cannot be used on a 32-bit OS and XP does not have the LocalLow folder).

System Config Files

As well as the deployment.properties file that gets created under the user profile, system administrators can also create a system-wide config file, the settings in which can override the user settings.  For example, you may have configured your virtualised Java to run in medium security mode to fix a problem with a certain website.  If an administrator has deployed a system config file to force Java to run in high security mode, this would override the package settings and break the application.  For this reason, I recommend that you either create your own system config file within your package, or just create a dummy folder set to override to hide the local one.

The default path for this config file is C:\Windows\Sun\Java\Deployment\deployment.properties. The location of this file can be changed by supplying an additional file C:\Windows\Sun\Java\Deployment\deployment.config (see recipe).

Another note about deployment.properties is that you may be tempted to create a barebones config file in the user profile containing just the settings you need. However, from my experimentation, I have found that there is a property named deployment.version (which does not match up with the actual Java version!), which if incorrectly set, causes the settings to be erased and replaced with defaults.  This is another reason I recommend putting all desired settings in a system wide config file.

Java 7 Security Features Issues

Java 7u10 introduced a new feature which causes the Java plugin to check if an updated version exists before it loads. Then in 7u17 they also added a built-in expiry date so the plugin can complain that it is out of date even if you block it from phoning home at the firewall! If your Java plugin believes it is out of date, this is what you will see first:

Java Update Prompt

Even if you check the box at the bottom, it only ignores the current release and will just pop up again when it detects another Java update has been released. I have seen posts describing ways to suppress this (such as this one) but I did not have any luck with any of them – the only method that worked for me was to set the registry keys that are created by the action of dismissing the dialog:

[HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties]
"deployment.expiration.decision.10.45.2"="later"
"deployment.expiration.decision.suppression.10.45.2"="true"

The keys above relate to Java 7u45. Yes, this is yet another versioning system being used by Oracle for the same product, don’t ask my why it says 10.45!

Another point of note is that these keys get wiped out if you open and close the Java Control Panel, so do not launch it after setting them!

If you are running 7u21 or above, you will run into another hurdle if your applet is unsigned (such as the one used at Javatester.org):

Javatester with out of date JRE7

To get past this you need to lower the security level to medium by setting deployment.security.level=MEDIUM in your deployment.properties file.  Alternatively, Java 7u51 offers a way to do this for specific URLs by adding them to a text file named exception.sites which is then placed in the Sun\Java\Deployment\Security folder.

We’re not done yet! The next popup you will see still prompts you to update before running the plugin:

Javatester with out of date JRE7 - medium security, updates requested - 7u21

There does not seem to be an easy way to suppress this one except for launching the plugin during sequencing and checking the boxes to not show again. This saves a file under the user’s Sun\Java\Deployment\cache folder, but the format of the folder structure does not offer an easy way to automate this.  At least as of Java 7u40, there is a deployment.properties setting you can configure to at least get rid of the update option, deployment.expiration.check.enabled=false, which then changes the dialog to this:

Javatester with out of date JRE7 - medium security, updates disabled 7u40

So, security settings in Java 7 are a bit of a mess!

Disabling Java Updates

There seems to be a lot of differing advice around regarding how to disable Java updates, so I decided to get to the bottom of it once and for all, here are my findings:

  • All of the Java MSI packages contain three properties related to automatic updates, AUTOUPDATECHECKJAVAUPDATE, and JU.
  • These properties only seem to affect versions v5u11 to v6u18, where setting any one of them to zero prevents a Run registry key being created which launches the Java update scheduler jusched.exe on startup. This isn’t majorly important as App-V ignores these keys, but I set all the properties to zero anyway.
  • Java v6u19 onwards separates the Java Update components into a separate MSI package, and both are installed by the main setup exe. If you extract the main MSI and only install that, then you do not have to worry about it.
  • The Java Control Panel will display an update tab with updates checked by default for v5u11 to v6u18, and also for v6u19 onwards if the update components are installed. This entire tab can be hidden by setting a registry key (see recipe).
  • If you’re going back that far, updates appear to be disabled by default for v5u10 and below.

Sequencing Recipe For Java Runtime

WARNING! – If sequencing using App-V 5.0 SP2 and plan on using global (i.e. per-machine) publishing, you should read this post first and consider creating the sequence using SP1 instead!

If Java is sequenced on a 32-bit machine it will work on 64-bit, but it will not be usable on 32-bit if sequenced on a 64-bit machine. I recommend using Windows 7 32-bit to create these packages if portability between 32/64-bit is desirable.

Pre-Sequencing Steps

Download The Source Media

The various versions of Java can be downloaded from the following locations:

Java 7 downloads: http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase7-521261.html

Java 6 downloads: http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase6-419409.html

Java 5 downloads: http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase5-419410.html

Java 4 downloads: http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase14-419411.html

Java 3 doesn’t seem to work on Windows 7 so is being ignored.

Extract The MSI Packages

To extract the MSI package (and Data1.cab file), simply launch the executable (no need to install it) then look for the files under the following locations:

  • %USERPROFILE%\AppData\LocalLow\Sun\Java (for versions 6 & 7 on Windows 7)
  • %APPDATA%\Sun\Java (for versions 6 & 7 on Windows XP)
  • %LOCALAPPDATA%\Sun\Java (for version 5)
  • %TEMP%\_isXXXX (for version 4)

Alternatively, the download and extraction process can be automated using this method described by  Remko Weijnen:

http://www.cupfighter.net/index.php/2014/01/100-automation-of-java-updates/

I have modified this script and added a .cmd file wrapper so that you can drag’n’drop the Java exe installer onto the cmd file and extract the MSI automatically, although it only works on v6u19 and above. Download the script here!

It is possible to use the default provided exe to produce the virtual package, however:

  • Extra steps may need to be taken to disable updates.
  • Care must be taken not to install the Ask toolbar, which is bundled in some Java releases.
  • The source MSI that gets extracted during installation should be manually deleted to save space in the resulting sequence.

Modify The Exclusion List

The following path should be added to the exclusion list for all operating systems and App-V versions:

C:\Windows\Installer

I don’t recommend adding this to a standard template as sometimes icons are stored in here and excluding them can have detrimental effects, but it is safe to do so with the Java installers.

Then, if you are sequencing on Windows Vista/7 or above using App-V 4.6, you will need to remove the following exclusion:

%CSIDL_LOCAL_APPDATA%

Installation Location

In App-V 4.6, it should not make much difference whether Java is installed to the virtual mount drive or the VFS. However, all testing was done with Java installed to its default location in the VFS, as this should in theory provide extra isolation by masking the locally installed Java files since the root Java folder gets set to override.

In App-V 5, it is recommended to install Java to its default location, but set the PVAD (Primary Virtual Application Directory) in this case to a random folder e.g. C:\<PACKAGENAME>. This ensures the main Java folder is set to override as described above, but is also advised due to a strange issue that was sometimes seen when installing into the PVAD, where the root folder contained nothing but empty folders mirroring the same folder structure filled up in the VFS; the net result of this was a bunch of empty folders when viewed on the client.

Monitoring Steps

Installation

Install the extracted MSI. Example command line:

msiexec /i jre1.6.0_45.msi /qb AUTOUPDATECHECK=0 JAVAUPDATE=0 JU=0 ADDLOCAL=ALL

ADDLOCAL=ALL is optional but it enables extra non-default features in Java 4 & 5.

Configuration

Set the following registry key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy
(on 64-bit Windows)
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy]
(on 32-bit Windows)

"EnableJavaUpdate"=dword:00000000

Next, set up your config files.  Create a folder %USERPROFILE%\AppData\LocalLow\Sun (Windows 7) or %APPDATA%\Sun (Windows XP) if it does not already exist. If sequencing on Windows 7 32-bit, creating both folders should result in a package that works on all platforms.

Create a file C:\Windows\Sun\Java\Deployment\deployment.config with the following contents:

deployment.system.config = file:\\C:\\WINDOWS\\Sun\\Java\\Deployment\\deployment.properties

Then create a file C:\Windows\Sun\Java\Deployment\deployment.properties. The contents of this will be optional depending on your Java version and desired settings, but here is an example:

deployment.expiration.check.enabled=false
(to prevent the upgrade button in the dialog when running unsigned Java code. Only applies to Java 7u40 and above.)
deployment.security.level=MEDIUM
(required to enable expired versions of from Java 7u21 to run unsigned code)
deployment.security.level.locked
(this forces the security level to override the setting in the user deployment.properties and disables the slider in the Java Control Panel)

To suppress additional update prompts in Java 7u10 and above, set the following registry keys, replacing the 45 in the version field with your Java update version (e.g. 10.51.2 for Java 7u51):

[HKEY_CURRENT_USER\Software\AppDataLow\Software\JavaSoft\DeploymentProperties]
"deployment.expiration.decision.10.45.2"="later"
"deployment.expiration.decision.suppression.10.45.2"="true"

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]

An extra thing I like to add is a modification to the browser title bar as a visual indicator that the browser is using a different version of Java. Unfortunately the title bar is no longer displayed in IE9 onwards, however the text can still be seen when hovering the mouse over the icon on the taskbar.

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
"Window Title"="Internet Explorer with Java 6u45"

Some versions of Java create shortcuts which need to be deleted:

  • Java 4 – Delete Desktop\Java Web Start and Start Menu\Java Web Start shortcuts
  • Java 7 – Delete Start Menu\Java shortcuts

I’ve automated all of these steps in a batch file which you can download here.

Post-Monitoring Steps

Delete any captured applications and create a new application pointing to the Java Control Panel. The location for this in Java 6 x86 on a 64-bit machine is:

C:\Program Files (x86)\Java\jre6\bin\javacpl.exe

OSD settings

The control panel is in a similar path for versions 5, 6 and 7, although the 64-bit Java versions are located under C:\Program Files instead of C:\Program Files (x86).  For Java version 4, the control panel is named jpicpl32.exe (also it has no icon by default but one can be set manually).

Modify the properties as per your own naming standards. Bear in mind that for App-V 4.6, the name + version joined together needs to be unique for each application, as does the OSD filename. It is recommended to append x86 or x64 to the version number at this point to prevent naming conflicts as a result of virtualising both 32-bit and 64-bit variants of the same Java release.

A shortcut is added by default when adding a new application, so this should be removed by expanding Shortcuts, pressing Edit Locations, and unchecking the box for the Start Menu.

In App-V 5, the applications are added and shortcuts are modified in the very last tab of the final sequencing stage.  The sequencer has a bug that means shortcuts cannot be edited, but they can be removed by pressing the delete key.

If sequencing Java 7u10 or above and you have set the registry keys to suppress the update prompt, remember do not launch the Java Control Panel as it will erase those settings!

Click here to continue to Part 2!

57 responses on “Sequencing Java – The Definitive Guide Part 1
(Introduction and recipe)

  1. Pingback: A collection (so far) of #APPV 5 Client file visibility and blocking information | Confessions of a Guru

  2. Björn

    Brilliant!

  3. Christian Leber

    Hey Dan,
    I tried to publish Java 7u51 to an Win8.1 PC with AppV V5.0 SP2 and the “RunVirtual” feature ( http://stealthpuppy.com/app-v-5-0-delivers-internet-explorer-plugin-nirvana/ ), but it never works.
    It loads the AppV Package (download finishes as soon as I start the IE, either x86 or x64), but the plugin never is visible in the IE. Do you have any direction to point me too?
    Thank you!
    Kind Regards
    Christian

    1. Is the app published globally (per-machine)? I don’t think RunVirtual works with apps published per-user.

      1. Christian Leber

        I tried both ways, your sequencing receipt here with the per-user publishing + Shortcut and the global publishing with RunVirtual of Aaron.
        Both start to stream the java package, but it doesn’t show as addon.
        I got the feeling, that it has to do with Win 8.1, I’m just setting up an Win 7 PC to test it there.

        1. Check that IE and Java are the same ‘bitness’ – i.e. if you are using an x86 version of Java on a 64-bit machine, make sure you are pointing to C:\Program Files (x86)\Internet Explorer\iexplore.exe ?

          1. Christian Leber

            I’m not new to packaging 😀 yes, I did use the right exe and also tested with x64 and x86 IE, just to be sure. Also created shortcuts for both, but no difference.

            BUT: I now tested the SAME thing, on an Win 7 x64 Client: Works easy simple immidiate and flawless.
            So it is Windows 8.1 x64 that produces this problem. I’ll check now if it works if I sequence it on an Win 7 x64 client and put the package on the Win 8.1 x64 client. If that works, I got a workaround. If it still doesn’t work…. I have a problem 😀

          2. Cool, let me know what you find, I’ve not used App-V very much with Windows 8!

          3. Christian Leber

            As Addition: I tested the “RunVirtual” solution now on Win7 x64 and Win 8.1 x64 with the same AppV Package:
            Win 7: Works in IE x86 and slowly in IE x64
            Win 8.1: Doesn’t see the Addon in IE x86 and IEx64 crashes on start. 🙁
            I have a MS AppV Workshop in 2 Weeks, that’s clearly a problem I will take with me as question.

          4. This reminds me of another issue I heard about, an IE11 issue rather than Win8.1. IE11 doesn’t like it’s first launch to happen inside a virtual environment. I think since SP2, App-V 5 always hooks into iexplore.exe. So first of all try removing the RunVirtual key, launching IE and closing it, then adding it back in. If that doesn’t help, try uninstalling the App-V client, launching IE, then reinstall the client.

            Thanks for reminding me, I’ve been meaning to investigate this one!

          5. Christian Leber

            Hi Dan,
            I went to the workshop about appv now and we found the solution: KB2934349
            After Installing that CU and creating a Sequenced Java in Windows 8.1 and also deploying it there it works like a charm with RunVirtual 🙂

          6. Good to know, thanks!

  4. Mukhtar Ahmed

    Regards the Deployment.config files entries. “To get past this you need to lower the security level to medium by setting deployment.security.level=MEDIUM in your deployment.config file” Do you not mean the deployment.properties file instead?

    1. Thanks, corrected!

  5. Rash

    “The sequencer has a bug that means shortcuts cannot be edited, but they can be removed by pressing the delete key.”

    We may be at cross purposes here, but are you referring to the instance where you go to edit the shortcut and it seems to lock the sequencer? I have found that if you click on the Sequencer app on the Taskbar, it’ll then work fine. Alternatively I’ve found it works fine if you right click on the shortcut in the left pane, and select EDIT.

  6. Rmusick

    Hi Dan. Great write, so far has worked great for us. Just one question, is it possible to make all websites but a few restricted at the same time as sequencing Java? Basically we will let them use the Virtualized Java but ONLY let them go to specific websites.

    Unless of course you already mentioned it and I missed it.
    Thanks

  7. Justin Mangum

    Dan – you may want to add this in. Thanks to a recent update from MS, older versions are blocked in IE. I had to add this file into my AppV package:
    [LOCALAPPDATA]\Microsoft\Internet Explorer\VersionManager
    versionlist.xml
    This file basically tells IE to block certain versions of Java. I placed my own version of that file in my AppV package, with this in it:

    This resolved that issue – javatester showed the packaged version without issue.

    The rest of the guide – perfect! Been trying for a long time to find a good sequencing recipe

    1. Justin Mangum

      Oops… website blocked my XML:
      http://pastebin.com/LehNKMLV

  8. Ram

    Christian Leber – Will it be possible to help me sequence java 7 update 67. Do, I sequence Java as a standard application or plug-in or middleware? Any help would be appreciated. I want to run Java 7 update 67 for now on Windows 7 x64 systems. Have been trying for a week – but no luck to get it working.

    1. Christian Leber

      Hi Ram,
      for me it helped to install the newest version of the Sequencer (currently this is SP2 Hotfix 4, but correct me if I’m wrong and missed an update).
      After that I just packaged it as standard application. You then can add either an IE Shortcut to the Package or use runvirtual to make IE recognize that it should run in the virtual bubble and you are good to go.

  9. Love the site, love the recipes! This article was excellent, thank you for sharing!

  10. Tim H

    Nice post, thanks

    I’m having trouble getting the Java CP applet displaying in Control Panel on Win8.1 . Only way I can get the applet is via leaving a start menu shortcut, which the recipe says to remove in the post-monitoring step. Any ideas? Does the applet load for anyone else in Control Panel in Win8.1 ?

    1. I don’t think App-V supports adding items to the control panel. If you need the JCP, just leave the shortcut in when sequencing. If you are sequencing an old version of Java for compatibility reasons, you may wish to rename the shortcut or its folder so that you do not get it confused with the main version.

  11. Alex Pedrosky

    Feeling sort of stupid asking this, but when you have a connection group of two apps, one being Java and one being a small browser-based app with a desktop shortcut containing javaws.exe in it’s path, should that shortcut path be hard-coded to the appdata VFS profile (guid and all) for the java app? I thought the point of app-v con groups was to have a shortcut pointing to it’s normal path under Program Files and it would be redirected to the virtual directories.

    1. If you need to point to an exe belonging in another app within a connection group, then yes one way is to use the GUID for the Java app and set up the matching directory structure on the sequencer.

      Another way is to point the shortcut to a script – once the virtual environment is established you can use the virtual directories under program files.

      I’ve been meaning to write a blog post on this very issue, I’ll get around to it one day!

  12. Ase

    Hi Dan,

    I sequenced Java 7 update 71 following you recepie, which is a dependency package for another sequenced java based application, called Alcatel AAA. I’ve then created a connection group adding both sequenced applications, that is Java + Alcatel AAA, but when Alcatel AAA is launched for some reason it throws this error “Error: could not find Java SE Runtime Environment” as if it can’t find the Java Home location. Sequenced java runs the java test page successfully in the browser. Do you have any ideas how I could resolve this issue?
    Thank you very much for all your efforts.

    1. Sorry, I haven’t encountered that particular application. Try analysing with Procmon to see where it is searching for Java perhaps?

  13. Wayne Green

    What about going up in Java versions? Our standard is v7u40 (locally) and when I try to run local IE 10 with v8u25 in the bubble, it can only see the old version 7u40. But when I run local IE, with NO local Java and v8u25 in the bubble, IE does see v8. How do I force IE to use the newer version?

    1. Have you followed the advice about making sure the appdata\locallow\sun folder is in the package?

  14. Kevin

    Hi Dan, great article, thank you. Do you know how to enable the Java Security Prompts? We have a package with 7.45 in order to meet the needs of a particular website, and for some people using the package, they are not prompted to “Run this application” and it just hangs and kicks out an class type error, but the ones that are prompted can then run the applet and no issues. Is this something that can be done locally or needs to be done in the package? We’ve had people who were able to run the applet o the website before, and are now not able to. Very confusing to say the least. Thanks!

  15. Wally Davis

    Hi Dan, I’ll try to keep this short. I am packaging Java 8 Update 40 on a Windows 7 32bit Pro with MS-Office Pro Plus 2010 and IE 10. When I package Java using App-V 4.6, I add the following Icon to open a specific website, C:\Program Files\Internet Explorer\iexplore.exe -noframemerging https://somewebsite.com/app. I also added or removed Exclusions and the Oracle based web application ran fine when sequencing. I even checked the version of Java by going to http://javatester.org/version.html and it came up 1.8.0_40. IE Web application worked fine during sequencing. When I implemented it in our Citrix VDI environment, I wouldn’t load up in the Web Browser. I even checked the Java Control Panel and it was running an older version of Java, i.e. 1.6 but the new one (Q:\Java\etc.) doesn’t even show up. Any ideas on what configuration step I might be missing or how to overcome this issue? Thanks!!

    1. Difficult to diagnose from here as it could be so many different things. Try posting on the Technet forum with more info (e.g. which Java versions are installed locally, which Java Control Panel did you test local or virtual?).

      I did encounter a strange issue recently with 4.6 where Java would no longer work in a DSC linked package on a client site, I haven’t yet tried to reproduce in the lab. So if you are using a shortcut package DSC’d to Java, try it as all in one instead!

      Also if your VDI is non-persistent, try launching Internet Explorer once normally by itself so that it initialises properly before attempting to launch it inside App-V.

      1. For what it’s worth, it’s a problem with the extracted Java MSI (or command line) as even the native install has the problem. I came across the same problem and was able to resolve it by adding parameter: RebootYesNo=No

  16. Hi Dan,

    I don’t think I can emphasise this enough: AWESOME ARTICLE! It’s the backbone of my Java standardisation process.

    I wanted to add something I came across (which may well be due to a mistake in my packaging process) when running multiple versions of Java on the same machine. Per what is apparently corporate standard these days we have multiple Java applications all built to different JRE versions, thus we have used App-V to deliver these. Using your process all our applications are delivered to our end users seamlessly as a series of shortcuts making the virtulisation of the application nearly invisible. I hit a problem though when running a 1.7 and 1.6 application simultaneously (with only the 1.7 built using your guide) as one or both of the applications would randomly freeze. From what I could ascertain it appeared both the versions were using the same local cache under %appdata%, regardless of the version both used the 1.6 cache. To fix this I updated the deployment.properties file to redirect this cache to c:\temp\%APPNAME% per the options provided by Oracle:
    https://docs.oracle.com/javase/7/docs/technotes/guides/jweb/jcp/properties.html

    I edited the deployment.user.cachedir, deployment.user.logdir and deployment.user.tmp entries to avoid this clash.

    This fixed the issue for me and I am open to anybody pointing out failures in my process that led to this!

    Cheers!

    1. Sounds like both your Java apps were writing to the appdata folder in the real, rather than the virtual file system. To fix, just make sure the folder thae lives under appdata exists in the packages, then writes will be redirected to the VFS where each Java package will have their own unique folder even though they have the same path! I’ve not come across this, what is the exact default path under appdata, and are these web apps or desktop apps?

      1. I had actually thought that might be the case. As this is embedded under the users context I had been studiously trying to avoid having these folders in the app-v environment. They are listed under:

        C:\Users\USERNAME\AppData\LocalLow\Sun\Java\Deployment\cache

        and have this cache locally allows for the two Java popup windows (security hiccups which you can have always run through the tick box) actually stick. This was apparently a game changer for the business.

        This is a web app.

        1. Actually, the guide says to create the AppData\LocalLow\Sun folder when sequencing – otherwise if you have the latest Java installed locally, local and virtual instances would share the same folder. And since this folder contains a file that lists the currently installed Java versions, it’s possible for a virtualised web app to start using the latest Java from the base instead of the older one in your package!

          1. Makes perfect sense, though I’m pretty sure I actually am. I used the automated batch from the sequencing guide which includes:

            md “%USERPROFILE%\AppData\LocalLow\Sun”

            and that leak into the local installed version is a definite worry. Theoretically it should’t be an issue as there won’t be a local install but that’ll require some serious testing!

  17. Chris

    Great article! Got an update for App-V 5 sp3?

    1. There are no changes for SP3, but it so happens I was sequencing Java today and have a couple of additions for overcoming Internet Explorer’s blocking of out of date ActiveX controls and also to pre-authorise the SSV Helper browser helper object to get rid of the annoying prompt. Maybe time for part 4…

      1. Stewart

        Yes please Dan!

  18. Pingback: The Microsoft App-V 5.0 Sequencer and Client Troubleshooting Guide - The Official Microsoft App-V Team Blog - Site Home - TechNet Blogs

  19. Ase

    Hi Dan,

    I virtualised Java 6 update 18 using your recepie, which is used for the java/web based application that only depends on that particular version and it works as expected in the virtual environment. But I am experiancing an issue with the local version of java based application that depends on Java 7 update 15. This version is installed locally. The application launches ok and calls the local version, but when a particular function within the application is called it calls the virtual Java 6 update 18 that I sequenced rather than local Java 7 update 15. Confused! Do you have any ideas why is native java based application calling virtual Java rather than local? The local version works as soon as I remove the virtualised Java 6 update 18. Any help is very much appreciated. Thanks Ase

    1. Have you sequenced Java in 5.0 SP2 or later and published Java globally? If so, try publishing it per-user, or revert to the SP1 sequencer.

      1. Faiz Siddiqui

        Hi Dan,

        I created a JRE8u45 App-V package with IE shortcut. It worked with IE 9 but fails with IE 11. Launches and then shuts down automatically. Making Local Interaction ‘True’ helps in launching but that causes base IE also to load same JRE8 Add-on, means if App-V IE shortcut and Base IE shortcuts are running together both will load same JRE Add-on, whichever was launched first. Any help ?

        1. I’ve not had to sequence Java for a while now, but I have heard of this issue so you’re not alone. IE11 always fails to load if it’s first launch is inside the bubble for that particular user, so make sure you launch IE11 once normally after you upgrade before testing the sequence.

          1. Faiz Siddiqui

            Dan, Thanks for your quick reply. I did launch IE 11 after upgrade (a clean virtual machine with IE 11) and then installed – launched App-v package, still I see the same behavior. Let me mention I am using App-V 4.6

          2. If you were using App-V 5.1, try the latest hotfix:

            https://support.microsoft.com/en-us/kb/3115834

  20. Davi Cruz

    Awesome work!

    Just one question. Now with Oracle JRE 8 the Medium security level don’t exist anymore. How did you managed that?

    I’ve created the file %windir%\sun\java\deployment\exception.sites containing all URLs on whitelist and added the property deployment.user.security.exception.site point to deployment.properties file, but it isn’t working…

    Have you ever done that? do you have any idea on this case? tks!

    1. Hi, just done this myself. If you have the locallow folder in the bubble you can just put it under deployment\security\exception.sites. Otherwise you can put it in a system-wide location by modifying config.properties, e.g:

      deployment.user.security.exception.sites=C\:/WINDOWS/Sun/Java/Deployment/Security/exception.sites

      1. Davi Cruz

        I’ll give it a try! Thanks for your help!

  21. Robert

    Hi Dan, Any luck/suggestions for running this on Windows 10? When I run my package (the one that worked successfully on Windows 7 and 8) on 10. it throws up a “The page you are viewing uses Java…” So it looks like it isn’t seeing Java.
    Thanks

  22. Carlos

    I belive I followed your instructions exactly but when i launch IE “Javatester.org” with the packaged Java i get the following, “The page you are viewing uses java”. Its not seeing the packaged java, Any thoughts?

    1. Make sure you are using 32-bit IE with 32-bit Java and 64-bit IE with 64-bit Java?

      1. Carlos

        Using 32bit Java and 32bit IE

        1. Well Javatester.org is unsigned so needs exceptions.sites configured… try https://www.java.com/en/download/installed.jsp instead.

Leave a Reply