Script not Installing Java-Application if used as SCCM-Application Package

[2SR82]

Hello,

 

I'm using the very good script from "http://psappdeploytoolkit.com/"since about 2 years now. Never had big problems with it, but now I have the following strange behavior. Not sure if it's SCCM or Script related, so I will ask on both places ;-)

 

I have a strange behavior trying to deploy Java 8 Update 91/92.

Until now I had used the Toolkit for deploying the extracted MSIs of the Java Installer without Problems.

Since the last 2 or 3 releases, Oracle seems to have changed something in the MSI (64bit) so that it shows an error when trying to install and I’m forced now to use there EXE Installer.

I’m executing the Installer with the following line:

Execute-Process -FilePath "$myEXENameX86" -Arguments "/s AUTO_UPDATE=0 REBOOT=0 SPONSORS=0 /L `"$env:windir\Logs\Software\$myEXENameX86.log`"" -WaitForMsiExec -PassThru

If I execute the script by right click and “run as Administrator”, everything runs fine and the Installer finishes successfull.
But if I now create a package from this script and deploy it with our SCCM Infrastructur (as Application) the Script starts fine, executing the EXE, getting back the Exit Code 0 but nothing is installed!
part of the LOG:

[Installation] :: [jre-8u92-windows-i586.exe] successfully resolved to fully qualified path [C:\WINDOWS\ccmcache\f\Files\jre-8u92-windows-i586.exe].	Execute-Process	11.07.2016 10:09:33	3700 (0x0E74)
[Installation] :: Check to see if mutex [Global\_MSIExecute] is available. Wait up to [10 minute(s)] for the mutex to become available.	Test-IsMutexAvailable	11.07.2016 10:09:33	3700 (0x0E74)
[Installation] :: Mutex [Global\_MSIExecute] is available for an exclusive lock.	Test-IsMutexAvailable	11.07.2016 10:09:33	3700 (0x0E74)
[Installation] :: Working Directory is [C:\WINDOWS\ccmcache\f\Files].	Execute-Process	11.07.2016 10:09:34	3700 (0x0E74)
[Installation] :: Executing [C:\WINDOWS\ccmcache\f\Files\jre-8u92-windows-i586.exe /s AUTO_UPDATE=0 REBOOT=0 SPONSORS=0 /L "C:\WINDOWS\Logs\Software\jre-8u92-windows-i586.exe.log"]...	Execute-Process	11.07.2016 10:09:34	3700 (0x0E74)
[Installation] :: Execution completed with exit code [0].	Execute-Process	11.07.2016 10:10:08	3700 (0x0E74)

The Installer of Java even didn’t create a own Logfile if I start the Script over the SCCM deployment. This is independent if I start the Application-Installation from the Application Catalog (as User) or deploy it directly to the System (Device).
If I’m now going to the local Cache folder of the Application and start it again via Right Click > run as Admin, everything installs fine again.

(perhaps I had a similar issue with the Adobe Acrobat Installer a few weeks ago, there was a missing IE-Plugin after the Installation, but I hadn’t verified it now.)

I’m not sure if this is a Problem with the Toolkit or with SCCM. We are using Version 1511 (5.0.8325.1000) of SCCM and PSADT-Script Version 3.6.8. Perhaps anyone have a hint for me what I can try to solve. I can’t imagine to work without the toolkit

Thanks for any help!

[TrialandError]

I am seeing this exact behavior in a 2012 R2 environment when using the .exe installer but I am not using the PSappdeploy kit. Running the script manually or as the system account works perfectly. I have tried the traditional software package and the scripted application. I can upload the logs if needed but they are pretty much the same as above.

[GarthMJ]

Have you run your script/exe as the local system account?

https://verbalprocessor.com/2007/12/05/running-a-cmd-prompt-as-local-system/

[TrialandError]

Yes it installed correctly when running as the local system account.

[GarthMJ]

Have you tried it as an x86 cmd?

[2SR82]

Hello,

thanks for your help!

Meanwhile I have found a solution for my Problem here:

https://social.technet.microsoft.com/Forums/en-US/0e831d5e-b607-4cd5-8c9f-0e94eaca8d8f/deploying-java-8-u-40-with-powershell-application-deployment-toolkit-works-fine-locally-but-fails?forum=configmanagerapps

Seems that it has something to do with the AppData Environment Variable. I could easily solve the problem with copying the "java.settings.cfg" described in the last Post for now.

We will see how long it works until Oracle will change something again.