Jamf Fleet Toolkit

Overview

Four command-line tools for the questions that come up every week on a large macOS fleet and that the Jamf console does not answer cleanly: which Macs are not encrypted, which have fallen off the map, which smart groups are dead weight, and whether a policy changed without anyone noticing.

Problem

At fleet scale the same audit questions recur weekly, and each one turns into manual console clicking that produces an answer nobody can reproduce later. Jamf’s built-in reporting does not cover them, so the answers end up inconsistent between the person asking and the person checking.

Approach

Each recurring question became a tool that runs the same way every time and writes a CSV, so the answer is auditable instead of remembered. Authentication uses Jamf’s API Roles & Clients OAuth2 client-credentials flow, not the deprecated username/password token endpoint.

• reports/compliance_report.py: checks every managed Mac against a baseline (FileVault, minimum OS, recent check-in, SIP, firewall) and writes a per-device CSV plus an overall compliance rate.
• reports/stale_devices.py: finds Macs past a check-in threshold, newest-stale first, with the assigned user so you know who to chase.
• remediation/smart_group_audit.py: cross-references smart groups against policy scopes to flag groups with zero members and groups no policy uses.
• remediation/policy_drift.py: snapshots policy configuration to a JSON baseline, then diffs the live environment against it and reports new, deleted, and field-level-changed policies.

Architecture

jamftk/client.py wraps the Jamf Pro API with OAuth2 auth, transparent token refresh with a safety buffer so long pulls do not expire mid-flight, one automatic retry on a 401, and a generator-based paginator. Credentials load from environment or a gitignored .env.

The toolkit is read-only by design. Every tool reports and audits; none write back. Remediation stays in reviewed Jamf policies, where change control already applies.

Outcome

Recurring fleet audits became reproducible commands with CSV output instead of console sessions, and policy drift became something a diff against a known-good baseline detects instead of something noticed after it caused an incident.

Lessons Learned

Keeping the toolkit strictly read-only was the decision that made it trustworthy to run against production. A reporting tool that could also mutate the environment invites hesitation before every run; one that provably cannot gets used freely, which is the whole point.