Remove all old versions of Java with PS AppDeploy Toolkit

Here's the script to uninstall all old versions of Java (while installing the newest version) using the Powershell AppDeploy Toolkit:

Remove-MSIApplications -Name "J2SE Runtime Environment 5.0"
Remove-MSIApplications -Name "Java(TM) 6 Update"
Remove-MSIApplications -Name "Java 7 Update"
Remove-MSIApplications -Name "Java 8 Update"

"Status information is currently unavailable for this deployment" - A workaround

Upon attempting to view Deployment Status of an Application, you may receive the "Status information is currently unavailable for this deployment" error when viewing the In Progress or Error tabs.  The Success tab may show normal deployment success statuses as expected.



The cause of this is unknown, but many online resources may tell you to put in a case with Microsoft.  Regardless, there is a workaround with SSRS Reports.  Under Monitoring / Reporting / Software Distribution - Application Monitoring, there is a report called Application Infrastructure Errors that will give you just what you need to fulfill that Deployment Status void.

Java management and you

Just uttering the word Java to any SCCM admin can bring forth repressed axe-murdering thoughts.  No worries - I hope to at least somewhat alleviate administering Java in an SCCM environment with this post.

Traditionally, Oracle/Sun has a history of leaving old Java versions installed even when updating to new versions.  This is where the headache comes in.  In a perfect world, Java would be actually updated with no previous versions left behind.  I suppose this can be a good thing for developers/testers, but for the majority rest of us, yeah, no.

First, you'll need the Java archive.  Thankfully Oracle keeps an online archive of every old Java version there is - JDK, JRE, 32-bit, 64-bit, you name it - all available with sign-up of a free Oracle account (and no, they don't spam your email after sign-up).

The link is here: http://www.oracle.com/technetwork/java/javase/archive-139210.html

To ease the pain of downloading every single version to add to SCCM for uninstallation, I'd highly suggest running a report of what Java versions are actually installed in your environment.  This can be best articulated with the Count of instances of specific software registered with Add or Remove Programs report in SCCM (under Monitoring / Reporting / Software - Companies and Products).



This report can give you a general idea of what old versions of Java to download.

The key to making this entire process speedy (at least for SCCM) is to obtain the MSI file inside the Java executable package.  This is fairly easy but requires a bit of legwork.  Once you download an old version of Java from the archive, run the executable, but don't install it.  On the first screen of the Java install, it has already extracted the files to a temp folder to install.  Simply leave the install window open and open Windows Explorer to navigate to C:\Users\<your username>\AppData\LocalLow  Depending on the Java version, you'll see a Sun or an Oracle folder.  Navigate to either folder, then Java, and you'll see the version of Java you just installed indicated in a folder (e.g. jre1.8.0_65_x64 or similar format).  Inside that folder is the MSI file you will need.  Copy this MSI file (and only the MSI file - if there are CAB files, they can be disregarded) to your SCCM application file share.  After this is copied (the Java installation can be cancelled, BTW), create a new application and point it to the MSI file you copied on your SCCM app share.  SCCM will automatically do what is needed to add the MSI - no modifications are needed after adding the MSI.

Once each Java MSI is added to SCCM, you can deploy an Uninstall deployment to the Collection of your choice.  Rinse and repeat the above paragraph for all other Java versions found in the report you ran.

If you find yourself adding a lot of versions of Java, you can optionally create a folder for all Java versions under your Applications list in the SCCM console (under Software Library / Application Management, right-click Applications and point to Folder - Create Folder)

Not all MSI's are different.

Today I learned that some - but not all - MSI's are created differently.

Take for instance Adobe Reader.  I had recently updated it to Reader DC 15.017.10050.  I created a new application and added the supersedence of the old one (15.016.20039) for uninstallation.  Normally I use Adobe Customization Wizard to enable options such as silent install and disabling cloud services.  After deploying I noticed in Software Center that the new one was consistently failing with error 0x87D00324.  This indicates an issue with the detection rule, in which case it was using the good ol' trustworthy MSI code.  

Problem is, the MSI codes for both 15.016.20039 and 15.017.10050 were exactly the same.  So I had to improvise a little.  Therefore I pointed 15.017... to a DisplayVersion registry key whose String value was 15.017.10050.  After updating this and refreshing the policy on the problematic clients, problem solved.

Cleanup before Capture script

DeploymentBunny made a great 'Cleanup before Capture' script that cleans up your reference image during a Build & Capture task sequence.  Just putting this here more for my own reference 😁