Windows - Software Lifecycle - Manage Third Party Override Options

What the third-party patching override Worklet does

This Automox Worklet™ writes a local ax_overrides configuration file on Windows endpoints that changes how the Automox agent handles third-party patching for the applications you name. By default, Automox patching follows the cached behavior defined for each software title (for example, force-closing an application that will not patch while running, or uninstalling a previous version before installing the new one). This Worklet replaces those defaults on a per-application basis using rules you set in evaluation.ps1.

Each rule attaches to a cached package name and sets one of two options: kill_if_running (whether the agent should force-close the process before patching) and uninstall_before_patch (whether the agent should uninstall the prior version first). The override applies only to the named application; every other software title continues to follow the Automox default.

The Worklet writes ax_overrides into the Automox program directory ($env:ProgramFiles\Automox on 32-bit hosts, ${env:ProgramFiles(x86)}\Automox on 64-bit) and rewrites the file whenever the rule set in evaluation.ps1 changes. The patching engine reads ax_overrides during the next patch cycle and applies the new behavior to matching titles.

Why enforce third-party patching overrides

Default third-party patching behavior in Automox is tuned for the typical case, but specific applications break that case. A line-of-business application that runs continuously may need kill_if_running set to False so a scheduled patch does not interrupt the user. A vendor installer that handles its own upgrades may need uninstall_before_patch set to False so Automox does not remove the prior version and trigger a license re-check. Without the override file, the patch either fails, restarts a critical process, or leaves the application in a partially upgraded state.

Patching exceptions accumulate in ways nobody plans for. A single Tier-3 ticket whitelists one ProductCode for one team for two days, six months later that exception is still in place across forty endpoints, and the change has fallen out of every dashboard. The Worklet keeps the override file under source control in evaluation.ps1, applies it on every policy run, and surfaces deviations as evaluation failures in the Automox activity log, so a missing or stale ax_overrides line is caught before it becomes a stalled patch window or a Help Desk escalation.

How third-party patching override enforcement works

1. Evaluation phase: The Worklet reads the four arrays defined at the top of evaluation.ps1 ($killIfRunningTRUE, $killIfRunningFALSE, $uninstallToPatchTRUE, $uninstallToPatchFALSE), deduplicates each list with Select-Object -Unique, and writes the result to $axDir\ax_overridesNew (one rule per line, format ProductName.kill_if_running=True or ProductName.uninstall_before_patch=False). It then compares Get-FileHash on ax_overridesNew against the existing ax_overrides. Matching hashes exit 0 (compliant). A mismatched file exits 123, a missing file exits 124, and a failed write exits 122 – each triggers remediation.

2. Remediation phase: The Worklet uses Copy-Item to move ax_overridesNew over the existing ax_overrides, then Remove-Item on the staging file. The next Automox patch cycle reads the refreshed ax_overrides and applies the new kill_if_running and uninstall_before_patch values to the named cached package names. Applications not listed in any array continue to follow Automox default behavior.

Third-party patching override requirements

• Windows 10 or later, or Windows Server 2019 or later

• PowerShell 5.0 or later running as SYSTEM (the default Automox agent context already meets this)

• Automox agent installed; the Worklet writes into the agent's own program directory

• Cached Package Name for each application you want to override – pull these from the Automox Naming Scheme for Third-Party Software Packages documentation, not from the installed application name in the Programs and Features control panel

• Knowledge of which override the application actually honors: kill_if_running applies to titles flagged 'App will NOT patch when running', and uninstall_before_patch applies to titles where Automox uninstalls before patching by default

• To revert an override, remove the corresponding ProductName from the array in evaluation.ps1 and rerun the policy; the next remediation rewrites ax_overrides without that line and the agent returns to default behavior

Expected state after override enforcement

After remediation, ax_overrides at the Automox program directory matches the contents written by evaluation.ps1. Each line follows the pattern ProductName.kill_if_running=True, ProductName.kill_if_running=False, ProductName.uninstall_before_patch=True, or ProductName.uninstall_before_patch=False. Subsequent evaluations exit 0 because Get-FileHash on the existing and freshly generated file return the same hash.

Validate by opening ax_overrides on a remediated endpoint and confirming the expected rules are present, then watching the Automox activity log during the next patch cycle for the named application. A successful override appears as the patch installing without force-closing the application (for kill_if_running=False) or without an uninstall step preceding the install (for uninstall_before_patch=False). If an override is ignored, the agent log will note that the named ProductName was not detected on the endpoint – confirm the cached package name matches the Automox documentation rather than the installed product display name.