EXE Software Installation (System Wide-All Users)

What the EXE software installation Worklet does

This Automox Worklet™ is a generic EXE installer wrapper for Windows. The script takes four inputs hard-coded between the single quotes at the top of evaluation.ps1 and remediation.ps1: $displayName, $displayVersion, $fileName, and $arguments. The remediation phase runs Start-Process against the EXE attached to the Worklet under Files, passes the configured silent switch through -ArgumentList, and waits for the installer to exit before re-checking the registry.

The Worklet covers the long tail of Windows applications that ship only as an EXE installer. NSIS, Inno Setup, InstallShield, and MSI-wrapped EXE packages all accept some form of unattended switch, and the same script handles every variant because the silent argument string is just another parameter the policy sets per application.

Why deploy EXE software through a single Worklet

Drivers, conferencing clients, CAD tools, and vendor utilities frequently ship as an EXE only, so the deployment story for those packages tends to fall back to RDP sessions, ad-hoc scripts, or USB sticks. A generic wrapper that reads the silent flag, display name, and version from script variables lets one Worklet cover every EXE in the catalog instead of one Worklet per application.

Scheduling this Worklet against a Windows workstation or server group turns EXE deployment into a fleet-wide policy run. The same evaluation that flags missing endpoints also flags endpoints running an out-of-date DisplayVersion, so a single policy pass installs net-new endpoints and brings stale endpoints up to the configured version.

How the EXE installer wrapper works

1. Evaluation phase: The script opens Software\Microsoft\Windows\CurrentVersion\Uninstall through both the Registry64 and Registry32 views with [Microsoft.Win32.RegistryKey]::OpenBaseKey, then walks every subkey and matches DisplayName against the configured value with -like "$displayName*" (wildcard at the end). On a match, the script compares DisplayVersion against [Version]"$displayVersion" with -ge. If at least one match is at or above the configured version, evaluation writes "Installed" and exits 0. Otherwise it writes "Not Installed" and exits 1 to queue remediation.

2. Remediation phase: The script resolves the installer path by joining the Worklet runtime directory ($Script:MyInvocation.MyCommand.Path) with $fileName, then runs start-process "$fPath" -ArgumentList "$arguments" -wait so the policy holds until the installer process exits. After the installer returns, the script re-runs the same Registry64 and Registry32 sweep against the Uninstall hive. If a matching DisplayName at or above $displayVersion is now present, it writes "Successfully installed $displayName version $displayVersion" and exits 0. Otherwise it writes a failure message and exits 1.

EXE installer wrapper requirements

• Windows 7 or later, 32-bit or 64-bit, workstation or server. PowerShell ships with every supported build.

• The Automox agent service account, which already runs as SYSTEM and meets the system-wide install requirement.

• The vendor EXE attached to the Worklet under Files in the Automox console. The remediation script reads the file from the Worklet runtime directory using $Script:MyInvocation.MyCommand.Path, so the installer must be uploaded to the Worklet itself rather than fetched from a URL.

• $fileName set to the exact filename of the uploaded EXE (including extension), for example Everything-1.4.1.986.x64-Setup.exe.

• $arguments set to the vendor's documented silent install switch. Common patterns: /S for NSIS-based installers, /SILENT or /VERYSILENT for Inno Setup, /s /v"/qn /norestart" for InstallShield wrappers, /quiet /norestart for MSI-wrapped EXEs.

• $displayName set to the value as it appears in Programs and Features (Apps and Features on Windows 10 and later) or under the Uninstall registry key. The script appends a trailing wildcard, so a partial prefix such as Notepad++ matches Notepad++ (64-bit x64) without further configuration.

• $displayVersion set to the application's published version string. The script casts it to [Version] for comparison, so values must parse as N.N or N.N.N.N. Universal Windows Platform (UWP and MSIX) applications are out of scope, since they do not register under the Uninstall hive.

Expected state after EXE deployment

After a successful remediation, the application's DisplayName appears in Programs and Features (appwiz.cpl) and under HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall or its WOW6432Node mirror, with DisplayVersion at or above the configured value. The Worklet writes "Successfully installed $displayName version $displayVersion" to the Automox activity log and exits 0. On 64-bit endpoints installing a 32-bit application, the entry lands under WOW6432Node and the Registry32 view of the evaluation sweep picks it up on the next run.

To validate manually, run this on the endpoint and confirm a hit for the target application: Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*, HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Where-Object DisplayName -like '<app>*' | Select-Object DisplayName, DisplayVersion, InstallDate. If remediation reports failure, check the installer's own log (most vendors write to %TEMP% or %ProgramData%) and confirm that $displayName matches the actual DisplayName written by the installer once it finishes.

Subsequent policy runs return exit 0 without re-running the installer because evaluation finds the application already at or above the configured version. To force a redeployment after a vendor update, raise $displayVersion in the evaluation script and upload the new EXE plus the updated $fileName in the remediation script; the next evaluation flags every endpoint below the new floor and remediation pushes the update.