Install and/Or Uninstall Java

What the Java replacement Worklet does

This Automox Worklet™ manages the Oracle Java lifecycle on Windows endpoints. The Worklet supports three modes: install a target Java SE build, install the target and uninstall every other Java version on the endpoint first, or run uninstall-only with no target build. Each mode runs from the same evaluation and remediation scripts, gated by three policy parameters.

The Worklet enumerates both Windows uninstall registry hives so 32-bit installs on 64-bit Windows are not missed. It opens HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall through the 64-bit registry view for native installs and reads HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall with Get-ChildItem for the WOW64 view. Any DisplayName matching Java* is counted as a Java installation, with the literal string "Java Auto Updater" excluded so the auto-updater entry is never treated as a JRE install.

Java SE Development Kit installs are detected as a group by matching DisplayName against *SE Development Kit*. If any JDK is present on the endpoint, the Worklet skips the uninstall block entirely to protect developer environments, unless $jdkOverride is set to $true. The override applies to the endpoint as a whole, not per-entry: when it is on, every Java row (including JDK) is uninstalled.

Three parameters drive behavior. $javaToInstall holds the exact Programs and Features DisplayName of the target build (set in evaluation), for example "Java 8 Update 321 (64-bit)". $javaInstallFile points to the installer filename attached to the Worklet (set in remediation), for example "jre-8u321-windows-x64.exe". $uninstallOtherJava and $jdkOverride are Boolean toggles that must be set to the same value in both evaluation.ps1 and remediation.ps1 so the compliance check and the action agree.

Why retire legacy Java builds across the fleet

Old Java builds are one of the most reliable footholds left on a Windows fleet. Oracle Java 6, 7, and early 8 updates carry well-documented CVEs covering deserialization flaws, sandbox escapes, and TLS implementation gaps. Endpoints often accumulate three or four side-by-side Java installations over years of application installers, each one a separate attack surface and a separate version reported to vulnerability scanners.

A converged Java baseline is hard to reach because old JREs hide in vendor application directories, Citrix images, and back-office Windows Server boxes that nobody logged into last quarter. This Worklet enumerates the Windows uninstall registry on each endpoint, runs the stored UninstallString for every Java row, protects endpoints with a JDK present by default, and stages the replacement JRE so the next evaluation reports a single current version per endpoint.

How the Java replacement flow works

1. Evaluation phase: The script opens the 64-bit uninstall hive with [Microsoft.Win32.RegistryKey]::OpenBaseKey on LocalMachine / Registry64, then reads HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall with Get-ChildItem and Get-ItemProperty. It counts every DisplayName -like 'Java*' (excluding 'Java Auto Updater') into $javaInstallations and flags $jdkInstalled when any DisplayName matches '*SE Development Kit*'. When $javaToInstall is set, it also checks whether the target DisplayName is already present. The script exits 0 (compliant) only when the install count, target presence, and JDK rules all match the desired state for the chosen $uninstallOtherJava and $jdkOverride flags; otherwise it exits 1 to schedule remediation.

2. Remediation phase: When $uninstallOtherJava is $true and either no JDK is present or $jdkOverride is $true, the script collects the UninstallString value from every matching Java entry in both registry views, then calls Start-Process MSIExec.exe with /X {<ProductGuid>} /qn /norestart for each one (the GUID is parsed from the stored UninstallString). When $javaInstallFile is set, it copies the installer to $env:windir\Temp, runs it with the Oracle silent flags /s REBOOT=0 SPONSORS=0, and removes the staged copy when the process returns. Each uninstall and the final install result are written to stdout for the Automox Activity Log.

Java replacement requirements

• Windows 8 or later, including Windows 10, Windows 11, and Windows Server 2012 R2 through 2022; PowerShell 5.1 in the SYSTEM context (the Automox agent default)

• Verified against Oracle Java SE 6, 7, and 8 uninstall strings; the Worklet was lightly tested with JDK installs and is designed primarily for JRE deployment

• Administrator-equivalent rights to read the uninstall hive and invoke MSIExec.exe (the agent default meets this)

• Upload the Oracle Java installer (for example jre-8u321-windows-x64.exe) to the Worklet attachments. The remediation passes Oracle's /s REBOOT=0 SPONSORS=0 silent flags, so the attached file must be the Oracle .exe installer that accepts those flags

• Set $javaToInstall in evaluation.ps1 to the exact Programs and Features DisplayName for the target build, including the (64-bit) or (32-bit) suffix that the installer writes; set $javaInstallFile in remediation.ps1 to the uploaded filename

• Set $uninstallOtherJava and $jdkOverride to the same Boolean values in both evaluation.ps1 and remediation.ps1 so the compliance check and the action agree. To remove all Java with no replacement, set $javaToInstall = "", $javaInstallFile = "", and $uninstallOtherJava = $true

• Plan licensing: Oracle JRE 8 Update 211 and later require an Oracle subscription for commercial use. OpenJDK or Amazon Corretto are no-cost alternatives, but their silent-install flags differ from Oracle's, so the Worklet's hard-coded /s REBOOT=0 SPONSORS=0 arguments will not work without script changes

Expected state after Java remediation

When install-with-uninstall mode runs successfully, every prior Java entry on the endpoint is removed and the target $javaToInstall build is reinstalled, leaving exactly one JRE row in Programs and Features. Note that the remediation always uninstalls every matching Java row first when $uninstallOtherJava is $true (the target is not preserved through the cleanup), then installs the target fresh from the attached file. A repeat evaluation reports the endpoint compliant. Vulnerability scanners that key on Java DisplayName, such as Tenable Nessus or Qualys, drop the older CVE findings on their next scan.

When the Worklet runs in uninstall-only mode (with $javaToInstall and $javaInstallFile both empty), every Java entry is removed unless a JDK is present and $jdkOverride is $false, in which case nothing is uninstalled. Validate by running Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*', 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' | Where-Object DisplayName -like 'Java*' and confirming the result is empty. Any failed uninstall surfaces in the Activity Log because each MSIExec call writes its DisplayName to stdout before running.