Normally we default to relying on our (JITI) Just in Time Installer to install managed applications. JITI installs in about the same time as virtualization and has the advantage of running at native speeds after the application is first installed. Over time this greatly reduces the load on the workstation’s CPU and disk reads. JITI also lets other applications see the file and registry settings of the installed application avoiding many of the configuration headaches of virtualization technologies like AppV.
Despite all these advantages of JITI, there is one area where virtualization wins. JITI does not allow two or more versions of the same application to run at the same time. Sometimes administrators come across an application that needs to be isolated from other applications or from a different version of the same application. The most common example is with Java, many older web pages require a specific version of Java to run. Administrators can’t simply install the older version without breaking newer pages that also rely on Java. Additionally, older versions of Java have known vulnerabilities that make it a security concern to install natively to the workstation. For these reasons, we rely on a pure application virtualization where we redirect all file and registry calls at the kernel driver level to an isolated redirection area. As the application runs all its files and registry calls are redirected to this redirection area and are only seen by the application itself and the parent process that is dependent on the isolated applications. This can be turned on by simply setting the application to run in “Isolation” by simply checking the “Isolate application” checkbox in the console under the “OPK” tab.
Once selected, the OpDesk agent will run the application processes isolated from any other running processes (this includes Microsoft’s Explorer.exe). The application will get fully downloaded and extracted into our redirection area during its initial install. Any file or registry data that gets modified while the application is running will get saved in the redirection area and not to the normal file system/registry. The redirection area is in a protected OpDesk\Application Cache folder of the Program Data folder. You can also use the reset feature to restore the application back to how it was originally installed. When the application gets uninstalled it will also remove any modified or added files and registry settings.
As you probably know, Microsoft does not allow the new Microsoft Edge browser to load any Java plugin JRE. However Windows 10 still ships with the older Internet Explorer that can run Java. You can configure the managed JRE to launch Internet explorer to show a specific page using a specific version of Java. Additionally we ship with an optionally installed simple browser (32 or 64 bit) that you can use to view different pages that need different versions of Java at the same time. Here is an example of how you would add a shortcut to the launch menu to launch our RasmSimpleBrowser32.exe which would install an isolated version of JRE7u80 (1.7) and show the common test webpage “https://javatester.org/”. Once this application is associated with a workstation or use you will see the specified icon in the launch menu. Once the shortcut is launched the end user simply sees the specified browser launch and the specified page loads using the version of Java desired.
All versions of the JRE require some configuration to allow/disallow various http pages to use the specific versions of Java. So you’ll need to add your page exceptions to Java’s security tab.
Finally you you should be able to launch your test Java web pages showing you can now run multiple versions of Java at the same time:
There are some known limitations of Java on newer operating systems. For example, we recommend installing Java 1.6 and above on Windows 10 since previous version of Java won’t run on Windows 10. Basically, if Java can run on an operating system natively, then we should be able to run virtualized.