Windows
View all Worklets
WindowsWindows

Windows - Software Lifecycle - Manage Third Party Override Options

Configure third-party software patching overrides to control behavior on Windows endpoints

Worklet Details

What the third-party patching override Worklet does

This Automox Worklet™ creates and manages a local override configuration file that customizes third-party software patching behavior on Windows endpoints. By default, Automox applies standard patching policies to all applications. This Worklet lets you override those defaults for specific software titles, giving you precise control over patch deployment.

The Worklet supports two key override options for each application. You can specify whether Automox should forcibly close the application before patching (the kill_if_running setting), and whether it should uninstall previous versions before applying the patch (the uninstall_before_patch setting).

The Worklet stores override configurations in a file at the Automox installation directory (ax_overrides). This file persists across patch cycles and applies automatically whenever those software titles are updated.

Why customize third-party patching behavior

Different applications have different patch requirements and behaviors. Some applications patch cleanly while running in the background, while others require explicit closure to avoid conflicts. Some benefit from clean uninstalls before patching, while others support in-place updates. Using a one-size-fits-all patching policy can lead to failed patches, extended downtime, or application instability.

By implementing application-specific overrides, you verify each software title patches using the optimal method for that application. This reduces failed patches, minimizes user disruption, and improves overall patch success rates across your environment. For applications that don't support Automox default behavior, overrides let you work around limitations and maintain patch compliance.

You can also use overrides to enforce security requirements. Some software titles require specific patching methods to maintain security compliance, and this Worklet maintains those methods are applied consistently across all endpoints.

How third-party patching override configuration works

  1. Evaluation phase: The Worklet reads the override parameters you specify (which software titles should use which override options). It generates a temporary override configuration file and compares it against any existing override file on the endpoint. If the files match, no action is needed. If they differ or if no override file exists, the Worklet signals that remediation is required.

  2. Remediation phase: The Worklet copies the new override configuration file from the temporary location to the permanent Automox directory (at C:\Program Files (x86)\Automox\ax_overrides or equivalent on 64-bit systems). The Automox patching engine then reads this file during subsequent patch operations and applies the specified override behavior to matching software titles.

Third-party patching override requirements

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

  • PowerShell 5.0 or later

  • Automox agent installed with administrator privileges

  • Correct cached package names for the software titles you want to override (available in Automox Product Documentation)

  • Knowledge of whether each application supports kill_if_running and uninstall_before_patch override options

Expected state after applying patching overrides

After the Worklet completes remediation, the override configuration file will be present at C:\Program Files (x86)\Automox\ax_overrides (or the equivalent 64-bit Program Files location). You can verify this change by checking the specific setting this Worklet modifies. The file contains one line per override, with each line specifying a software title, the override option (kill_if_running or uninstall_before_patch), and the desired behavior (True or False).

When the Automox patching engine encounters one of the specified software titles in the override file, it applies the configured behavior instead of the default behavior. For example, if you set kill_if_running=False for an application, Automox will not forcibly close that application before patching, even if the default behavior is to close it. You can verify the overrides are active by checking the Automox agent logs during subsequent patch operations or by reviewing the ax_overrides file directly on the endpoint.

How to validate manage third party override options changes

  1. Run this Worklet on a pilot Windows endpoint and review evaluation output for manage third party override options.

  2. Confirm Automox activity logs show successful completion and exit code 0.

  3. Verify endpoint state using checks aligned to evaluation script logic, such as Test-Path, Remove-Item, Select-Object.

  4. Validate remediation effects from script operations such as Test-Path, Write-Output, Copy-Item, then rerun evaluation for compliance.

View in app
evalutation image
remediation image

Consider Worklets your easy button

What's a Worklet?

A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklet automation scripts perform configuration, remediation, and the installation or removal of applications and settings across Windows, macOS, and Linux.

do more with worklets