5. Shipping agent updates

Owner: IT Prerequisite: Steps 1-4 are complete - the initial Arbium pilot rollout is live and the smoke test came back green.

When the Arbium team ships a new agent version (e.g. RootsMac-1.1.4.pkg), the existing app entry from Step 3 is updated in place. Devices auto-upgrade on next sync — no re-enrollment, no per-device touch.

This page is the steady-state operational flow for that update cycle. Backend updates (new chart version, new images) are Cloud Ops’s responsibility and roll out independently — see Cloud Ops Step 3 - Upgrading the chart. IT does not redeploy anything when the backend is upgraded; agents reconnect against the same endpoint. The Admin UI is part of the backend chart, so admin upgrades also need no action from IT.

What we send for an update

• The new PKG: RootsMac-<version>.pkg (one universal PKG covers x86_64 + arm64).

Update the app in Jamf

1. Settings > Computer Management > Packages. Upload the new .pkg.
2. Edit the existing install policy (created in Step 3) and point it at the new package.
3. Save. On next recurring-check-in trigger, scoped devices download and install the new version. Jamf installs as root; no per-user permission prompts.

Update the app in Intune

1. Apps > macOS > Roots (the entry created in Step 3).
2. Properties > App information > Edit.
3. Upload the new .pkg.
4. Intune reads the bundle metadata. If you set “Ignore app version = Yes” in Step 3 (recommended), there’s no version comparison to satisfy — just upload and save. Without that flag, Intune may complain that the embedded Sentry framework version hasn’t changed; the workaround is to ensure the agent’s own CFBundleShortVersionString beats whatever it’s compared against.
5. Review + save.

What happens on the device

On next MDM check-in (~8h default cycle, or sooner with a manual Sync):

1. The MDM downloads the new PKG.
2. The installer’s pre-install script unloads the running LaunchAgent for the current console user.
3. PKG installs in place at /Applications/Roots.app.
4. The post-install script re-loads the LaunchAgent in the console user’s GUI session, which respawns the agent on the new binary.

If no user is logged into the GUI when the update lands, the post-install bootstrap silently skips and the LaunchAgent auto-loads on next user login.

Update the managed preferences (only if needed)

For pure binary updates, no profile change is needed — skip this section.

If the new version changes the config schema (e.g. adds a new key) or the values themselves change (different endpoint, different Entra tenant), update the managed-preferences profile:

1. Edit the profile in Jamf or Intune.
2. Substitute the updated placeholders (see Step 2 for the full key set).
3. Re-deploy to the pilot group.

The Mac agent re-reads its managed prefs on next launch — the next LaunchAgent restart (which happens with the binary update) picks up the new values automatically.

Force-deploy to a canary device

To validate immediately on one canary first:

• Jamf: sudo jamf policy on the device.
• Intune: Company Portal > “Sync this device”.

Within ~5 minutes the new PKG downloads and installs. The agent is killed, upgraded, and restarted automatically.

Verify on the canary

Same checks as Step 4 smoke test, plus a version comparison:

defaults read /Applications/Roots.app/Contents/Info.plist CFBundleShortVersionString
# Expect: the new version (e.g. 1.1.4)

pgrep -lf Roots
# Should show the Roots process with a recent start time

Tail the runtime log to confirm a ready event from the new release:

tail -f ~/Library/Application\ Support/RootsMac/status.jsonl

In Sentry Logs, filter by the new release (e.g. release:roots-mac@1.1.4) and confirm status.type: ready + status.type: upload entries appear.

After the canary is green, the wider device group auto-upgrades on its natural sync cadence. No further action.

Roll back

To revert to a prior agent version: re-upload that version’s .pkg to the same app entry.

With Intune’s “Ignore app version = Yes” set, downgrades work the same as upgrades — the binary on disk is replaced regardless of version comparison. Jamf treats it as a normal package install.

If you hit any “newer version already installed” complaint, uninstall first (push a shell script that removes /Applications/Roots.app + unloads the LaunchAgent + clears TCC + drops the pkgutil receipt), then re-install the older version.

Ping the Arbium team if you need to coordinate a rollback — we can confirm which approach fits your deployment.

Done

The pipeline self-heals from here. Monitor Sentry for runtime errors from the fleet, and check the backend public.captures table for ongoing health.