GPO – Deploying Java 8 Update 60

Update 19/05/2016: Added other version info.

Extracting the MSI

To extract the MSI, run the “jre-8u60-windows-i586.exe” or  “jre-8u60-windows-x64.exe” EXE do not proceed with the installation. Open the folder “%LOCALAPPDATA%Low\Oracle\Java”, depending if you ran the i586 or x64 version you will see one of the following folders.

  • jre1.8.0_60
  • jre1.8.0_60_x64

Open up the correct folder, and within the folder you will see the MSI file “jre1.8.0_60.msi”. Copy this MSI to another location then cancel the installation.

Silent Install Error

Now that you have the MSI file you have probably tried to install it from the command line using “msiexec /qb /i jre1.8.0_60.msi”. If you used a command prompt that isn’t elevated you get the following error in the event viewer, even though you elevate the MSI installation.

“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.”

MSI Fixes

The reason for the error above is that the MSI executes an installer that is embedded into the MSI, but when it runs this installer it doesn’t run it with administrative privileges instead it runs it in the logged on users security context. To fix this you need to modify the MSI DB with an MSI DB editor such as Orca (My personal preference is InstED http://www.instedit.com/). Open the MSI in your editor of choice and open up the table “CustomAction” and select the row “installexe” and change the value of the field “Type” to decimal 3090 or hexadecimal 0x0C12. This will set the msidbCustomActionTypeNoImpersonate bit so that it runs the embedded installer with administrative privileges.

Once the change above has been made the installer will now fail with the following error.

“Unable to install Java. Unable to open file C:\ProgramData\Oracle\Java\java.settings.cfg. Check that the configuration file exists and that the path to the file is correct.”

To fix this error an empty configuration file “java.settings.cfg” needs to be added to the “%ALLUSERSPROFILE%\Oracle\Java” folder by the installer. To do this we need to add 6 new entries to various tables in the MSI DB.

Once again open the MSI in your editor of choice and perform the following:

  1. Insert a new row into the table “Directory”
    • Directory Field = CommonAppDataFolder
    • Directory_Parent Field = TARGETDIR
    • DefaultDir Field = .:Common~1|CommonAppData
  2. Insert a new row into the table “Directory”
    • Directory Field = OracleDir
    • Directory_Parent Field = CommonAppDataFolder
    • DefaultDir Field = Oracle
  3. Insert a new row into the table “Directory”
    • Directory Field = JavaDir
    • Directory_Parent Field = OracleDir
    • DefaultDir Field = Java
  4. Insert a new row into the table “Component”
    • Component Field = emptycfgComponent
    • ComponentId Field = <Insert GUID>
    • Directory_  Field = JavaDir
    • Attributes Field = Decimal 0 or Hexadecimal 0x0000
    • Condition Field = <null>
    • KeyPath Field = <null>
  5. Insert a new row into the table “FeatureComponents”
    • Feature_ Field = jrecore
    • Component_ Field = emptycfgComponent
  6. Insert a new row into the table “File”
    • File Field = java.settings.cfg
    • Component_ Field = emptycfgComponent
    • FileName Field = java~1.cfg|java.settings.cfg
    • FileSize Field = 0
    • Version Field = <null>
    • Language Field = <null>
    • Attributes Field = Decimal 8192 or Hexidecimal 0x2000
    • Sequence Field = 2
  7. Insert a new row into the table “Media”
    • DiskId Field = 2
    • LastSequence Field = 2
    • DiskPrompt Field = <null>
    • Cabinet Field = <null>
    • VolumeLabel Field = <null>
    • Source Field = <null>
  8. Insert a new row into the table “RemoveFile”
    • FileKey Field = java.settings.cfg
    • Component_ Field = emptycfgComponent
    • FileName Field = java~1.cfg|java.settings.cfg
    • DirProperty Field = JavaDir
    • InstallMode Field = 3

This adds a reference to the file in the installer DB, now you need to create an empty “java.settings.cfg” file. To do this open the folder where the MSI is located and create the folder structure “CommonAppData\Oracle\Java” and then within the “Java” folder create an empty file called “java.settings.cfg”.

The last thing to be done is to set the embedded installer so that it installs silently when the UI level is set to “Basic UI” (/qb switch) , the current configuration is that it only installs silently if the UI level is set to “No UI” (/qn switch). To change this open the MSI in your editor and open the table “InstallExecuteSequence”, within that table locate the action “SetSilentInstall” and change the condition from “UILevel=2” to “UILevel<=3”.

With the changes above you will find that the MSI installer should work as expected.

Customisations

There are many articles out on the web on how to customise the installation of Java 7 by changing/adding properties to the “Properties” table in the MSI, the same properties still apply. Here are the ones that I’ve chosen to set in our deployment.

Disable Java Auto Update

  • AUTO_UPDATE=0
  • AUTOUPDATECHECK=0
  • JU=0
  • JAVAUPDATE=0

Disable the EULA

  • EULA=0

Disable the installation Java with sponsored software

  • SPONSORS=0

Lower the web Java security level (Note: High is the lowest setting in Java 8)

  • WEB_JAVA_SECURITY_LEVEL=H

Disable the sending of  installation-related statistics to Oracle

  • WEB_ANALYTICS=0

Transform File (MST)

Once I’ve amended the MSI file I create a transform file, with InstED this is an easy process of comparing your modified MSI with an unmodified file. I then use this for both the X86 and X64 versions of the Java MSI and it’ll hopefully it’ll be compatible with the next version that comes out, which saves time and effort of doing this again :-).

Deployment

I’ve only tested the deployment through the command line with both elevated and un-elevated command prompts, other people have deployed Java 8 based on my previous post via GPO successfully so it will more than likely work for this version as well.

Other Versions

There have been reports in the comments that this will also works for the newer versions of Java 8. I haven’t personally verified that they work as my work and home life are hectic at the moment, and at the time of writing I believe it works for the following versions.

  • Java 8 Update 92
  • Java 8 Update 91
  • Java 8 Update 77
  • Java 8 Update 74
  • Java 8 Update 73
  • Java 8 Update 72
  • Java 8 Update 71
  • Java 8 Update 66
  • Java 8 Update 65
Advertisements

GPO – Deploying Java 8 Update 25

Update 09/09/2015: If you are deploying Java 8 Update 60 please see my updated post GPO – Deploying Java 8 Update 60 as Oracle have made some changes to the MSI that means the instructions below no longer work.

Extracting the MSI

To extract the MSI, run the “jre-8u25-windows-i586.exe” or  “jre-8u25-windows-x64.exe” EXE do not proceed with the installation. Open the folder “%LOCALAPPDATA%Low\Sun\Java”, depending if you ran the i586 or x64 version you will see one of the following folders.

  • jre1.8.0_25
  • jre1.8.0_25_x64

Open up the correct folder, and within the folder you will see the MSI file “jre1.8.0_25.msi”. Copy this MSI to another location then cancel the installation.

Silent Install Error

Now that you have the MSI file you have probably tried to install it from the command line using “msiexec /qb /i jre1.8.0_25.msi”. If you used a command prompt that isn’t elevated you get the following error in the event viewer, even though you elevate the MSI installation.

“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.”

MSI Fixes

The reason for the error above is that the MSI executes an installer that is embedded into the MSI, but when it runs this installer it doesn’t run it with administrative privileges instead it runs it in the logged on users security context. To fix this you need to modify the MSI DB with an MSI DB editor such as Orca (My personal preference is InstED http://www.instedit.com/). Open the MSI in your editor of choice and open up the table “CustomAction” and select the row “installexe” and change the value of the field “Type” to decimal 3074 or hexadecimal 0x0C02. This will set the msidbCustomActionTypeNoImpersonate bit so that it runs the embedded installer with administrative privileges.

Once the change above has been made the installer will now fail with the following error.

“Unable to install Java. Unable to open file C:\ProgramData\Oracle\Java\java.settings.cfg. Check that the configuration file exists and that the path to the file is correct.”

To fix this error an empty configuration file “java.settings.cfg” needs to be added to the “%ALLUSERSPROFILE%\Oracle\Java” folder by the installer. To do this we need to add 6 new entries to various tables in the MSI DB.

Once again open the MSI in your editor of choice and perform the following:

  1. Insert a new row into the table “Directory”
    • Directory Field = OracleDir
    • Directory_Parent Field = CommonAppDataFolder
    • DefaultDir Field = Oracle
  2. Insert a new row into the table “Directory”
    • Directory Field = JavaDir
    • Directory_Parent Field = OracleDir
    • DefaultDir Field = Java
  3. Insert a new row into the table “Component”
    • Component Field = emptycfgComponent
    • ComponentId Field = <Insert GUID>
    • Directory_  Field = JavaDir
    • Attributes Field = Decimal 0 or Hexadecimal 0x0000
    • Condition Field = <null>
    • KeyPath Field = <null>
  4. Insert a new row into the table “FeatureComponent”
    • Feature_ Field = jrecore
    • Component_ Field = emptycfgComponent
  5. Insert a new row into the table “File”
    • File Field = java.settings.cfg
    • Component_ Field = emptycfgComponent
    • FileName Field = java~1.cfg|java.settings.cfg
    • FileSize Field = 0
    • Version Field = <null>
    • Language Field = <null>
    • Attributes Field = Decimal 8192 or Hexidecimal 0x2000
    • Sequence Field = 1
  6. Insert a new row into the table “Media”
    • DiskId Field = 2
    • LastSequence Field = 1
    • DiskPrompt Field = <null>
    • Cabinet Field = <null>
    • VolumeLabel Field = <null>
    • Source Field = <null>

This adds a reference to the file in the installer DB, now you need to create an empty “java.settings.cfg” file. To do this open the folder where the MSI is located and create the folder structure “CommonAppData\Oracle\Java” and then within the “Java” folder create an empty file called “java.settings.cfg”.

The last thing to be done is to set the embedded installer so that it installs silently when the UI level is set to “Basic UI” (/qb switch) , the current configuration is that it only installs silently if the UI level is set to “No UI” (/qn switch). To change this open the MSI in your editor and open the table “InstallExecuteSequence”, within that table locate the action “SetSilentInstall” and change the condition from “UILevel=2” to “UILevel<=3”.

With the changes above you will find that the MSI installer should work as expected.

Customisations

There are many articles out on the web on how to customise the installation of Java 7 by changing/adding properties to the “Properties” table in the MSI, the same properties still apply. Here are the ones that I’ve chosen to set in our deployment.

Disable Java Auto Update

  • AUTO_UPDATE=0
  • AUTOUPDATECHECK=0
  • JU=0
  • JAVAUPDATE=0

Disable the EULA

  • EULA=0

Disable the installation Java with sponsored software

  • SPONSORS=0

Lower the web Java security level (Note: High is the lowest setting in Java 8)

  • WEB_JAVA_SECURITY_LEVEL=H

Disable the sending of  installation-related statistics to Oracle

  • WEB_ANALYTICS=0

Transform File (MST)

Once I’ve amended the MSI file I create a transform file, with InstED this is an easy process of comparing your modified MSI with an unmodified file. I then use this for both the X86 and X64 versions of the Java MSI and it’ll hopefully it’ll be compatible with the next version that comes out, which saves time and effort of doing this again :-).

Deployment

I’ve only tested the deployment through the command line with both elevated and un-elevated command prompts. My plan is to deploy Java 8 using GPO, but I’ve not managed to test this yet, I will update this post once I have . If you do manage to test deploying via GPO before I do, please let me know and I’ll update this post accordingly.

 

GPO – Issue Deploying A Scheduled Task Running As “SYSTEM”

Recently whilst doing our windows 8.1 deployment I came across an issue where a computer based schedule task running as “SYSTEM” wasn’t applying. After doing some research and trying a few things depending how you set the task up you got one of the two error below:

  1. The computer ‘********’ preference item in the ‘OU Policies {********}’ Group Policy object did not apply because it failed with error code ‘0x80070534 No mapping between account names and security IDs was done.’ This error was suppressed.
  2. The computer ‘********’ preference item in the ‘OU Policies {********}’ Group Policy object did not apply because it failed with error code ‘0x80041316 The task XML contains an unexpected node.’ This error was suppressed.

Both the error codes point to the same issue, when creating a schedule task that runs as “NT AUTHORITY\SYSTEM”

The issue lies in the fact that the schedule task runs is set to run as the “SYSTEM” account. In the group policy preferences “Schedule Task (Windows Vista and later)” window you get two different results when looking up the system account.

  1. You get “NT AUTHORITY\SYSTEM” when you lookup the account on a domain.
  2. You get “BUILTIN\SYSTEM” when you lookup the account on a computer.

When you look it up by computer, it appears as if it’s working correctly as the security options grey out. When the policy is deployed though the computer it’s unable to lookup “BUILTIN\SYSTEM” as a security principal and fails to deploy (See error 1). When looked up by domain or by manually entering “NT AUTHORITY\SYSTEM” the security options do not grey out. Again when it’s deployed to a computer it fails with the error that it’s unable to deploy the task as it has an unexpected XML node (See error 2).

The only way I’ve found to work around this issue is to:

  1. Set the user as “NT AUTHORITY\SYSTEM”.
  2. Select the “Run only when user is logged on” option.
  3. Manually edit the XML file that the policy creates, and remove the XML node <LogonType>InteractiveToken</LogonType> from the task in question.

The XML file for the schedule tasks (1 file per group policy, multiple tasks per file) can be located in this location on the domain:

\\<DNSDomainName>\sysvol\<DNSDomainName>\Policies\<GroupPolicyUniqueID>\Machine\Preferences\ScheduledTasks\ScheduledTasks.xml

Here are the contents of the file with the XML node still in it. To make the file readable I have expanded the XML.

<?xml version="1.0" encoding="utf-8"?>
<ScheduledTasks clsid="{CC63F200-7309-4ba0-B154-A71CD118DBCC}">
  <TaskV2 clsid="{D8896631-B747-47a7-84A6-C155337F3BC8}" name="EMET Config Refresh" image="1" changed="2014-09-10 12:31:37" uid="{4501D60E-1D83-45A1-8A51-0D4CF9D8432A}" userContext="0" removePolicy="1">
    <Properties action="R" name="EMET Config Refresh" runAs="NT AUTHORITY\SYSTEM" logonType="Group">
      <Task version="1.3">
        <RegistrationInfo>
          <Author>TEST\AdminUser</Author>
          <Description></Description>
        </RegistrationInfo>
        <Principals>
          <Principal id="Author">
            <RunLevel>HighestAvailable</RunLevel>
            <GroupId>NT AUTHORITY\SYSTEM</GroupId>
            <LogonType>InteractiveToken</LogonType>
          </Principal>
        </Principals>
        <Settings>
          <IdleSettings>
            <Duration>PT5M</Duration>
            <WaitTimeout>PT1H</WaitTimeout>
            <StopOnIdleEnd>false</StopOnIdleEnd>
            <RestartOnIdle>false</RestartOnIdle>
          </IdleSettings>
          <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
          <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
          <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
          <AllowHardTerminate>true</AllowHardTerminate>
          <AllowStartOnDemand>true</AllowStartOnDemand>
          <Enabled>true</Enabled>
          <Hidden>false</Hidden>
          <ExecutionTimeLimit>P3D</ExecutionTimeLimit>
          <Priority>7</Priority>
        </Settings>
        <Triggers>
          <EventTrigger>
            <Enabled>true</Enabled>
            <Subscription>&lt;QueryList&gt;&lt;Query Id="0" Path="Application"&gt;&lt;Select Path="Application"&gt;*[System[Provider[@Name='SceCli'] and EventID=1704]]&lt;/Select&gt;&lt;/Query&gt;&lt;/QueryList&gt;</Subscription>
          </EventTrigger>
        </Triggers>
        <Actions>
          <Exec>
            <Command>%ProgramFiles(x86)%\EMET 5.0\EMET_Conf.exe</Command>
            <Arguments>--refresh</Arguments>
          </Exec>
        </Actions>
      </Task>
    </Properties>
  </TaskV2>
</ScheduledTasks>

After this has been done the schedule task will deploy and work as expected, but if the scheduled task that was modifed is edited you will need to reapply this workaround.

As of writing this issue still exists in Windows Server 2012 R2.