Uninstall Specific App by Name

What the display-name uninstaller does

This Automox Worklet™ uninstalls Windows applications by DisplayName. The Worklet enumerates the 64-bit HKLM Uninstall hive via [Microsoft.Win32.RegistryKey]::OpenBaseKey with RegistryView::Registry64, the 32-bit Uninstall hive at HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall, and the per-user Uninstall hive under HKU:\<sid>\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall for every loaded profile. It matches each entry's DisplayName against -like "*$appName*" and excludes any entry whose SystemComponent value is set.

The Worklet takes two parameters: $appName (the DisplayName substring) and $uninstallSwitchEXE (a fallback set of silent switches for EXE-based installers). The script wraps $appName with wildcards internally, so the input itself should be a partial product name without asterisks. A value like 'winrar' catches every WinRAR build the vendor ships across the estate; a more specific value like 'Adobe Acrobat Reader' targets only that variant and leaves Pro DC installs in place.

For each matched entry, the Worklet reads UninstallString. If the string contains 'msiexec', the script invokes MSIExec.exe with /x <ProductCode> /qn /norestart /l*v $env:windir\temp\UninstallApp-64.log (or -32.log for the 32-bit hive, -Usr.log for per-user). For EXE installers, the script splits UninstallString on the '.' character to separate the executable path from its built-in silent switches; if no switches are recoverable, it falls back to $uninstallSwitchEXE. Per-user installations are uninstalled via a transient scheduled task that runs in the Users principal and is unregistered as soon as the State returns to Ready.

Why uninstall Windows applications by display name

The hardest part of removing a Windows application at scale is rarely the uninstall itself; it is figuring out the right command line. MSI installers expose a clean syntax (msiexec /x {GUID} /qn). EXE installers ship vendor-specific quiet switches (/S, /silent, /uninstall, /quiet). Per-user installers register their UninstallString under HKU and refuse to run cleanly from a SYSTEM context. Authoring a per-product script for every application in the estate is open-ended operations work.

This Worklet is the generic Windows uninstall path. Set $appName to a DisplayName substring and the script reads the UninstallString from the Uninstall hive to recover the per-product silent switches at runtime. Pair the Worklet with a discovery query that lists which DisplayName patterns are installed across the estate, then schedule the uninstall against the names you want gone. The same Worklet handles MSI, EXE, and HKU per-user installers from a single policy.

How the display-name uninstall works

1. Evaluation phase: The Worklet opens the 64-bit HKLM Uninstall hive via the .NET RegistryKey API (Registry64 view), the 32-bit hive at HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall, and every HKU:\<sid>\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall path under a temporary HKU PSDrive. It counts subkeys whose DisplayName matches -like "*$appName*" and whose SystemComponent value is not set. If the count is greater than zero, the script writes the count to the Activity Log and exits 1 to flag for remediation. With no matches it exits 0.

2. Remediation phase: The remediation script re-walks the same three hives. For entries whose UninstallString contains 'msiexec', it runs MSIExec.exe /x <PSChildName> /qn /norestart with a verbose log under $env:windir\temp\. For EXE entries, it strips quotes from UninstallString, splits on '.' to separate path from switches, and falls back to $uninstallSwitchEXE when no switches are present. Per-user EXE uninstalls are dispatched through a Schedule.Service scheduled task registered as 'Uninstall User App' under the Users principal, polled for State -eq 'Ready', then unregistered. Failures exit 1603 (uninstall failed) or 87 (no silent switches available); successful runs exit 0.

Display-name uninstall requirements

• Windows 7 or later, including Windows 10, Windows 11, and Windows Server 2016+, with PowerShell 2.0 or later available to the Automox agent

• SYSTEM context for the Automox agent so the script can read HKLM uninstall hives, mount HKU, and register scheduled tasks for per-user uninstalls (the default agent context satisfies this)

• $appName set to a DisplayName substring unique enough to avoid collateral matches; do not use wildcards in the value because the script wraps the input with * internally

• $uninstallSwitchEXE set for EXE installers that do not store recoverable switches in their UninstallString; without this fallback the script exits 87 and logs the missing-switches error

• A pilot run against a test group to confirm the $appName substring matches the intended software and nothing else, since unintended matches will be uninstalled along with the target

Expected Windows state after the uninstall

After a successful remediation, no entry whose DisplayName matches the configured substring remains under the HKLM 64-bit, HKLM 32-bit, or HKU Uninstall hives, and the application no longer appears in Apps and Features. Start menu shortcuts and Program Files directories are removed by the vendor uninstaller as part of its standard flow. The next evaluation pass exits 0 with 'Installed software was not found - Remediation not needed'.

Validate by inspecting $env:windir\temp\UninstallApp-64.log, UninstallApp-32.log, or UninstallApp-Usr.log on the endpoint for MSI verbose output, and by re-running Get-ChildItem on the three Uninstall hives with the same DisplayName filter. For audit evidence, capture the Activity Log entry that records the number of installations found and the per-endpoint exit code. Entries that exit 87 indicate an EXE installer with no recoverable switches – set $uninstallSwitchEXE to the vendor's documented silent syntax and re-run.