Backstory:
From around Oracle Java 8u121 and up to current date some
components in a virtualized Java would stop working if virtualized with AppV and SWV.
Example:
We have a couple of web app that is launched using JNLP, Applications stopped working from that update when fully virtualized.When started javaws.exe gets closed after around 10 seconds without any output, no errors, nothing.
Old workaround:
I found a way to “virtualize” some components like registry with an Hybrid package on SWV and AppV with some exe files scripted into base layer (local file system c:\). Even if this is working pretty good it’s not a proper virtual package and basefiles loaded into the browser could fail when you force removal by script.When possible we always want to make sure all files stay inside the virtual layer, that way we ensure compatibility and integrity of files and folders and we can forcefully close and remove virtual applications and be sure everything in the base Os is still untouched
Working solution:
This solution was based on information I found on several sites (links in the end of article), but you could just skip to the SWV/AppV part in the end if you want the easy solution since i found a lot of bugs in the normal install, thats why I like to use the msi installer, it's proven more stable than the exe installer:
---------------------------------------- Normal Java install -------------------------------------------------------
Create a folder called "config" and inside create 3 different files:
Create a folder called "config" and inside create 3 different files:
• deployment.config - The contents of this file:
deployment.system.config.mandatory=true
deployment.system.config=file:///C:/WINDOWS/Sun/Java/Deployment/deployment.properties
• deployment.properties - The contents of this file
# System Deployment Properties # Disable Sponsor offers like ASK Toolbar install.disable.sponsor.offers=true install.disable.sponsor.offers.locked # Mixed code (sandbox vs. trusted) security verification deployment.security.mixcode=HIDE_RUN # Security Level deployment.security.level=HIGH # Security Execution Environment\Enable granting elevated access to signed apps # aka. Allow user to grant permissions to signed content deployment.security.askgrantdialog.show=true # Enable Java content in the browser deployment.webjava.enabled=true # JNLP File/MIME Association deployment.javaws.associations=0 deployment.javaws.autodownload=NEVER deployment.javaws.autodownload.locked # Shortcut Creation deployment.javaws.shortcut=NEVER # Prompt: Your Java version is insecure. or Your Java version is out of date deployment.expiration.check.enabled=false deployment.expiration.check.enabled.locked # Exception sites file location deployment.user.security.exception.sites=C:\\WINDOWS\\Sun\\Java\\Deployment\\exception.sites # Java Console - Options for show, disable or hide the Java Console deployment.console.startup.mode=HIDE # This settings make Java all JNPL sites work with virtual Appv and SWV deployment.security.use.insecure.launcher=true
• exception.sites - You can add application URLS in this file to allow your users to Java enabled sites that would normally be blocked by security checks. Note that once you use this file, sites can no longer be added in the Java Control Panel, this gives you more control as you can manage this exclusively through the exception.sites file.
Create another folder, you can call it Jre1.80_xx (Use
whatever version of Java yor're deploying to keep some standard and also make it
easy to identify. Inside this folder,
place the config folder as well as the latest java exe available (at time of
writing it is jre-8u161-windows-i586.exe).
You are also going to create two more files inside this folder:
java.settings.cfg - The contents of this file can vary,
depending on your deployment needs, this are my settings:
INSTALL_SILENT=Enable
STATIC=Disable
AUTO_UPDATE=Disable
WEB_JAVA=Enable
WEB_JAVA_SECURITY_LEVEL=H
WEB_ANALYTICS=Disable
EULA=Disable
REBOOT=Disable
NOSTARTMENU=Enable
SPONSORS=Disable
REMOVEOUTOFDATEJRES=1
• install.bat - This is your install script pulling everything together. The part about wmic is only needed if you deploy to base with Oracle msi/exe and want to remove old versions first.
@echo off
setlocal enableextensions
@cd /d "%~dp0"
setlocal enableextensions
@cd /d "%~dp0"
REM The below command will look for and uninstall any previous Java 7 or 8 from the target machine
wmic product where "name like 'Java 7%%' or name like 'Java 8%%'" call uninstall /nointeractive
REM The first command will copy the Java configuration file to the target machine
xcopy java.settings.cfg "C:\ProgramData\Oracle\Java\" /I /Q /R /Y > nul
REM The following line will install the java software to the target computer
Start /wait jre-8u161-windows-i586.exe INSTALLCFG=C:\ProgramData\Oracle\Java\java.settings.cfg /L C:\jre-8u161.log
REM The next line will copy the Java deployment property files to the target computer
xcopy Config\*.* "C:\Windows\Sun\Java\Deployment\" /I /Q /R /Y > nul
endlocal
You can use this .bat file instead for your SWV installation:
@echo off
setlocal enableextensions
@cd /d "%~dp0"
setlocal enableextensions
@cd /d "%~dp0"
REM The following line will install the java software to the target computer
Start /wait msiexec /i "%~dp0jre1.8.0_161.msi" NOSTARTMENU=1 JU=0 JAVAUPDATE=0 AUTOUPDATECHECK=0 WEB_JAVA=1 WEB_ANALYTICS=0 WEB_JAVA_SECURITY_LEVEL=H DISABLEADVTSHORTCUTS=1 ALLUSERS=1 /l*v c:\java180_161.log /qr
REM Delete javapath\contains symbolic links and must be copied to base layer for compile to work
del /q C:\ProgramData\Oracle\Java\javapath\*
REM Copy correct java path files to baselayer
xcopy "C:\Program Files (x86)\Java\jre1.8.0_161\bin\java.exe" "C:\ProgramData\Oracle\Java\javapath\"
xcopy "C:\Program Files (x86)\Java\jre1.8.0_161\bin\javaw*.exe" "C:\ProgramData\Oracle\Java\javapath\"
endlocal
SWV:
Personaly I just use the msi installer with the applied parameters "NOSTARTMENU=1 JU=0 JAVAUPDATE=0 AUTOUPDATECHECK=0 WEB_JAVA=1 WEB_ANALYTICS=0 WEB_JAVA_SECURITY_LEVEL=H DISABLEADVTSHORTCUTS=1 ALLUSERS=1 /l*v c:\java180_161.log /qr" since Oracle has a record for breaking the installer once in a while.I normally don't apply security settings pr. host with the "exceptions.sites" file so this can be removed from your deployment file.
Our users can then add the pages they want to run manually. Less secure but less of an hassle for us, you have to consider pros and cons, most users have to call our helpdesk anyway for that.
Easiest way is to just create the user deployment.properties file with this line inside:
deployment.security.use.insecure.launcher=true
Then copy the deployment.properties file to: [USER_TEMPLATE]\USERPROFILE\AppData\LocalLow\Sun\Java\Deployment, may have to
force read only settings to the file if you want to preserve it .
Also remember to add exlude, .jar + .jnpl + .sites to exluded files types in package.
AppV:
The same applies to AppV, you could just create deployment.properties
Then remove
localAppData from Exclusions prior to sequencing and edit the
deplyment.properties in AppData\LocalLow\Sun\Java\Deployment during sequencing
OR somehow edit the deplyment.properties in
AppData\LocalLow\Sun\Java\Deployment for the existing package in local, not
virtualized location (if localLow was in excludes)
With this line:
deployment.security.use.insecure.launcher=true
Also I recommend using JRE block from TMurgent if you want to isolate your AppV Java.
The following quote from Timothy Mangan should say it all:
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. 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.
Easiest way is to just create the user deployment.config file with this line inside:
ReplyDeletedeployment.security.use.insecure.launcher=true
Shouldn't that be deployment.properties ?
Yes, you are correct, tnx for pointing out the typo for me. Will correct it.
Delete