MSI Software Installation (System Wide-All Users)

What the MSI deployment wrapper does

This Automox Worklet™ deploys any standards-compliant MSI package to Windows endpoints in system-wide (per-machine) context. The Worklet ships as a generic wrapper around msiexec, so the same template covers 7-Zip, Slack, vendor agents, line-of-business apps, and any internal MSI a packaging team produces. You upload the MSI as the policy payload, set four variables, and the same script handles 32-bit and 64-bit Windows hosts without modification.

Detection reads the MSI itself. The Worklet opens the MSI database through the WindowsInstaller.Installer COM object and pulls the five mandatory MSI properties: ProductCode (the install GUID), ProductVersion, ProductName, Manufacturer, and ProductLanguage. Post-install verification keys off the ProductCode rather than DisplayName matching, so the Worklet survives vendor renames and locale differences in the registry.

The remediation call uses msiexec /i with /qn (no UI) and /norestart, joined with your $custArgs (for example, ALLUSERS=1 or INSTALLDIR="C:\Program Files\Vendor") and a verbose install log written to %WINDIR%\temp\<fileName>.log. The verification phase reads both the native and Wow6432Node uninstall hives, so deployments to 32-bit installers on 64-bit Windows are detected the same way as native 64-bit ones.

Why deploy MSI software through Automox

Most Windows enterprise applications still ship as MSI, and the install logic is nearly identical across every package: silent flags, custom properties, log to a known path, then verify against the registry uninstall key. Hand-rolling that wrapper per application produces dozens of near-duplicate scripts that drift over time. This Worklet replaces every one-off installer script in the catalog with a single, parameterized template that handles bitness, version comparison, and post-install verification consistently.

Deploying MSI packages through an Automox policy collapses the per-application install workflow into one evaluation cycle. The evaluation phase queries the Windows Installer registry for the target ProductCode and version; remediation runs msiexec only on endpoints that fail the check, so a fleet of 5,000 workstations might only see remediation fire on the few hundred that actually lack the package. The result is a deterministic, idempotent rollout: schedule the policy once, no per-host packaging session, no manual remediation queue, and no requirement that the user be on the corporate network when the install runs.

How the MSI deployment works

1. Evaluation phase: The Worklet detects whether the host is 64-bit and, if so, opens the 64-bit view of HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall using [Microsoft.Win32.RegistryKey]::OpenBaseKey with Registry64. It enumerates each uninstall subkey, matching DisplayName against the $appName wildcard. The Worklet then walks HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall via Get-ChildItem and Get-ItemProperty, which covers 32-bit Windows hosts natively and the native 64-bit uninstall hive on 64-bit Windows. For each match, [Version]$DisplayVersion is compared against [Version]$dispVer. If any install meets or exceeds the target, the endpoint exits 0 (compliant); otherwise it exits 1 and is flagged for remediation.

2. Remediation phase: The Worklet locates the uploaded MSI via Split-Path on $Script:MyInvocation.MyCommand.Path and joins it with $fileName. Test-Path validates the payload exists (a missing payload exits 2 with a clear error). The Get-MSIPropertyList function opens the MSI database through WindowsInstaller.Installer and reads ProductCode, ProductVersion, ProductName, Manufacturer, and ProductLanguage. The Worklet then builds the argument list as msiexec /i "<path>\<fileName>" /qn /norestart <custArgs> /l*v "%WINDIR%\temp\<fileName>.log", launches msiexec with Start-Process -Wait, and checks both Registry64 and Registry32 views of Uninstall\<ProductCode> for a DisplayVersion that meets or exceeds the MSI's ProductVersion. Success writes "Installation of <fileName> Successful" and exits 0; failure writes a pointer to the log path and exits 1603.

MSI deployment requirements

• Windows 7, Windows 8.1, Windows 10, Windows 11, or Windows Server 2012 R2 and later, 32-bit or 64-bit

• Upload the MSI as the Worklet payload (Policies > Worklets > the Worklet > Files); the script auto-resolves the payload path through Split-Path on $Script:MyInvocation.MyCommand.Path

• Set $fileName in the remediation script to the exact uploaded filename including the .msi extension (for example, slack-standalone-4.13.0.0.msi)

• Set $appName in the evaluation script to the DisplayName as it appears in Programs and Features (Win7/8.1) or Apps and Features (Win10/11); wildcard matching with -like is in effect, so partial names work

• Set $dispVer to the target DisplayVersion; the comparison uses the [Version] type, so values must parse as Major.Minor.Build.Revision

• Optional: set $custArgs in remediation for MSI public properties (for example, ALLUSERS=1, REBOOT=ReallySuppress, INSTALLDIR="C:\Program Files\Vendor") – the script appends /qn, /norestart, and the log argument automatically

• The Automox agent runs as SYSTEM, which already has the administrative privileges msiexec requires for per-machine installs; no extra credential plumbing needed

• Universal Windows Platform (UWP) and Microsoft Store packages are not supported by this Worklet – use a dedicated UWP deployment Worklet for those

Expected state after MSI deployment

After a successful remediation, the application is registered under HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\<ProductCode> (the native hive for 64-bit MSIs, Wow6432Node for 32-bit MSIs on 64-bit Windows). DisplayVersion matches or exceeds the ProductVersion read from the MSI, and the application appears in Apps and Features for all users. Subsequent policy runs short-circuit at the evaluation phase because $installed increments on the version match and the script exits 0.

If verification fails, the Worklet exits 1603 and writes "Encountered Errors. See logfile at %WINDIR%\temp\<fileName>.log" to the Automox activity output. Open the log with a text editor and search for "Return Value 3" to locate the MSI failure point; the line above typically names the missing prerequisite, locked file, or invalid property. Common causes of 1603 on a per-machine MSI install are a service holding a file lock on the target binary, a missing Microsoft Visual C++ runtime, or a custom action that fails when the user context is SYSTEM rather than an interactive admin. Re-run the policy after correcting the underlying condition; the Worklet re-evaluates and remediates in one pass.