Package-Free Patch Management in Jamf Pro

Pre-deployment Verification

Before pilot deployment, each Installomator label would be run locally with DEBUG=2. This performs the pre-deployment security checks without installing the application, allowing IT to verify the vendor source, detected version, archive/installer handling, code-signing/notarization, and expected Team ID, and to test the Jamf wrapper script before the 10-Mac pilot.

Pilot Go or No Go

Go: 10/10 pilot Macs complete the intended update without unintended application installation, data loss, forced termination of active work, or security-validation failure. Any initial failure must have an identified root cause, documented remediation, and a successful retest before production.

No-go: Any unresolved failure, incorrect scope, authenticity-validation failure, or destructive user-impact issue pauses rollout.

Production Stages

After a go decision is approved, a company communication would go out informing all employees that their applications will be updated on an ongoing basis and that they will be notified of the 5-day update timeline. Production computers would be scoped and monitored first. Once deemed successful, the executive rollout would begin, with a war room contact made available. Conference room updates would be scheduled with staff for manual deployment every Thursday at an agreed after-hours time. IT will connect to Conference Room devices via SSH and invoke sudo jamf policy -id <POLICY_ID> for the corresponding Update - [App] - Conference Room policy. Updates to Installomator and swiftDialog versions on Conference Room devices will also be handled manually.

Executive and Conference Room

Deferral timing is managed by the application update script. Standard application policies pass $8Deferral_profile:standard, and Executive policies pass $8Deferral_profile:executive. The script records when it first observes the update and calculates the appropriate Available, 48-hour, 24-hour, or Required stage based on elapsed time.

7 Day Deadline Plan

The deferral period for standard production devices is limited to 5 days, leaving a 2-day remediation buffer to reach at least 95% compliance within the 7-day requirement. Executive devices receive the additional 48-hour deferral, making their final required stage day 7.

Rollback Steps

Pause and containment: Pause and containment can be handled by removing scope from the affected application update policy. This prevents additional devices from running the policy and limits the impact of an identified failure.

Rollback: An Installomator rollback can be performed by updating the approved version and SHA-256 in the deployment policy to the previously approved release. This will not roll back devices that have already received the newer Installomator version, but it prevents additional devices from receiving the impacted version. Application rollback would require uninstalling the impacted application and reinstalling the appropriate version.

Recovery: Application recovery would require uninstalling and reinstalling the application. If the updater itself is impacted, Installomator can be run in DEBUG=2 to troubleshoot and validate the issue before remediation and production scope are restored.

Open-Application Behavior and Deferral Deadline

I chose a 5-day deferral deadline to provide a 2-day buffer and increase the probability of reaching 95% compliance within the 7-day requirement. Open applications receive increased messaging before becoming required to reduce work interruption. I rejected a full 7-day deferral because it leaves no remediation buffer. The failure mode I wanted to avoid was devices remaining non-compliant at the end of the reporting window because users deferred too long or had applications open.

Release Selection and Keeping Untested Releases Out of Production

Jamf Patch Management identifies when an application is outdated, and Installomator is trusted to obtain and validate the latest vendor release. Updates are first validated against the pilot cohort before broader production rollout. An approved-version gate inside the updater was considered but not implemented to avoid adding unnecessary complexity to the workflow. The failure mode I wanted to avoid was an untested vendor release reaching broad production before the update path had been validated on the pilot Macs.

Updater Maintenance and Replacing a Reviewed Version

I chose to keep production on the reviewed Installomator release/stable version while limiting the main version to pilot devices. Once the main version is tested and approved, the production policy is updated with the approved version and SHA-256. I rejected automatically updating production to the latest Installomator version. The failure mode I wanted to avoid was an untested updater change reaching production and causing application update or validation failures across the fleet.

1. The approved Installomator beta (main) version is 11.0, and the approved production (release) version is 10.9. | 2. Jamf Pro v11.32 is used for this case. | 3. Installomator is deployed at /usr/local/Installomator/Installomator.sh. Standard production and Executive Macs use the approved release build (10.9); Patch Pilot - Managed Apps uses the approved main build (11.0); Conference Room Macs are assumed to already have the approved release build and use the manual repair policy (3.23) if needed [3]. | 4. Homebrew has already been installed and is updated via a Jamf script policy that installs once and checks for updates (out of scope). | 5. ChatGPT Classic is the preferred application (keeps Codex separate). | 6. swiftDialog 3.1.0 or later is assumed to already be available at /usr/local/bin/dialog and is used only for end-user messaging. The existing deployment policy (3.5) is reused for managed production devices, while Conference Room Devices use the manual fallback policy (3.24) only if swiftDialog needs repair or redeployment. | 7. Cohort device groups are created as Static Groups: Executive Devices, Conference Room Devices. | 8. Patch Management software titles have been added and configured for Google Chrome, ChatGPT Classic, OpenAI ChatGPT Codex, and Slack (Computers > Patch Management > +) [4]. | 9. Jamf objects are defined as Configuration Profiles, Extension Attributes, Mac Apps, Packages, Patch Policies, and Policies [5]. Static Groups, Smart Groups, and Scripts are assumed to be Jamf objects as well. | 10. Based on the available Jamf Patch Management titles and OpenAI's current desktop-app transition, “ChatGPT” in the exercise refers to OpenAI ChatGPT Classic, while “Codex” refers to the newer ChatGPT/Codex desktop application. They are treated as separate installed applications for reporting, scoping, and remediation. | 11. Patch Pilot - Managed Apps is a Smart group populated by the Department inventory attribute | 12. Executive & Conference Cohort Devices are a Static Group | 13. Existing Google Chrome and Slack packages are associated with versions in their Patch Management software-title definitions and are used by the legacy Google Chrome and Slack Patch Policies [7][8]. | 14. Computer Inventory Collection settings have been enabled

Operational Documentation

A Package-Free Application Management runbook should be documented during rollout and maintained post-rollout for Service Desk and IT Engineering.

The runbook will document the Installomator and swiftDialog dependencies | how to verify approved Installomator versions and SHA-256 hashes | application labels | Jamf policy parameters | how to manage application reporting and maintain the Jamf Dashboard | expected logs | common failure conditions | troubleshooting procedures | rollback/recovery steps | the process for testing, approving, and promoting new Installomator versions.

Service Desk: Inventory Refresh and Safe Retry

Service Desk first runs sudo jamf recon to refresh inventory, then confirms the Mac is still in the applicable Update Eligible - [App] Smart Group and is not in the [App] - Absent exclusion group. If the application is still installed and eligible, Service Desk can safely retry the corresponding Update - [App] policy by policy ID. The updater script performs an installed-only check before remediation, so the retry does not install an absent application.

#2: A Mac belongs to the production scope but never runs the update policy.

1. Verify the Mac is a member of the applicable Update Eligible - [App] Smart Group and is not in Conference Room Devices, Patch Pilot - Managed Apps, Executive Devices, or the matching [App] - Absent exclusion.

2. Verify the Mac has checked in and its inventory is current; run sudo jamf recon -verbose if the inventory may be stale.

3. Review the Jamf Policy Log for the applicable Update - [App] policy. If scope is correct and the policy has not run, manually invoke it with sudo jamf policy -id <POLICY_ID>.

#3: The updater reports success, but Jamf inventory still shows the older version.

1. Run sudo jamf recon or sudo jamf recon -verbose to force a fresh inventory update.

2. Verify the computer is still managed and that its Jamf computer record is receiving check-in and inventory updates.

3. Review the update policy’s Jamf Policy Log to confirm the policy ran successfully and compare its timestamp and actions against the last inventory update.

#1: One of the applications is unexpectedly installed on a Mac that did not previously have it.

1. Review the Mac’s current and previous inventory to confirm whether the application was truly absent before the event and identify when it first appeared.

2. Review the applicable Update - [App] policy scope and Policy Log to confirm whether the Mac was in the [App] - Absent exclusion group at the time and whether the new workflow actually ran.

3. Review Jamf policy and installation history to identify the actual deployment path. The new Update - [App] policies exclude the matching [App] - Absent Smart Group, and HillmanPackageFree_UpdatorFinal.sh also exits when the target app is not installed, so evidence that this workflow installed the app would indicate a scope or guardrail failure.

Classification and Absent Apps

Jamf classifies an installed Mac as Current, Outdated, or Unknown after inventory. Chrome, ChatGPT, Codex, and Slack use the corresponding Patch Reporting software title plus Application Version; Wispr Flow uses Application Version compared with the Wispr Flow - Latest Version Extension Attribute (1.4). All application update policies also exclude the matching [App] - Absent Smart Group, and the updater script verifies the application is installed before continuing with remediation.