Java updates

[sburrows]

My current machines have Java 7 update 25 installed. I am trying to push down Java 7 update 45. I created the package for Jave7u45 in composer and pushed it to a test machine by using a policy. The policy log states that everything went fine and installed, but when I check the Java version details it still says it is on update 25.

Anyone else run in to this? Am I doing something wrong packaging it?

[mm2270]

Any particular reason you're repackaging the Java install? its already in a valid package format. so there's no need in my experience to do anything other than upload the pkg file into Casper Admin and deploy via policy.

I think before anyone can effectively help you, you might want to try using the Oracle supplied installer as is and seeing what the results are.

[sburrows]

To my understanding the reason we are repackaging is because we want to set the settings so it doesn't check for updates. Our users do not have Admin access so they won't be able to install it if they get prompt.

[Jeff-JAMF]

Have you tried using the Version 7 Update 45 package as is (i.e. without using Composer)? This downloads as "jre-7u45-macosx-x64.dmg" - when you open the DMG, the Java 7 update 45.pkg can be uploaded via Casper Admin and deployed to clients via a policy or Casper Remote.

Link: http://www.java.com/en/download/index.jsp

[mm2270]

@Burrows
OK, I get what you're saying, but I'd encourage you to think about policy deployments in a more modular way. understand you want to set the auto update settings for Java, but that doesn't mean you need to repackage the whole Java install just to get that setting in. Policies can install as many individual packages as you want, even if they are from Self Service, so they don't always need to be rolled into a single installer. Now, there is sometimes value in having everything contained in a single package, especially if you also use them with an app like Remote Desktop, so I'm not saying its without merit, (and there are ways to achieve that and still keep things separate) but in this case, I'd try separating out the change for the auto update settings into one pkg and leave the existing Java Update install from Oracle as-is. Throw both into your policy, possibly setting a later priority for the settings package so it gets installed after the regular Java one.

See if you can do that and try it out. I just would not repackage the Java install if I were you, as its asking for trouble in many cases.

If you do decide you want to go that route, consider looking at autopkg as it has some vetted ways of handling that. (re-packaging)

[andrew_stenehje]

You can see this thread for reference to trying to manage java settings by running a script after installing java:

https://jamfnation.jamfsoftware.com/discussion.html?id=6489

[sburrows]

Thanks everyone! I appreciate the help. I will give your suggestions a try tomorrow. I am going to try the Oracle pkg and scripting the update preference.

[scottb]

A couple things. We are using the Java-supplied pkg in Self Service just fine as-is.
There was a bug in 7_25 where it said it was "up to date" and it wasn't. I believe that was fixed in 7_40.
We've had zero errors delivering the Java supplied pkg in Self Service.

[rfreeborn]

With Java 7 installer I have found no need to run through composer. Just upload the Java 7 update 45 package to JSS and set policy and scope. For some reason Composer Snapshot does not notice update and just builds package with original plugin so you end up with a package that just installs what ever Java you had installed. Another option is to use package manifest in composer after you have installed Java and it will build package with the updated version as it pulls correct components from finder paths.