macOS - Software Lifecycle - JAMF List Software Plans

What the Jamf software update plan auditor does

This Automox Worklet™ queries the Jamf Pro API from a macOS endpoint to retrieve the managed software update plans associated with the devices behind a configured Jamf tag. The Worklet does not change any setting on the endpoint. It returns inventory only: the set of plans Jamf currently has on record for the tagged devices, written to the Automox Activity Log.

The Worklet calls Jamf through the Automox Worklet Development Kit (WDK). The wrapped command wdk mdm jamf plans --tag "${PATCH_TAG}" authenticates against the Jamf Pro tenant with the API client credentials stored as organization secrets and asks the WDK to return the plans scoped to the configured tag. Evaluation uses -o json so the script can count plans; remediation re-runs the same call and prints the human-readable output.

Plan output is captured by the Automox Activity Log on every run. The data is consumable downstream – ticketing, compliance dashboards, or a sibling Worklet that reconciles Jamf update plans against the Automox patch report for the same Mac.

Why audit Jamf software update plans from the endpoint

Jamf Pro is the system of record for MDM-managed software update plans on a Mac fleet, but the Jamf console does not natively reconcile its plan state against the Apple softwareupdate --list output on each laptop or against the patch posture Automox already reports. When a plan stalls in pending or fails on a single endpoint, the gap is invisible until someone opens the Jamf console, filters to the right scope, and reads it row by row.

Auditing Jamf software update plans usually means logging into a second console, exporting CSVs, and reconciling them against patch state by hand. This Worklet pulls Jamf API data from inside the Automox policy run and returns the result through the Automox Activity Log, so the audit travels with the patch report instead of living in a separate spreadsheet.

How Jamf update plan retrieval works

1. Evaluation phase: evaluation.sh invokes the WDK with wdk mdm jamf plans --tag "${PATCH_TAG}" -o json. The WDK reads AX_JAMF_CLIENT_ID, AX_JAMF_CLIENT_SECRET, and AX_JAMF_BASE_URL from the policy inputs, authenticates against the Jamf tenant, and returns the plans scoped to the configured tag. The script counts the returned plans with ottoq. Zero plans returns exit 0 (compliant, nothing to remediate). One or more plans returns exit 1 so Automox schedules remediation, which is where the listing is emitted. If the WDK call itself fails, the evaluation prints the error to stderr and exits 0.

2. Remediation phase: remediation.sh re-runs wdk mdm jamf plans --tag "${PATCH_TAG}" without the -o json flag and captures the output. An EXIT trap writes the captured payload to stdout when the WDK call succeeds, or to stderr when it fails, and exits with the WDK exit code. On success, the Automox Activity Log captures the human-readable plan listing for the policy run. On failure (expired token, network error, Jamf 5xx), the error message surfaces in the activity log rather than being silently swallowed.

Jamf plan audit requirements

• macOS endpoint (Workstation or Server) under Automox management with the Automox WDK installed at /usr/local/bin/wdk and Jamf MDM enrollment in place

• Jamf Pro tenant exposing the managed software updates API, with an API client stored as organization secrets: AX_JAMF_CLIENT_ID, AX_JAMF_CLIENT_SECRET, and AX_JAMF_BASE_URL (for example https://yourorg.jamfcloud.com)

• Jamf API client granted the following roles: Create Managed Software Updates, Read Computers, Read Managed Software Updates, and Send Computer Remote Command to Download and Install OS X Update

• Automox API credentials stored as organization secrets: AX_AUTOMOX_API_KEY and AX_AUTOMOX_ORG_UUID, added as inputs to the policy with names matching the secrets exactly

• PATCH_TAG variable set in the script (defaults to JAMF) to match the tag assigned to the in-scope devices in Jamf

• Policy scoped to a single endpoint – scoping to multiple endpoints may result in unintended behavior, per the script header

Expected Jamf plan output and validation

After a remediation run, the Automox Activity Log contains the Jamf managed software update plans associated with the devices behind the configured PATCH_TAG. An auditor can read the Automox run output and see which devices have plans on record without opening the Jamf Pro console, then cross-check that list against the Automox patch report for the same endpoints to surface plans stuck in pending while the endpoint is online and patchable.

Validate the run against the endpoint itself by comparing the plan target version to /usr/sbin/softwareupdate --list on the local Mac. If a plan is stuck or failing, run /usr/bin/log show --predicate 'subsystem == "com.apple.MobileSoftwareUpdate"' --last 1h on the Mac to capture the DDM error before reissuing the plan in Jamf. An evaluation exit of 0 with no remediation run means the configured tag has no plans scoped to it. A stderr message in the activity log means the Jamf API call itself failed – check the API client credentials, the AX_JAMF_BASE_URL value, and the assigned Jamf API roles before re-running the policy.