Uninstall All Apps Under Specific Version

What the version-targeted uninstaller does

This Automox Worklet™ removes every instance of a named application that falls below a minimum version threshold on a Windows endpoint. You supply two values – the application name as it appears in Programs and Features and the lowest version you want to keep – and the Worklet handles the rest. Anything at or above the threshold is left alone.

The Worklet inspects three uninstall registry locations on each endpoint. It opens the 64-bit hive at HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall through the Registry64 view, then the 32-bit hive at the same path under the Wow6432Node redirect, then every per-user HKEY_USERS profile mounted as a temporary HKU PSDrive. Each DisplayName is matched with a wildcard against your $appName, and each DisplayVersion is parsed as a [version] object and compared against your $appVersion. SystemComponent entries are skipped so the Worklet never touches Windows-managed bundles.

Remediation branches on installer type. If the UninstallString starts with msiexec, the Worklet calls msiexec.exe /x <ProductCode> /qn /norestart with a verbose log written to %windir%\temp\UninstallApp-64.log, UninstallApp-32.log, or UninstallApp-Usr.log depending on the hive. If the UninstallString points at a vendor EXE, the Worklet parses the embedded switches off the registry value, falls back to the $uninstallSwitchEXE parameter when no switches are present, and runs the uninstaller with Start-Process -Wait. Per-user installations are handed off to a scheduled task that runs in the user context and self-deletes when it reports Ready.

Why retire outdated application versions

Stale application versions are the single largest source of background CVE exposure in a typical Windows fleet. Python 3.7 builds keep an OpenSSL chain that is years out of date. Adobe Reader installations stop receiving DC channel updates once the major version goes EOL. A user-context Slack install bypasses Programs and Features entirely and rides whatever version the user first downloaded. The vulnerability scanner flags every one of them, and the patch policy that targets the current release does not see them.

Stale application builds on Windows endpoints accumulate fastest where end users install per-user MSI or EXE packages outside of standard inventory tools. Point this Worklet at the application by name, set the version floor to the build your patch policy installs, and every endpoint that drifts below the floor cleans itself up on the next evaluation. The version-targeted DisplayVersion match catches the per-user installs under HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall that an MSI-only inventory tool will not surface.

How version-targeted uninstalls work

1. Evaluation phase: The Worklet walks the 64-bit uninstall hive through OpenBaseKey with Registry64, then the 32-bit hive via Get-ChildItem on HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall, then every loaded HKEY_USERS profile. For each subkey whose DisplayName matches *$appName* and whose SystemComponent flag is unset, the script casts DisplayVersion to [version] and compares it to [version]$appVersion. Each installation below the threshold increments the $remediate counter. A non-zero counter exits 1 and flags the endpoint for remediation; otherwise the script writes Compliant and exits 0.

2. Remediation phase: For each non-compliant installation the script reads UninstallString. If the string contains msiexec, the Worklet runs msiexec.exe /x <ProductCode> /qn /norestart /l*v <log path> using the registry subkey name as the ProductCode. If it points at an EXE, the Worklet splits the UninstallString on the .exe boundary, strips quotes, and recovers the original silent switches; if no switches are embedded it substitutes $uninstallSwitchEXE. Per-user installations register a one-shot scheduled task that runs as Users, polls for state Ready, and is unregistered when complete. Exit 1603 signals an uninstall failure, exit 87 signals a missing $uninstallSwitchEXE for an EXE with no embedded switches, and exit 0 signals every target was removed.

Version-targeted uninstall requirements

• Windows 7 or later workstation or server with PowerShell 2.0 or later

• Local administrator privileges (the Automox agent context already meets this)

• $appName: the DisplayName as it appears in Programs and Features. Partial matches are allowed because the script applies wildcards internally; pick a value distinct enough to avoid collateral uninstalls (use 'Adobe Acrobat Reader' instead of 'Adobe')

• $appVersion: the minimum version to keep, in dotted-numeric form parseable by [version] (3.9.5, 23.003.20244, 4.33.73). Anything strictly less than this version is removed

• $uninstallSwitchEXE: optional fallback silent switches for EXE installers whose UninstallString contains no usable switches (for example /uninstall /quiet or /S). Leave blank for pure-MSI applications

• Network reachability to %windir%\temp on the endpoint for MSI verbose logs (UninstallApp-64.log, UninstallApp-32.log, UninstallApp-Usr.log)

• Test the $appName / $appVersion / $uninstallSwitchEXE combination on a pilot endpoint before scheduling against a production group, particularly for vendor EXEs whose silent switches differ across releases

Expected state after the uninstall completes

Only installations at or above $appVersion remain. The 64-bit hive, the 32-bit Wow6432Node hive, and every HKEY_USERS profile have been swept, so user-context installs that survived a Programs and Features sweep are gone too. MSI uninstalls leave a verbose log under %windir%\temp\UninstallApp-<scope>.log that captures the msiexec return code; EXE uninstalls inherit whatever logging the vendor uninstaller provides. The Worklet writes the count of successful removals to the Automox activity log and exits 0.

Validate by running Get-Package -Name '<AppName>' -ErrorAction SilentlyContinue or by re-querying the uninstall registry directly: Get-ChildItem HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall, HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall | Get-ItemProperty | Where-Object DisplayName -like '*AppName*' | Select-Object DisplayName, DisplayVersion. Re-run the Worklet to confirm: a compliant endpoint exits 0 with the message Compliant and does not invoke remediation. For audit evidence, capture the activity log entry for the policy run and pair it with the %windir%\temp\UninstallApp-*.log files for any MSI removals. The endpoint stays compliant until a user or installer drops a sub-threshold build back on disk, at which point the next evaluation flags it and the Worklet cleans it again.