Software Management Group

 View Only

Updating Java through Managed Software Delivery Policy 

Nov 04, 2013 02:39 PM

** Since creating this article when java 7u45 came out, I've updated my process a bit, and created an updated article - if you're looking for info on updating Java you might get better info at this link **

This is a walk through of how we plan to deploy the latest version of Java.  We use a managed software delivery policy instead of patch management so we can customize the installer to (hopefully) not prompt user for updates.  Hope it helps someone.

1)      Download the latest offline installer from  http://www.java.com/en/download/manual.jsp

2)      Extract the MSI using these directions http://www.java.com/en/download/help/msi_install.xml

3)      Copy .cab and .msi to folder on desktop

4)      Open InstEd and do file Open and select copied .msi

5)      Select Transform, new transform

6)      In same folder where .cab and .msi file are, create transform named like jre1.7.0_45.mst

7)      Under the "Property table" add following PROPERTIES: 

a.      AUTOUPDATECHECK=0
b.      IEEXPLORER=1
c.      JAVAUPDATE=0
d.      JU=0
e.      MOZILLA=1
f.       RebootYesNo=No

When you reopen InstEd it shows you values you changed on top, like below for easy double checking
1.png

8)      Go to Registry Table and right click in window and select add row, registry: String and enter Key

a.       Registry = NotifyDownload
b.      Root = 2
c.       Key = Software\JavaSoft\Java Update\Policy
d.      Name = NotifyDownload
e.      Value = 0
f.        Component_ = jz

2.png

9)      Create (or copy existing) deployment.config and deployment.properties file to same folder where .cab, .mst, and .mst files are.  These are plain text files. 

a.       Our deployment.config file following 2 lines

deployment.system.config.mandatory=true
deployment.system.config=file:\\C\:\\Windows\\Sun\\Java\\Deployment\\deployment.properties

b.      Our deployment.properties file is following 2 lines

deployment.javaws.autodownload=NEVER
deployment.javaws.autodownload.locked

You can add more options to properties file based on what’s available in current release. See http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/properties.html

The folder on the desktop should now have 5 files, data1.cab, deployment.config, deployment.properties, .msi file and .mst file.

10)      Open CMS and navigate to Manage – Software Catalog - Import

11)      Click plus button and navigate to folder where all 5 java related files exist, select all files and then select open

12)      Make sure .msi file is bolded, if not highlight it and select “Set Installation File”

13)      Select Next, files upload to CMS.  Edit name, etc as desired. Leave checkbox checked for edit software resource… Select OK.

14)      On package tab, delete Install, install no IU and install for all users leaving just Install for all users with no UI/Repair/Uninstall options (not necessary).  For the “Install for all users with no UI” command line, edit it so it uses the MST file you created

a.       Ex  msiexec.exe /i "jre1.7.0_45.msi" TRANSFORMS="jre1.7.0_45.mst" /qn ALLUSERS=2

15)      Detection rule is auto created.  For Applicability, enter as needed (I leave both at default).  Click OK to save.

16)      Navigate to your CMS sharepoint \\cms\SoftwareLibrary and find the UUID of the folder uploaded (latest time /date stamp).  This is the same UUID folder name that gets copied locally to workstation when rolling out.

17)      Create command script task to copy deployment files to right location.  My script also includes lines to delete javaUpdate registry file if it exists because some people had this from previous versions and the Java 7 45 installer wasn’t clearing it and leaving the update tab in the control panel app.    Here’s example script – replace 9f283b6e-34b5-4e23-a171-82d3axxxxxxx with the UUID from step 16.

xcopy "C:\Program Files\Altiris\Altiris Agent\Agents\SoftwareManagement\Software Delivery\{9f283b6e-34b5-4e23-a171-82d3axxxxxxx}\cache\deployment.config" C:\Windows\sun\java\deployment\ /y

xcopy "C:\Program Files\Altiris\Altiris Agent\Agents\SoftwareManagement\Software Delivery\{9f283b6e-34b5-4e23-a171-82d3axxxxxxx }\cache\deployment.properties" C:\Windows\sun\java\deployment\ /y

reg add "HKLM\Software\JavaSoft\Java Update\Test"
reg delete "HKLM\Software\JavaSoft\Java Update" /f

11)   If needed, create vbscript to remove all previous versions of Java if needed.  I got my script from “serverkudsk” comment in this thread .  I changed the line strCurrentVersion to be Java(TM) Update 45, this script removes all versions of java on machine below 1.7.45. 

http://www.itninja.com/question/silent-uninstall-java-all-versions
 

12)    Create Managed software delivery Policy with 2 scripts and add software task.  I also add a task to delete software cache (this regenerates the software listed in inventory, there was a bug in 7.1 where old software doesn’t get removed unless you clear cache), and then run a software inventory scan.  Set applied to and schedule as necessary for your org.

This is what my policy looks like

3.png

Note: To create a filter to see who has your app installed, go to Software in CMS, software releases, find the package you created and right click and select actions, create installed software filter. 

 

Reference:  

Packaging Java (ITNinja) http://www.itninja.com/blog/view/java-7-update-25-best-way-to-deploy-with-customized-settings

http://www.itninja.com/software/oracle/java-2/7-552

Deployment Configuration File and Properties (Oracle) http://docs.oracle.com/javase/7/docs/technotes/guides/deployment/deployment-guide/properties.html

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

Jan 22, 2014 11:30 AM

Posted a new article summarizing the process I went through for updating to Java 51 for anyone interested. Tried to correct some mistakes and make it as simple as possible for next time. Thanks for all the replies here - they were helpful.

https://www-secure.symantec.com/connect/articles/updating-java-through-managed-software-delivery-policy-updated-article

Jan 15, 2014 09:58 AM

If they go to certain Java resources, our users are getting attached update message.  

I see in Java 7 release notes - "For businesses that manage the update process centrally, a new deployment property can be used to disable the Java version is out of date warning." 

I obviously missed some keys in my deployment file... I would think this message is different than the expiration controlled by "deployment.expiration.check.enabled" or is that the key I'm looking for (that I already knew I missed)?

http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/properties.html

Thanks for any info.  I want to try to get the 51 installer right!

Jan 14, 2014 04:32 PM

7u51 is out for those interested.

One of my users claims to be getting expiration message, but I haven't been able to reproduce.. yet

http://www.oracle.com/technetwork/java/javase/downloads/index.html

Dec 31, 2013 12:11 PM

Greg,

Thanks for the quick reply.  I tried the change date/time trick and confirmed I'm prompted after expiration date (February 14th, I think you have typo above saying January).  Good to know.

Wish I had known about these 2 keys when I rolled out 7u45.  

deployment.expiration.check.enabled=false

deployment.expiration.decision.suppression=TRUE
 
 
Will be putting that in my new copy of the file that will get dropped with the new installer out in January.
 
Thanks again!

Dec 31, 2013 11:53 AM

It happens the day after the expiration date.  I set my clock forward on the PC to test.

Jan 14th, no popup.  Jan 15th, popup.

 

Also, look in AppData\LocalLow\Sun\Java\Deployment\deployment.properties

You can confirm the answers to the prompt inside the file.  In this case I chose LATER.

ALSO, if you want to keep testing, I recommend deleting the entire deployment.properties file under that path above.  I've tried deleted just the lines but get mixed results with the "modified.timestamp" line getting created at different moments when opening, closing, refreshing browser windows.  If I delete the file I'm guaranteed to get the popup launching anything java.

deployment.modified.timestamp=1392482600238
deployment.expiration.decision.timestamp.10.45.2=1392482599
deployment.version=7.21
deployment.expiration.decision.10.45.2=later
deployment.expiration.decision.suppression.10.45.2=false

 

 

Finally, remember that this popup can finally be supressed and you'll want to test that dropping this file works :).  I'm lucky in that I don't need to APPEND these 4 lines so overwriting anything that is there is safe enough for me to do.

SCRIPT

copy deployment.properties %windir%\sun\java\deployment /y

CONTENTS of deployment.properties

deployment.expiration.check.enabled=false
deployment.expiration.decision.suppression=TRUE
deployment.javaws.autodownload=NEVER
deployment.javaws.autodownload.locked
 

Dec 31, 2013 10:29 AM

Looks like new version of Java is scheduled for Jan 14th for anyone not already aware.  It will expire 7u45 on Feb 14th.

I haven't been through a Java 7 update/expiration - can anyone give me a hint of when (if) my users will start seeing prompts, will it be as soon as Jan 14th?

http://java.com/en/download/faq/release_changes.xml

http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html

 

Thanks! 

Nov 19, 2013 12:17 PM

I have not seen a single reboot from this. We have it applied to 10600+ machines.

 

Nov 18, 2013 12:46 PM

@wogdog - have you seen any strangeness with reboots when upgrading version 7 that way? Thanks!

Nov 18, 2013 12:06 PM

We currently have a 'Java - remove old' policy in place, that tests for old versions of java installed by checking for their MSI code, and if found, removes them.

We then have another policy that just installs whatever the current version is. We rotate the current version in to this policy, and whatever version is being replaces into the 'Java - remove old' policy.

Both of these being done with CMS.

Regarding step 14, if the software is not already in the 'Newly Discovered Software', we install it on a test machine, let CMS inventory it (or force an inventory on this machine), then associate an installer with that software title. This way we are assured we are using the correct version installer for the inventoried software.

The bane of our existence, besides frequent Java updates, are laptops. We are a k12 institution, and have many laptops that are used only for testing, about twice a year. When they arent being used for testing, they are shoved in a closet somewhere not powered on or plugged in. Updates for anything are dificult on them...

Nov 17, 2013 07:06 PM

A practice I encourage is to try and shut down PCs (desktops, not laptops) nightly (with exceptions). Then you could wake them up later to install patches and software.

But make sure you don't just use a "Power off" Task, if your system gets busy or has problems it might queue the tasks up and shut everything down during the day. Just run a script that will check the time forst and only shutdown if it's within a certain window.

Nov 15, 2013 03:04 PM

Andy - Thanks for sharing.  Our users almost never logout (logged in or shut down).  I'll have to try to play around and see if I can find anything that works with the next java update.  

Nov 14, 2013 10:31 PM

If you can get away with running the updates out of hours (maybe using Wake-On-LAN) I've found for other things that using the "Reboot after" Advanced option in Managed Software Delivery Policies works well - I always combine it with a Run only when no user is logged on.

Nov 13, 2013 12:25 PM

@burndtjammer - Thanks, I appreciate the feedback.  95% of my users were java 6 so all is going ok so far.

Any tips for using CMS to upgrade users that have version 7?  I guess I'll run into that next few weeks whenever the next version is released.  This time I can do a more proper uninstall versus script - but concerned about the lack of reboot.  

I was thinking if I took some of Andykn101's tips and made those java files part of their own policy, maybe I could better handle Java updates via PM (with manually edited command line), though I suspect the reboot issue would still be there as well.

Nov 13, 2013 12:19 PM

Excellent write up.  You've pulled everything together that was discussed here https://www-secure.symantec.com/connect/forums/how-everyone-addressing-forced-java-dialog-java-update-needed-your-java-version-insecure#comment-9366211 with issues solved on other sites and put them in one definitive article.  This should be a lifesaver to admins everywhere encountering java issues, giving us more time to plan out our java installs.

I'd be careful with uninstalling previous versions of 7 and doing this install without a reboot in between. It doesnt like that very much. 

Nov 05, 2013 02:36 PM

Properties in Capitals being able to be passed as Windows Installer Properties is a function of the Windows Installer standards. 

These are the command line options for all versions of msiexec:

http://msdn.microsoft.com/en-us/library/aa367988(v=vs.85).aspx

http://technet.microsoft.com/en-us/library/cc759262(v=ws.10).aspx

And these are supported from Windows Installer 3.0 and later:

http://msdn.microsoft.com/en-us/library/aa372024(v=vs.85).aspx

If the individual properties aren't documented by the vendor, Oracle in this case, you could always go through the Windows Installer (msi) package to try and work out what effect they have.

I think that some of those properties may be a bit obsolete by now, I just use them anyway whilst they're still in the Windows Installer (msi) package.

Nov 05, 2013 10:48 AM

If you are looking for Wise/Admin Studio training, Raynet has good modules at reasonable prices.

Nov 05, 2013 10:22 AM

Thanks. I ventured into the Wise forum once (trying to learn how to package quicktime) and didn't really get much help other than a link to check out ITninja (was appdeploy back then).  Maybe I wasn't persistent enough but I almost felt like it wasn't a place for newbies to learn.  I think it'd be nice if the Symantec forums had some support for people new to repackaging beyond shooting them over to the kace related site.

Nov 05, 2013 10:09 AM

Sally5432,

Packaging is an honourable passtime and a bit of an art, I loved it myself as a customer and if you need support here, there are some really talented trusted advisors hanging around the Wise Forums who also post on ITNinja. A lot of the things you need to know will be on vendors sites, as for transforms and properties, that is Microsoft Installer technology that third parties do their best to break any rules for!

Nov 05, 2013 09:22 AM

Hi Andy,

Thanks for the feedback!  Part of my reasoning for posting this was to learn from others since I'm new to this, so I really appreciate it.

"Step 7: All the properties you put in the transform, being Capitalised, can be passed directly to the Windows Installer on the command line except the restart suppress which has it's own Windows Installer parameter anyway:"

Is there some documentation that a user would know this?  I found the link below but didn't see all of the options.  For all I know, the options in the transform don't do anything anymore either.  I have a hard time trying to figure out what's been phased out/supported with the new installers.

http://docs.oracle.com/javase/7/docs/webnotes/install/windows/jre-installer-options.html#running

Thanks again

Nov 05, 2013 05:19 AM

Really useful piece of work, thanks. A few comments:

Step 1: To make sure your Java downloads don't have any adware use:

http://www.oracle.com/technetwork/java/javase/downloads/index.html

Step 7: All the properties you put in the transform, being Capitalised, can be passed directly to the Windows Installer on the command line except the restart suppress which has it's own Windows Installer parameter anyway:

msiexec /i "jre1.7.0_45.msi" AUTOUPDATECHECK=0 IEEXPLORER=1 JAVAUPDATE=0 JU=0 MOZILLA=1 /norestart

Step 9: I usually package the deployment.config and deployment.properties files seperately as one Software Update to the main Java Software Release with their own detection rule, that way, any manual or other install of Java gets updated. Then I can add them to the Policy and have a recurring schedule on the Policy to continually (I prefer daily) check for compliance. And that way the xcopy commands don't need the full path to the source files.

Step 10: I only discovered this recently myself, but Symantec best practice is to create the Software Product first and import the Package into that:

http://www.symantec.com/docs/TECH212106

Step 14: I always put /l*v "%temp%\msiname.log" at the end of Windows Installer (msi) install command lines.

Step 17: Organisations that have upgraded their Altiris Agents from v6 may have the old Software Delivery path: "C:\Program Files\Altiris\Altiris Agent\Software Delivery\{9f283b6e-34b5-4e23-a171-82d3axxxxxxx}\cache\..."

second Step 11: I think the "official" method to uninstall old Java runtimes would be to go through your Inventoried Software Components and edit each Java runtime entry to add a:

  • default Uninstall command line
  • detection rule
  • "Supersedes" Association saying it's superseded by the latest JRE.

 

Nov 04, 2013 04:20 PM

This is a great article.  Thank you for sharing.

PMS does provide the option of using a custom install, so that may still be an alternate method for some customers.

Related Entries and Links

No Related Resource entered.