 |
jreBlock: is a simple PowerShell script to help when you need to sequence a Java JRE inside of an App-V virtual environment. NOTE: See special section below for working with Version 4 of this script. VERSION 3 DETAILS ------------------------------ The typical technique to sequencing Java JREs is to actively attempt to hide all other versions of Java from the virtual environment other than the one you want. Arron Parker provided a cmd script back in the App-V 4.5 days, but it needed to be updated to the latest versions of Java to use it. So in 2011 Patrick created a powershell version with an intent to "future proof" the blocking within the package anticipating what the future versions of Java might look like. Version two of the script was updated 4 years ago, so in 2016. We had to update the script to version 3 to cover changes made in the numbering scheme by Oracle (who knew that the 1.8 series would have more than 99 updates?) This is a PowerShell script that anticipates the likely versions of Java over the next few years, and allows you to optionally specify a maximum version if that isn't enough. Why do I need this?:When Java is installed, it adds a bunch of COM registrations pointing to the current version it is installing. Sun (now Oracle) changes the GUID in a predictable way and adds or updates all of the old GUIDs to also point to the new version. Thus any software trying to access the old version will get the new version. Which in theory is great, except that so much Java code ends up being version specific (or more to the point, when new Java versions come out that are not concerned enough with backward compatibility). Due to security concerns, if you deploy Java natively on operating systems you always want to be patching to the latest version. Virtualizing any old version of Java that you require for an app that needs a specific version using this technique, will allow the app running inside that virtual environment to only see this version of Java, no matter what version might be natively installed. And since that version of Java probably has well known security vulnerabilities, you only want the user to use that crusty version of Java when running the app that requires it, not for general web surfing. (Side note: "Web surfing" seems like it must be a strange California reference. You can't surf a spider's web, you must carefully climb on it). You can combine the dependent app in the java package directly, or package separately and use a connection group. You probably create a special shortcut in the package for your app, and you probably also remove the browsing bar from the UI of the web browser in this package so they can't go climbing in those dangerous places. They can do that from the non-virtualized browser. You also don't have to deploy Java natively. This solution works great anyway. And it might be time to be removing from systems except when absolutely needed anyway. How to use JreBlock:To use the script using the defaults, which handles up to version 1.9.2.99, you would run the following commands in a 32-bit version of powershell launched using RunAsAdministrator. (Note: this means that on an x64 OS you use the powershell (x86) version!). You launch powershell twice, once prior to sequencing and again while in monitoring mode.
The scripts will create a few more blocker keys than you probably need, but better safe then sorry.
VERSION 4 Details ----------------------------------- Version 4 of the script has been rewritten:
So run PassiveInstallDependencies.ps1 (no arguments) prior to sequencing and then during sequencer monitoring run jreblock.ps1 -DeleteKeys, followed by the Java install you need. ----------------------------------------------------------- The tool is free for personal or commercial use. Here is the ZIP package with the PS1: jreBlock V 3.0.0.0
Here is the ZIP package with the PS1 files: jreBlock V 4.0.0.0 |