It seems like I have to re-invent my SCCM Java deployment process each and every time Oracle comes out with a new update. I am currently attempting to deploy Java 1.8 update 31 and am having little luck. While this is an SCCM-centric question I am still in the testing process prior to actually deploying the software. I getting an installation error as follows with the 32-bit installation:

MSI (s) (50:CC) [11:52:09:663]: Product: Java 8 Update 31 -- Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action installexe, location: C:\Windows\Installer\MSI79FF.tmp, command: /s INSTALLDIR="C:\Program Files (x86)\Java\jre1.8.0_31\\" WEB_JAVA=1 REPAIRMODE=0

The installer creates the installation directory and copies the files but the installation ultimately fails with the generic 1603 error.

The command line that I am using to install Java is being passed through Powershell Deployment Toolkit as:

Execute-MSI-Actioninstall-Path"jre1.8.0_31.msi"-Parameters"JU=0 JAVAUPDATE=0 AUTOUPDATECHECK=0 RebootYesNo=No WEB_JAVA=1 /q"

Which I tested manually as:

msiexec.exe /I "jre1.8.0_31.msi" JU=0 JAVAUPDATE=0 AUTOUPDATECHECK=0 RebootYesNo=No WEB_JAVA=1 /q

When manually run the install completes just fine without complaint so I know the switches are correct and are fully functional. I have even run the actual .com installer using just the "/s SPONSORS=0" arguments and that works just fine too when run manually.

I have never had an issue where a command line that works when run manually under and admin context won't work when run through Powershell. I read through the related thread at: http://www.edugeek.net/forums/enterprise-software/143767-java-8-update-25-silent-install-via-sccm-8.html however it doesn't seem to come to a definitive conclusion as to what could be done. I am not using config files as I have never had the need to before (passing the switches always worked until now). I am also able to completely uninstall all previous versions of Java using the Remove-MSIApplications PDT commandlet (which also works fine if I manually install 1.8 u 31 before running the PDT process again).

I am just getting fed up with the mess that is Java. It would be nice if there was simply some consistency and predictability within these version. If anyone can provide insight I would really appreciate it.

V/r,

Chris

Just an initial thought. . .did you look at the MSI log? If you search for "Return Value 3" in the MSI log, it should take you to a point in the log that gives maybe a little more detail about the 1603 error.

I am actually deploying this version of Java at a client today, so I may have some more input later.

Jeff

Remove any previous version of the software first.

https://www.java.com/en/download/help/error_1722.xml

The 1722 error comes directly out of the .msi log and unlike the PDT log where there is only a 1603 error there are a couple of lines associated and none of them seem to provide further detail Here is some further contecxt:

CustomAction installexe returned actual error code 61013 (note this may not be 100% accurate if translation happened inside sandbox)

MSI (s) (50:CC) [11:52:09:663]: Product: Java 8 Update 31 -- Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action installexe, location: C:\Windows\Installer\MSI79FF.tmp, command: /s INSTALLDIR="C:\Program Files (x86)\Java\jre1.8.0_31\\" WEB_JAVA=1 REPAIRMODE=0

Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action installexe, location: C:\Windows\Installer\MSI79FF.tmp, command: /s INSTALLDIR="C:\Program Files (x86)\Java\jre1.8.0_31\\" WEB_JAVA=1 REPAIRMODE=0

later in the logging I see:

MSI (s) (50:CC) [11:52:11:719]: Error in rollback skipped. Return: 5

MSI (s) (50:CC) [11:52:11:838]: Product: Java 8 Update 31 -- Installation failed.

MSI (s) (50:CC) [11:52:11:839]: Windows Installer installed the product. Product Name: Java 8 Update 31. Product Version: 8.0.310. Product Language: 1033. Manufacturer: Oracle Corporation. Installation success or error status: 1603.

I have done this multiple ways including using a WMIC query and my PDT script also removed any previous versions without issue so I don't think old versions are my problem, besides if this was the case then why would I be able to run the MSIEXE.EXE command line without problem but not be able to handle the same command line in a scripted process? From what I can tell people have been having this issue since before update 31 with Java 1.8.

I ran into exactly the same issue. Setup failed with this message when run as system account but the same commandline was successful when launched as local administrator account.

It turned out that the following commandline arguments should not be used :

EULA=0 AUTO_UPDATE=0 SPONSORS=0.

When I use one of those on the commandline, execution fails under system account. When I leave them out, execution succeeds.

These arguments are passed to a custom action installexe, which probable can't handle them well.

This helped for me. I have no explanation.

I had a similar issue as well, but leaving off the command-line arguments listed above didn't prove to work so well for me unfortunately.

However, keeping with the idea that there might be an issue with the system account not being able to install Java, I changed the "Logon Requirement" from "Whether or not a user is logged on" to "Only when a user is logged on".  This is all under the User Experience tab.  After changing this setting, my install took off with the following switches:

msiexec /i jre1.8.0_31.msi WEB_JAVA=1 WEB_JAVA_SECURITY_LEVEL=H NOSTARTMENU=1 WEB_ANALYTICS=0 AUTO_UPDATE=0 EULA=0 SPONSORS=0 REBOOT=0 INSTALL_SILENT=1

For the future reference, the uninstall command I'm using:

msiexec /x {26A24AE4-039D-4CA4-87B4-2F83218031F0} /q

I know this isn't very ideal, but seemed to work fine while logged in as a user with admin rights, along with IE open to a page that required Java.

I too am frustrated with deploying Java as it seems like I'm having to re-invent the wheel every single time!

Same problem here.  I haven't tried running "Only when a user is logged on" yet, but I'm not sure that's suitable for my situation anyway.  Our users don't have admin rights, and in the past I've found that java installs fail if users are logged on and have a browser window open at the time the install runs. 

I'm still trying variations on the command line, but wanted to add my comment here and follow the thread in case anyone else comes up with a solution. 

This new installer seems to be fairly resilient from what I've seen as compared to previous installers. I've had my browser opened and working on websites that require Java and have had no issues with the installer running in the background. I've also tested it with supersedence in place, where it will install the new Java, while also removing the old Java, all with an open browser.

Strange how Java will make one thing better, while completely breaking something else.

One source of the 1722 and 1619 errors might be due to the system profile having two different possible directories depending on whether the process is 32 bit or 64 bit. I believe that it was your post led me to this URL:

http://www.edugeek.net/forums/enterprise-software/143767-java-8-update-25-silent-install-via-sccm-7.html

As it was pointed out by 'sccmadmin' (Mike) in post #103, there seems to be some sort of bug in the 32 bit installer when it is running in the system account . What happens is: the installer writes the files to one directory, but then when it tries to start msiexec.. the msi is not found in the location where it was expecting it. This might be due to the installer calling the wrong msiexec? Or folder redirection issues..  I don't know specifically without seeing exactly what the exe installer is intending to do.

Mike also points out that when you do not use the exe file, you miss out on the language support that oracle builds in. While he does use an install config file (java.settings.cfg) in the command line, it is not required and it didn't help me overcome the need for that same file to be present in C:\ProgramData\Oracle\java ... so I omitted it from the install command line. Oracle either does not know the issue exists, or they are just not capable enough to fix it.  Mike used the approach of changing the system profile location, and with his admitted lack of a better option at the time,it was inventive and it did work for him. Relying on the script the change the system profile path back/forth every time was not something I wanted to do. But He did get me thinking. (thank you)

Here is the approach I took..

1. Delete or rename the Sun directory in the SYSWOW64 path.. (C:\Windows\SysWOW64\config\systemprofile\AppData\LocalLow\Sun)

2. Create a directory junction called "Sun". Instead of a real folder, now there is a junction. Essentially both possible sun folders point to the same place:
   cmd /c mklink /J C:\Windows\SysWOW64\config\systemprofile\AppData\LocalLow\Sun C:\Windows\System32\config\systemprofile\AppData\LocalLow\Sun

3. Make sure that C:\ProgramData\Oracle\Java\java.settings.cfg exists, if you are trying to install via system,the install will fail if the file does not exist. The file might already exist on your system if you did a manual install, it will not exist in the rest of your environment, so make sure it is there on those systems too..

4. Install Java using the exe because it is better.. :
   jre-8u31-windows-i586.exe /s AUTO_UPDATE=0 INSTALL_SILENT=1 REBOOT=0 SPONSORS=0 WEB_ANALYTICS=0 /l* "C:\windows\temp\jre-8u31-windows-i586.log"

That should work for you..  hopefully..   I cannot say for sure whether it will fix issues with the MSI installer or not. Also.. if you like to leave automatic updates turned on, you may also need to create a junction the the oracle directory in the same path.

In order to deploy this to the masses.. you need to automate the prerequisite actions, this may work for you:

These install strings can be configured in an SCCM/ConfigMgr Application
Make sure you *do not* check the "run this process as 32 bit on 64 hosts", it will not work correctly because the 32 bit process will redirect references to C:\windows\system32 and your directory junction will not get created correctly.

Hopefully the the formatting does not get messed up: I placed left & right double quotation marks in the string surrounding the text for the java.settings.cfg file so that I did not have to deal with escaping the characters.. They are characters Alt+0147 () and Alt+0148 ()  the powershell command (-c) is surrounded by the normal quote character found on your keyboard.

#This one works for x86
powershell -noprofile -c "&{$ErrorActionPreference = 'SilentlyContinue';$l='C:\Windows\SysWOW64\config\systemprofile\AppData\LocalLow';$l32 = $l.replace('WOW64','tem32');$dir=gci $l -force | Where {$_.name -eq 'sun'};if((gwmi Win32_OperatingSystem).OSArchitecture -eq '64-bit' -and !(($dir.Attributes) -match 'ReparsePoint')){gci $l\Sun -Recurse | rm -recurse -force; rm $l\Sun -recurse -force;mkdir $l32\Sun;cmd /c mklink /J $l\Sun $l32\Sun|out-null;};$p=$env:allusersprofile+'\Oracle\Java';mkdir $p;AUTO_UPDATE=0`r`nEULA=0`r`nINSTALL_SILENT=1`r`nSPONSORS=0`r`nWEB_ANALYTICS=0| out-File $p'\java.settings.cfg' -Encoding ascii;.\jre-8u31-windows-i586.exe /s AUTO_UPDATE=0 INSTALL_SILENT=1 REBOOT=0 SPONSORS=0 WEB_ANALYTICS=0|out-null;$host.SetShouldExit($LastExitCode);}"

#This one works for x64
powershell -noprofile -c "&{$ErrorActionPreference = 'SilentlyContinue';$p=$env:allusersprofile+'\Oracle\Java';mkdir $p;AUTO_UPDATE=0`r`nEULA=0`r`nINSTALL_SILENT=1`r`nSPONSORS=0`r`nWEB_ANALYTICS=0| out-File $p'\java.settings.cfg' -Encoding ascii;.\jre-8u31-windows-x64.exe /s AUTO_UPDATE=0 INSTALL_SILENT=1 REBOOT=0 SPONSORS=0 WEB_ANALYTICS=0|out-null;$host.SetShouldExit($LastExitCode);}"

Perhaps there is a better way to do this which avoids the need for a directory junction. But this can help us (and oracle) learn how the installer behaves in the system context..  which they really need to learn about..  this Java bug submitted for Java 6 Update 25 would lead me to believe that they do know of the redirection issue: https://bugs.openjdk.java.net/browse/JDK-7014194 .. the original post contains this blurb which is interesting: "JRE 1.6.0_22 silent install is failing on WINDOW SERVER 2008 when done in system context (whatever that means)"  it seems that whoever logged this bug for the person reporting the issue is clueless to what the system account or system context means..

If oracle will make the necessary changes to the .exe so that it properly extracts and executes the 32 bit msi file on 64 bit machines.. that would be great. If they would also fix the issue with the java.settings.cfg file being written when the install is being silently performed (this is an issue with 32 and 64 bit installers), that would be awesome.. and if they would try to not break it in the future, that would be fantastic.

--

When picking which install options I would used. I used the properties extracted from the .msi file and referred to the oracle website which explains each option.

MSI options:
As extracted from the CustomAction \ SetCMDLine line item in the MSI:
{[SILENT]}{ INSTALLDIR="[INSTALLDIR]\"}{ WEB_JAVA=[WEB_JAVA]}{ WEB_JAVA_SECURITY_LEVEL=[WEB_JAVA_SECURITY_LEVEL]}{ STATIC=[STATIC]}{ WEB_ANALYTICS=[WEB_ANALYTICS]}{ INSTALLCFG="[INSTALLCFG]"}{ USAGETRACKER_CFG="[USAGETRACKER_CFG]"}{ DEPLOYMENT_RULE_SET="[DEPLOYMENT_RULE_SET]"}{ EULA=[EULA]}{ NOSTARTMENU=[NOSTARTMENU]}{ INSTALL_SILENT=[INSTALL_SILENT]}{ AUTO_UPDATE=[AUTO_UPDATE]}{ SPONSORS=[SPONSORS]}{ REPAIRMODE=[REPAIRMODE]}    


I Decided to use these options:
{[SILENT]} <- Notice that this is not a pair, I believe that [SILENT] is set to "/s" if you specified /s or "INSTALL_SILENT=1" on the command line for the exe.
And these:
{ WEB_ANALYTICS=[WEB_ANALYTICS]}{ INSTALL_SILENT=[INSTALL_SILENT]}{ AUTO_UPDATE=[AUTO_UPDATE]}{ SPONSORS=[SPONSORS]}

I Decided NOT to use:
{ WEB_JAVA=[WEB_JAVA]} *Default for WEB_JAVA is 1, specifying this on the cmd line is not needed.
{ WEB_JAVA_SECURITY_LEVEL=[WEB_JAVA_SECURITY_LEVEL]}, Defualt sec level is H.. specifying this on the cmd line is not needed.
{ STATIC=[STATIC]}
{ INSTALLDIR="[INSTALLDIR]\"}
{ INSTALLCFG="[INSTALLCFG]"}
{ USAGETRACKER_CFG="[USAGETRACKER_CFG]"}
{ DEPLOYMENT_RULE_SET="[DEPLOYMENT_RULE_SET]"}
{ EULA=[EULA]}
{ NOSTARTMENU=[NOSTARTMENU]}
{ REPAIRMODE=[REPAIRMODE]}

MSI option usage:
http://docs.oracle.com/javase/8/docs/technotes/guides/install/config.html#config_file_options

Pay attention to the fact that they do say you can use the options on the command line as well -> "You may use the same options at the command line when running the JRE Windows Offline Installer or the JRE MSI Enterprise Installer."

Marshall

• Edited by MarshallHarrison 19 hours 17 minutes ago Spelling and Grammar

One source of the 1722 and 1619 errors might be due to the system profile having two different possible directories depending on whether the process is 32 bit or 64 bit. I believe that it was your post led me to this URL:

http://www.edugeek.net/forums/enterprise-software/143767-java-8-update-25-silent-install-via-sccm-7.html

As it was pointed out by 'sccmadmin' (Mike) in post #103, there seems to be some sort of bug in the 32 bit installer when it is running in the system account . What happens is: the installer writes the files to one directory, but then when it tries to start msiexec.. the msi is not found in the location where it was expecting it. This might be due to the installer calling the wrong msiexec? Or folder redirection issues..  I don't know specifically without seeing exactly what the exe installer is intending to do.

Mike also points out that when you do not use the exe file, you miss out on the language support that oracle builds in. While he does use an install config file (java.settings.cfg) in the command line, it is not required and it didn't help me overcome the need for that same file to be present in C:\ProgramData\Oracle\java ... so I omitted it from the install command line. Oracle either does not know the issue exists, or they are just not capable enough to fix it.  Mike used the approach of changing the system profile location, and with his admitted lack of a better option at the time,it was inventive and it did work for him. Relying on the script the change the system profile path back/forth every time was not something I wanted to do. But He did get me thinking. (thank you)

Here is the approach I took..

1. Delete or rename the Sun directory in the SYSWOW64 path.. (C:\Windows\SysWOW64\config\systemprofile\AppData\LocalLow\Sun)

2. Create a directory junction called "Sun". Instead of a real folder, now there is a junction. Essentially both possible sun folders point to the same place:
   cmd /c mklink /J C:\Windows\SysWOW64\config\systemprofile\AppData\LocalLow\Sun C:\Windows\System32\config\systemprofile\AppData\LocalLow\Sun

3. Make sure that C:\ProgramData\Oracle\Java\java.settings.cfg exists, if you are trying to install via system,the install will fail if the file does not exist. The file might already exist on your system if you did a manual install, it will not exist in the rest of your environment, so make sure it is there on those systems too..

4. Install Java using the exe because it is better.. :
   jre-8u31-windows-i586.exe /s AUTO_UPDATE=0 INSTALL_SILENT=1 REBOOT=0 SPONSORS=0 WEB_ANALYTICS=0 /l* "C:\windows\temp\jre-8u31-windows-i586.log"

That should work for you..  hopefully..   I cannot say for sure whether it will fix issues with the MSI installer or not. Also.. if you like to leave automatic updates turned on, you may also need to create a junction the the oracle directory in the same path.

In order to deploy this to the masses.. you need to automate the prerequisite actions, this may work for you:

These install strings can be configured in an SCCM/ConfigMgr Application
Make sure you *do not* check the "run this process as 32 bit on 64 hosts", it will not work correctly because the 32 bit process will redirect references to C:\windows\system32 and your directory junction will not get created correctly.

Hopefully the the formatting does not get messed up: I placed left & right double quotation marks in the string surrounding the text for the java.settings.cfg file so that I did not have to deal with escaping the characters.. They are characters Alt+0147 () and Alt+0148 ()  the powershell command (-c) is surrounded by the normal quote character found on your keyboard.

#This one works for x86
powershell -noprofile -c "&{$ErrorActionPreference = 'SilentlyContinue';$l='C:\Windows\SysWOW64\config\systemprofile\AppData\LocalLow';$l32 = $l.replace('WOW64','tem32');$dir=gci $l -force | Where {$_.name -eq 'sun'};if((gwmi Win32_OperatingSystem).OSArchitecture -eq '64-bit' -and !(($dir.Attributes) -match 'ReparsePoint')){gci $l\Sun -Recurse | rm -recurse -force; rm $l\Sun -recurse -force;mkdir $l32\Sun;cmd /c mklink /J $l\Sun $l32\Sun|out-null;};$p=$env:allusersprofile+'\Oracle\Java';mkdir $p;AUTO_UPDATE=0`r`nEULA=0`r`nINSTALL_SILENT=1`r`nSPONSORS=0`r`nWEB_ANALYTICS=0| out-File $p'\java.settings.cfg' -Encoding ascii;.\jre-8u31-windows-i586.exe /s AUTO_UPDATE=0 INSTALL_SILENT=1 REBOOT=0 SPONSORS=0 WEB_ANALYTICS=0|out-null;$host.SetShouldExit($LastExitCode);}"

#This one works for x64
powershell -noprofile -c "&{$ErrorActionPreference = 'SilentlyContinue';$p=$env:allusersprofile+'\Oracle\Java';mkdir $p;AUTO_UPDATE=0`r`nEULA=0`r`nINSTALL_SILENT=1`r`nSPONSORS=0`r`nWEB_ANALYTICS=0| out-File $p'\java.settings.cfg' -Encoding ascii;.\jre-8u31-windows-x64.exe /s AUTO_UPDATE=0 INSTALL_SILENT=1 REBOOT=0 SPONSORS=0 WEB_ANALYTICS=0|out-null;$host.SetShouldExit($LastExitCode);}"

Perhaps there is a better way to do this which avoids the need for a directory junction. But this can help us (and oracle) learn how the installer behaves in the system context..  which they really need to learn about..  this Java bug submitted for Java 6 Update 25 would lead me to believe that they do know of the redirection issue: https://bugs.openjdk.java.net/browse/JDK-7014194 .. the original post contains this blurb which is interesting: "JRE 1.6.0_22 silent install is failing on WINDOW SERVER 2008 when done in system context (whatever that means)"  it seems that whoever logged this bug for the person reporting the issue is clueless to what the system account or system context means..

If oracle will make the necessary changes to the .exe so that it properly extracts and executes the 32 bit msi file on 64 bit machines.. that would be great. If they would also fix the issue with the java.settings.cfg file being written when the install is being silently performed (this is an issue with 32 and 64 bit installers), that would be awesome.. and if they would try to not break it in the future, that would be fantastic.

--

When picking which install options I would used. I used the properties extracted from the .msi file and referred to the oracle website which explains each option.

MSI options:
As extracted from the CustomAction \ SetCMDLine line item in the MSI:
{[SILENT]}{ INSTALLDIR="[INSTALLDIR]\"}{ WEB_JAVA=[WEB_JAVA]}{ WEB_JAVA_SECURITY_LEVEL=[WEB_JAVA_SECURITY_LEVEL]}{ STATIC=[STATIC]}{ WEB_ANALYTICS=[WEB_ANALYTICS]}{ INSTALLCFG="[INSTALLCFG]"}{ USAGETRACKER_CFG="[USAGETRACKER_CFG]"}{ DEPLOYMENT_RULE_SET="[DEPLOYMENT_RULE_SET]"}{ EULA=[EULA]}{ NOSTARTMENU=[NOSTARTMENU]}{ INSTALL_SILENT=[INSTALL_SILENT]}{ AUTO_UPDATE=[AUTO_UPDATE]}{ SPONSORS=[SPONSORS]}{ REPAIRMODE=[REPAIRMODE]}    


I Decided to use these options:
{[SILENT]} <- Notice that this is not a pair, I believe that [SILENT] is set to "/s" if you specified /s or "INSTALL_SILENT=1" on the command line for the exe.
And these:
{ WEB_ANALYTICS=[WEB_ANALYTICS]}{ INSTALL_SILENT=[INSTALL_SILENT]}{ AUTO_UPDATE=[AUTO_UPDATE]}{ SPONSORS=[SPONSORS]}

I Decided NOT to use:
{ WEB_JAVA=[WEB_JAVA]} *Default for WEB_JAVA is 1, specifying this on the cmd line is not needed.
{ WEB_JAVA_SECURITY_LEVEL=[WEB_JAVA_SECURITY_LEVEL]}, Defualt sec level is H.. specifying this on the cmd line is not needed.
{ STATIC=[STATIC]}
{ INSTALLDIR="[INSTALLDIR]\"}
{ INSTALLCFG="[INSTALLCFG]"}
{ USAGETRACKER_CFG="[USAGETRACKER_CFG]"}
{ DEPLOYMENT_RULE_SET="[DEPLOYMENT_RULE_SET]"}
{ EULA=[EULA]}
{ NOSTARTMENU=[NOSTARTMENU]}
{ REPAIRMODE=[REPAIRMODE]}

MSI option usage:
http://docs.oracle.com/javase/8/docs/technotes/guides/install/config.html#config_file_options

Pay attention to the fact that they do say you can use the options on the command line as well -> "You may use the same options at the command line when running the JRE Windows Offline Installer or the JRE MSI Enterprise Installer."

Marshall

• Edited by MarshallHarrison Friday, February 06, 2015 4:57 PM Spelling and Grammar

One source of the 1722 and 1619 errors might be due to the system profile having two different possible directories depending on whether the process is 32 bit or 64 bit. I believe that it was your post led me to this URL:

http://www.edugeek.net/forums/enterprise-software/143767-java-8-update-25-silent-install-via-sccm-7.html

As it was pointed out by 'sccmadmin' (Mike) in post #103, there seems to be some sort of bug in the 32 bit installer when it is running in the system account . What happens is: the installer writes the files to one directory, but then when it tries to start msiexec.. the msi is not found in the location where it was expecting it. This might be due to the installer calling the wrong msiexec? Or folder redirection issues..  I don't know specifically without seeing exactly what the exe installer is intending to do.

Mike also points out that when you do not use the exe file, you miss out on the language support that oracle builds in. While he does use an install config file (java.settings.cfg) in the command line, it is not required and it didn't help me overcome the need for that same file to be present in C:\ProgramData\Oracle\java ... so I omitted it from the install command line. Oracle either does not know the issue exists, or they are just not capable enough to fix it.  Mike used the approach of changing the system profile location, and with his admitted lack of a better option at the time,it was inventive and it did work for him. Relying on the script the change the system profile path back/forth every time was not something I wanted to do. But He did get me thinking. (thank you)

Here is the approach I took..

1. Delete or rename the Sun directory in the SYSWOW64 path.. (C:\Windows\SysWOW64\config\systemprofile\AppData\LocalLow\Sun)

2. Create a directory junction called "Sun". Instead of a real folder, now there is a junction. Essentially both possible sun folders point to the same place:
   cmd /c mklink /J C:\Windows\SysWOW64\config\systemprofile\AppData\LocalLow\Sun C:\Windows\System32\config\systemprofile\AppData\LocalLow\Sun

3. Make sure that C:\ProgramData\Oracle\Java\java.settings.cfg exists, if you are trying to install via system,the install will fail if the file does not exist. The file might already exist on your system if you did a manual install, it will not exist in the rest of your environment, so make sure it is there on those systems too..

4. Install Java using the exe because it is better.. :
   jre-8u31-windows-i586.exe /s AUTO_UPDATE=0 INSTALL_SILENT=1 REBOOT=0 SPONSORS=0 WEB_ANALYTICS=0 /l* "C:\windows\temp\jre-8u31-windows-i586.log"

That should work for you..  hopefully..   I cannot say for sure whether it will fix issues with the MSI installer or not. Also.. if you like to leave automatic updates turned on, you may also need to create a junction the the oracle directory in the same path.

In order to deploy this to the masses.. you need to automate the prerequisite actions, this may work for you:

These install strings can be configured in an SCCM/ConfigMgr Application
Make sure you *do not* check the "run this process as 32 bit on 64 hosts", it will not work correctly because the 32 bit process will redirect references to C:\windows\system32 and your directory junction will not get created correctly.

Hopefully the the formatting does not get messed up: I placed left & right double quotation marks in the string surrounding the text for the java.settings.cfg file so that I did not have to deal with escaping the characters.. They are characters Alt+0147 () and Alt+0148 ()  the powershell command (-c) is surrounded by the normal quote character found on your keyboard.

#This one works for x86
powershell -noprofile -c "&{$ErrorActionPreference = 'SilentlyContinue';$l='C:\Windows\SysWOW64\config\systemprofile\AppData\LocalLow';$l32 = $l.replace('WOW64','tem32');$dir=gci $l -force | Where {$_.name -eq 'sun'};if((gwmi Win32_OperatingSystem).OSArchitecture -eq '64-bit' -and !(($dir.Attributes) -match 'ReparsePoint')){gci $l\Sun -Recurse | rm -recurse -force; rm $l\Sun -recurse -force;mkdir $l32\Sun;cmd /c mklink /J $l\Sun $l32\Sun|out-null;};$p=$env:allusersprofile+'\Oracle\Java';mkdir $p;AUTO_UPDATE=0`r`nEULA=0`r`nINSTALL_SILENT=1`r`nSPONSORS=0`r`nWEB_ANALYTICS=0| out-File $p'\java.settings.cfg' -Encoding ascii;.\jre-8u31-windows-i586.exe /s AUTO_UPDATE=0 INSTALL_SILENT=1 REBOOT=0 SPONSORS=0 WEB_ANALYTICS=0|out-null;$host.SetShouldExit($LastExitCode);}"

#This one works for x64
powershell -noprofile -c "&{$ErrorActionPreference = 'SilentlyContinue';$p=$env:allusersprofile+'\Oracle\Java';mkdir $p;AUTO_UPDATE=0`r`nEULA=0`r`nINSTALL_SILENT=1`r`nSPONSORS=0`r`nWEB_ANALYTICS=0| out-File $p'\java.settings.cfg' -Encoding ascii;.\jre-8u31-windows-x64.exe /s AUTO_UPDATE=0 INSTALL_SILENT=1 REBOOT=0 SPONSORS=0 WEB_ANALYTICS=0|out-null;$host.SetShouldExit($LastExitCode);}"

Perhaps there is a better way to do this which avoids the need for a directory junction. But this can help us (and oracle) learn how the installer behaves in the system context..  which they really need to learn about..  this Java bug submitted for Java 6 Update 25 would lead me to believe that they do know of the redirection issue: https://bugs.openjdk.java.net/browse/JDK-7014194 .. the original post contains this blurb which is interesting: "JRE 1.6.0_22 silent install is failing on WINDOW SERVER 2008 when done in system context (whatever that means)"  it seems that whoever logged this bug for the person reporting the issue is clueless to what the system account or system context means..

If oracle will make the necessary changes to the .exe so that it properly extracts and executes the 32 bit msi file on 64 bit machines.. that would be great. If they would also fix the issue with the java.settings.cfg file being written when the install is being silently performed (this is an issue with 32 and 64 bit installers), that would be awesome.. and if they would try to not break it in the future, that would be fantastic.

--

When picking which install options I would used. I used the properties extracted from the .msi file and referred to the oracle website which explains each option.

MSI options:
As extracted from the CustomAction \ SetCMDLine line item in the MSI:
{[SILENT]}{ INSTALLDIR="[INSTALLDIR]\"}{ WEB_JAVA=[WEB_JAVA]}{ WEB_JAVA_SECURITY_LEVEL=[WEB_JAVA_SECURITY_LEVEL]}{ STATIC=[STATIC]}{ WEB_ANALYTICS=[WEB_ANALYTICS]}{ INSTALLCFG="[INSTALLCFG]"}{ USAGETRACKER_CFG="[USAGETRACKER_CFG]"}{ DEPLOYMENT_RULE_SET="[DEPLOYMENT_RULE_SET]"}{ EULA=[EULA]}{ NOSTARTMENU=[NOSTARTMENU]}{ INSTALL_SILENT=[INSTALL_SILENT]}{ AUTO_UPDATE=[AUTO_UPDATE]}{ SPONSORS=[SPONSORS]}{ REPAIRMODE=[REPAIRMODE]}    


I Decided to use these options:
{[SILENT]} <- Notice that this is not a pair, I believe that [SILENT] is set to "/s" if you specified /s or "INSTALL_SILENT=1" on the command line for the exe.
And these:
{ WEB_ANALYTICS=[WEB_ANALYTICS]}{ INSTALL_SILENT=[INSTALL_SILENT]}{ AUTO_UPDATE=[AUTO_UPDATE]}{ SPONSORS=[SPONSORS]}

I Decided NOT to use:
{ WEB_JAVA=[WEB_JAVA]} *Default for WEB_JAVA is 1, specifying this on the cmd line is not needed.
{ WEB_JAVA_SECURITY_LEVEL=[WEB_JAVA_SECURITY_LEVEL]}, Defualt sec level is H.. specifying this on the cmd line is not needed.
{ STATIC=[STATIC]}
{ INSTALLDIR="[INSTALLDIR]\"}
{ INSTALLCFG="[INSTALLCFG]"}
{ USAGETRACKER_CFG="[USAGETRACKER_CFG]"}
{ DEPLOYMENT_RULE_SET="[DEPLOYMENT_RULE_SET]"}
{ EULA=[EULA]}
{ NOSTARTMENU=[NOSTARTMENU]}
{ REPAIRMODE=[REPAIRMODE]}

MSI option usage:
http://docs.oracle.com/javase/8/docs/technotes/guides/install/config.html#config_file_options

Pay attention to the fact that they do say you can use the options on the command line as well -> "You may use the same options at the command line when running the JRE Windows Offline Installer or the JRE MSI Enterprise Installer."

Marshall

• Edited by MarshallHarrison Friday, February 06, 2015 4:57 PM Spelling and Grammar

One source of the 1722 and 1619 errors might be due to the system profile having two different possible directories depending on whether the process is 32 bit or 64 bit. I believe that it was your post led me to this URL:

http://www.edugeek.net/forums/enterprise-software/143767-java-8-update-25-silent-install-via-sccm-7.html

As it was pointed out by 'sccmadmin' (Mike) in post #103, there seems to be some sort of bug in the 32 bit installer when it is running in the system account . What happens is: the installer writes the files to one directory, but then when it tries to start msiexec.. the msi is not found in the location where it was expecting it. This might be due to the installer calling the wrong msiexec? Or folder redirection issues..  I don't know specifically without seeing exactly what the exe installer is intending to do.

Mike also points out that when you do not use the exe file, you miss out on the language support that oracle builds in. While he does use an install config file (java.settings.cfg) in the command line, it is not required and it didn't help me overcome the need for that same file to be present in C:\ProgramData\Oracle\java ... so I omitted it from the install command line. Oracle either does not know the issue exists, or they are just not capable enough to fix it.  Mike used the approach of changing the system profile location, and with his admitted lack of a better option at the time,it was inventive and it did work for him. Relying on the script the change the system profile path back/forth every time was not something I wanted to do. But He did get me thinking. (thank you)

Here is the approach I took..

1. Delete or rename the Sun directory in the SYSWOW64 path.. (C:\Windows\SysWOW64\config\systemprofile\AppData\LocalLow\Sun)

2. Create a directory junction called "Sun". Instead of a real folder, now there is a junction. Essentially both possible sun folders point to the same place:
   cmd /c mklink /J C:\Windows\SysWOW64\config\systemprofile\AppData\LocalLow\Sun C:\Windows\System32\config\systemprofile\AppData\LocalLow\Sun

3. Make sure that C:\ProgramData\Oracle\Java\java.settings.cfg exists, if you are trying to install via system,the install will fail if the file does not exist. The file might already exist on your system if you did a manual install, it will not exist in the rest of your environment, so make sure it is there on those systems too..

4. Install Java using the exe because it is better.. :
   jre-8u31-windows-i586.exe /s AUTO_UPDATE=0 INSTALL_SILENT=1 REBOOT=0 SPONSORS=0 WEB_ANALYTICS=0 /l* "C:\windows\temp\jre-8u31-windows-i586.log"

That should work for you..  hopefully..   I cannot say for sure whether it will fix issues with the MSI installer or not. Also.. if you like to leave automatic updates turned on, you may also need to create a junction the the oracle directory in the same path.

In order to deploy this to the masses.. you need to automate the prerequisite actions, this may work for you:

These install strings can be configured in an SCCM/ConfigMgr Application
Make sure you *do not* check the "run this process as 32 bit on 64 hosts", it will not work correctly because the 32 bit process will redirect references to C:\windows\system32 and your directory junction will not get created correctly.

Hopefully the the formatting does not get messed up: I placed left & right double quotation marks in the string surrounding the text for the java.settings.cfg file so that I did not have to deal with escaping the characters.. They are characters Alt+0147 () and Alt+0148 ()  the powershell command (-c) is surrounded by the normal quote character found on your keyboard.

#This one works for x86
powershell -noprofile -c "&{$ErrorActionPreference = 'SilentlyContinue';$l='C:\Windows\SysWOW64\config\systemprofile\AppData\LocalLow';$l32 = $l.replace('WOW64','tem32');$dir=gci $l -force | Where {$_.name -eq 'sun'};if((gwmi Win32_OperatingSystem).OSArchitecture -eq '64-bit' -and !(($dir.Attributes) -match 'ReparsePoint')){gci $l\Sun -Recurse | rm -recurse -force; rm $l\Sun -recurse -force;mkdir $l32\Sun;cmd /c mklink /J $l\Sun $l32\Sun|out-null;};$p=$env:allusersprofile+'\Oracle\Java';mkdir $p;AUTO_UPDATE=0`r`nEULA=0`r`nINSTALL_SILENT=1`r`nSPONSORS=0`r`nWEB_ANALYTICS=0| out-File $p'\java.settings.cfg' -Encoding ascii;.\jre-8u31-windows-i586.exe /s AUTO_UPDATE=0 INSTALL_SILENT=1 REBOOT=0 SPONSORS=0 WEB_ANALYTICS=0|out-null;$host.SetShouldExit($LastExitCode);}"

#This one works for x64
powershell -noprofile -c "&{$ErrorActionPreference = 'SilentlyContinue';$p=$env:allusersprofile+'\Oracle\Java';mkdir $p;AUTO_UPDATE=0`r`nEULA=0`r`nINSTALL_SILENT=1`r`nSPONSORS=0`r`nWEB_ANALYTICS=0| out-File $p'\java.settings.cfg' -Encoding ascii;.\jre-8u31-windows-x64.exe /s AUTO_UPDATE=0 INSTALL_SILENT=1 REBOOT=0 SPONSORS=0 WEB_ANALYTICS=0|out-null;$host.SetShouldExit($LastExitCode);}"

Perhaps there is a better way to do this which avoids the need for a directory junction. But this can help us (and oracle) learn how the installer behaves in the system context..  which they really need to learn about..  this Java bug submitted for Java 6 Update 25 would lead me to believe that they do know of the redirection issue: https://bugs.openjdk.java.net/browse/JDK-7014194 .. the original post contains this blurb which is interesting: "JRE 1.6.0_22 silent install is failing on WINDOW SERVER 2008 when done in system context (whatever that means)"  it seems that whoever logged this bug for the person reporting the issue is clueless to what the system account or system context means..

If oracle will make the necessary changes to the .exe so that it properly extracts and executes the 32 bit msi file on 64 bit machines.. that would be great. If they would also fix the issue with the java.settings.cfg file being written when the install is being silently performed (this is an issue with 32 and 64 bit installers), that would be awesome.. and if they would try to not break it in the future, that would be fantastic.

--

When picking which install options I would used. I used the properties extracted from the .msi file and referred to the oracle website which explains each option.

MSI options:
As extracted from the CustomAction \ SetCMDLine line item in the MSI:
{[SILENT]}{ INSTALLDIR="[INSTALLDIR]\"}{ WEB_JAVA=[WEB_JAVA]}{ WEB_JAVA_SECURITY_LEVEL=[WEB_JAVA_SECURITY_LEVEL]}{ STATIC=[STATIC]}{ WEB_ANALYTICS=[WEB_ANALYTICS]}{ INSTALLCFG="[INSTALLCFG]"}{ USAGETRACKER_CFG="[USAGETRACKER_CFG]"}{ DEPLOYMENT_RULE_SET="[DEPLOYMENT_RULE_SET]"}{ EULA=[EULA]}{ NOSTARTMENU=[NOSTARTMENU]}{ INSTALL_SILENT=[INSTALL_SILENT]}{ AUTO_UPDATE=[AUTO_UPDATE]}{ SPONSORS=[SPONSORS]}{ REPAIRMODE=[REPAIRMODE]}    


I Decided to use these options:
{[SILENT]} <- Notice that this is not a pair, I believe that [SILENT] is set to "/s" if you specified /s or "INSTALL_SILENT=1" on the command line for the exe.
And these:
{ WEB_ANALYTICS=[WEB_ANALYTICS]}{ INSTALL_SILENT=[INSTALL_SILENT]}{ AUTO_UPDATE=[AUTO_UPDATE]}{ SPONSORS=[SPONSORS]}

I Decided NOT to use:
{ WEB_JAVA=[WEB_JAVA]} *Default for WEB_JAVA is 1, specifying this on the cmd line is not needed.
{ WEB_JAVA_SECURITY_LEVEL=[WEB_JAVA_SECURITY_LEVEL]}, Defualt sec level is H.. specifying this on the cmd line is not needed.
{ STATIC=[STATIC]}
{ INSTALLDIR="[INSTALLDIR]\"}
{ INSTALLCFG="[INSTALLCFG]"}
{ USAGETRACKER_CFG="[USAGETRACKER_CFG]"}
{ DEPLOYMENT_RULE_SET="[DEPLOYMENT_RULE_SET]"}
{ EULA=[EULA]}
{ NOSTARTMENU=[NOSTARTMENU]}
{ REPAIRMODE=[REPAIRMODE]}

MSI option usage:
http://docs.oracle.com/javase/8/docs/technotes/guides/install/config.html#config_file_options

Pay attention to the fact that they do say you can use the options on the command line as well -> "You may use the same options at the command line when running the JRE Windows Offline Installer or the JRE MSI Enterprise Installer."

Marshall

• Edited by MarshallHarrison Friday, February 06, 2015 4:57 PM Spelling and Grammar

Here is my script I use to deploy Java 8 update 31. I set it to run at Logon of the users I found that works best. I have some sites in the "Exception Sites" list and a few settings in the "Deployment Properties" file. I also tell it to run from the Distribution Point which also fixed some other errors I was having.

REM Uninstalls versions of Java 8 update 5, Update 20, Update 25.
REM Remarked out uninstall command for 7

taskkill /F /IM iexplore.exe
START /wait MsiExec.exe /X{26A24AE4-039D-4CA4-87B4-2F83218005FF} /quiet
START /wait Msiexec.exe /X{26A24AE4-039D-4CA4-87B4-2F83218020F0} /quiet
START /wait Msiexec.exe /X{26A24AE4-039D-4CA4-87B4-2F83218025F0} /quiet
START /wait \\sccm-server\smspkgd$\A01002E2\jre1.8.0_31.msi /qn /L C:\Java8Update31DeployLog.txt
mkdir C:\windows\sun\java\deployment
COPY \\sccm-server\smspkgd$\A01002E2\deployment.properties %SystemRoot%\Sun\Java\Deployment\ /Y
COPY \\sccm-server\smspkgd$\A01002E2\exception.sites %SystemRoot%\Sun\Java\Deployment\ /Y

Why are you refering to \\ -paths? You could simple refer to .\ or %CD% instead, run from DP isn't needed in this case as the files in your A01002E2 -package are downloaded to %windir%\ccmcache and run from there locally, the way ConfigMgr is designed to work.

Marshall,

     I played around with the suggestions you made regarding the directory junction and didn't get anywhere. I have tried both the .MSI approach (which is what I originally wrote about) and I just finished testing the .exe approach and in both cases I get the same thing. Both the 32-bit and 64-bit installers come back with this issue. I think I am going to have to eschew the Powershell Deployment Toolkit for a plain vanilla SCCM command line deployment (though I have to test that too). It seems so strange the this package installs just fine with the command line switches when I execute them from the command line manually but as soon as I use Powershell to do the same thing, everything breaks.

Thanks,
Chris

Just a suggestion here... when you are running the command, you need to be cognizant of where the script and source is located.

When you run:

msiexec.exe /I "jre1.8.0_31.msi" JU=0 JAVAUPDATE=0 AUTOUPDATECHECK=0 RebootYesNo=No WEB_JAVA=1 /q

It is assumed that the jre1.8.0_31.msi is in the same directory as where the script is executing from. If so, then you need to append a ".\" to the MSI location to tell Powershell to use something relative to that file.

This would look like:

msiexec.exe /I ".\jre1.8.0_31.msi" JU=0 JAVAUPDATE=0 AUTOUPDATECHECK=0 RebootYesNo=No WEB_JAVA=1 /q

I have had problems in the past using msiexec with the command parameters in powershell, so instead I do the following (which serves to be more robust):

$arguments = "/I `"jre1.8.0_31.msi`" JU=0 JAVAUPDATE=0 AUTOUPDATECHECK=0 RebootYesNo=No WEB_JAVA=1 /q"
Start-Process msiexec.exe -ArgumentList $arguments -NoNewWindow -wait

The things that made my deployment come together were:

1.  Putting that "java.settings.cfg" file under "C:\ProgramData\Sun\Java" BEFORE the deployment took off.  I did this by creating an application and deployed it, and I made that application a requirement before my Actual Java Deployment.  I also made a requirement that the Java.settings.cfg must be in place before the Java 8 Update 31 installer will even begin. 

2.  Making sure to check that the install only runs when a user is logged on. Running while a user is not logged on, under the system account doesn't seem to work for me.

3.  Running the EXE vs the MSI installer "jre-8u31-windows-i586.exe /s NOSTARTMENU=1 AUTO_UPDATE=0 INSTALL_SILENT=1 REBOOT=0 SPONSORS=0 WEB_ANALYTICS=0"

I know there are a bunch of ways of doing this, but this has seemed close to 100% effective in my situation, and so far after testing on 65 users, I've not heard a word yet.

Installation with NT/SYSTEM Account -> Using SCCM 2012 R2

My Solution....
Not Working under Windows 7 x64:

msiexec /i "jre1.8.0_31_x64.msi" /qn AUTO_UPDATE=0 WEB_JAVA_SECURITY_LEVEL=H EULA=0 /Log C:\Java_install_x64.log --> Error 1603 /1722

Working under Windows 7 x64 without Parameters:

msiexec /i "jre1.8.0_31_x64.msi" /qn /Log C:\Java_install_x64.log

Parameters eq. Auto_Update should been set with GPO.

It seems the MSI Installer have Problems with the "Java" Parameters under the NT/System Account. (Bug from Java)

Regards
Florian.

Found these, which might hopefully be fixed soon:

https://bugs.openjdk.java.net/browse/JDK-8073434

and

https://bugs.openjdk.java.net/browse/JDK-7014194

Per the backport of JDK-7014194 - https://bugs.openjdk.java.net/browse/JDK-8033129 - this is due to be fixed in 8u45, due out with the April 14th CPU release.

Thanks for the update, Stephen.  Your presence here to provide this update is very welcome.

Fixing this bug will help adoption rates for Java 8, which is very low according my peers in the patch management community.  It's coming just in time, too, as Java 7 goes out of support.

 I came across this post to check on the latest on this issue.  it seems the jre8 command line has been changed compared to the jre7.  with jre7, silent installs worked effortlessly with "/s /v /qn REBOOT=ReallySuppress"

Now jre8 is throwing errors with this same command lines switches for a silent upgrade. 

The workaround appears to be just uninstalling the previous versions then installing jre8 with the "/s" switch for silent install.  the previous jre configuration settings appears to be kept such as the security exception sites.  

More of info here for jre8

https://docs.oracle.com/javase/8/docs/technotes/guides/install/windows_installer_options.html#CJAJGEHA

• Edited by PSUOH 9 hours 5 minutes ago

I posted all my deployment scripts and required additional files at:

http://www.itninja.com/software/oracle/java-8/8-update-40

Look out for the post by "nzdude"

I tested this for 8 update 45 and it's working like a dream.



• Edited by nzdude 9 hours 24 minutes ago more info

 I came across this post to check on the latest on this issue.  it seems the jre8 command line has been changed compared to the jre7.  with jre7, silent installs worked effortlessly with "/s /v /qn REBOOT=ReallySuppress"

Now jre8 is throwing errors with this same command lines switches for a silent upgrade. 

The workaround appears to be just uninstalling the previous versions then installing jre8 with the "/s" switch for silent install.  the previous jre configuration settings appears to be kept such as the security exception sites.  

More of info here for jre8

https://docs.oracle.com/javase/8/docs/technotes/guides/install/windows_installer_options.html#CJAJGEHA

• Edited by PSUOH Thursday, April 16, 2015 10:42 PM

I posted all my deployment scripts and required additional files at:

http://www.itninja.com/software/oracle/java-8/8-update-40

Look out for the post by "nzdude"

I tested this for 8 update 45 and it's working like a dream.



• Edited by nzdude Thursday, April 16, 2015 10:23 PM more info

I have been using this method since java 6 update 45 and it has never let me down (currently we are deploying java 8 update 40). Maybe try putting the options in a transform?

I am not certain what WEB_JAVA does bit IIRC this wasn't in the properties table of the MSI. I am probably wrong on this just thought I would mention it.

As long as you are extracting the MSI from the exe you shouldn't have any issues. It's worth noting that the property's that disabled old versions of JRE no longer work on newer releases as there is a built in expiration date, This is from 8.0.25

Expiration:

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u45) will expire with the release of the next critical patch update scheduled for July 14, 2015.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u45) on August 14, 2015. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.

http://www.oracle.com/technetwork/java/javase/8u45-relnotes-2494160.html

As long as this URL is blocked you have 30 days post the first expiration until you clients will start complaining of available updates.  

https://javadl-esd-secure.oracle.com/update/baseline.version

As long as you are extracting the MSI from the exe you shouldn't have any issues. It's worth noting that the property's that disabled old versions of JRE no longer work on newer releases as there is a built in expiration date, This is from 8.0.25

Expiration:

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u45) will expire with the release of the next critical patch update scheduled for July 14, 2015.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u45) on August 14, 2015. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.

http://www.oracle.com/technetwork/java/javase/8u45-relnotes-2494160.html

As long as this URL is blocked you have 30 days post the first expiration until you clients will start complaining of available updates.  

https://javadl-esd-secure.oracle.com/update/baseline.version

• Proposed as answer by dotps1 12 hours 56 minutes ago
• Unproposed as answer by dotps1 12 hours 56 minutes ago

Thank you for this post, your step 3, saved the day for me. And I have built a fully functional PS script to download and extract the java msi's, and then build a full application in SCCM. it will not create the deployment. ( I was a bit scared of that part ;))

anyway, here is the syntax

New-SccmJavaApplication -SourceCreationPath <String> -SccmServer <String> -SccmSiteCode <String> [-SccmApplicationFolder <String>] [-CodeSigningCertificate <X509Certificate2>] [ <CommonParameters>]

Example:

New-SccmJavaApplication -SourceCreationPath \\mySccmServer\Sources -SccmServer SccmServer -SiteCode 1AB -SccmApplicationFolder 'Java RuntimeEnvironment' -Verbose

The -Verbose will give full output.  You will need to run the script as an admin for the Java MSI Extraction.  Here is the source code: New-SccmJavaApplication.  Its a lot of code I know, but it works well

Thanks again for the tip about the cfg in the programdata dir.  that was the catalyst!