-
Notifications
You must be signed in to change notification settings - Fork 6
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| HTTP 400 | Wrong scope (ABM key with ASM) | Check Account Type matches where you created the key |
| HTTP 400 | Wrong Client ID or Key ID | Double-check both in ABM/ASM Settings → API |
| HTTP 401 | Private key doesn't match Key ID | Create a new key; re-download the .p8 file |
| Network error | Firewall blocking account.apple.com
|
Test connectivity to https://account.apple.com
|
| Symptom | Likely cause | Fix |
|---|---|---|
| HTTP 401 | Expired client secret | Regenerate in Jamf Pro → API Roles and Clients |
| HTTP 404 | Wrong server URL | No trailing slash; include port if non-standard |
| Connection refused | VPN required | Check whether Jamf requires VPN from your network |
invalid_client |
Wrong Client ID | Copy from Jamf Pro → API Clients |
- Confirm your ABM/ASM organisation has enrolled devices
- Check the API key is Enabled in ABM/ASM Settings → API
- HTTP 403 in the log usually means the key was revoked
- Verify the API Role has Read Computers and Read Mobile Devices
- Check the client hasn't expired (Jamf clients can have an expiry date)
- Reduce Page Size to 500 if you see timeout errors
- Devices must be In Both with an AxM Device UUID
- If Do Not Refetch is on and all devices already have results, Step 3 is skipped — this is correct
- Check Sync Device Types — if set to Mac Only with no Macs, coverage is skipped
- Confirm Step 1 completed — without AxM UUIDs there is nothing to look up
- Most common cause: missing Update Computers or Update Mobile Devices on the API Role
- HTTP 400 on mobile devices can mean the date format is wrong — this is handled automatically in v1.2+
- HTTP 404 means Jamf can't find the device by ID — may have been deleted between Step 2 and Step 4
Both Step 1 and Step 2 must complete in the same sync run. If you're starting from an empty database, wipe the cache and run a full sync with Device Cache set to 0.
The app picks the record with the latest end date when a device has multiple coverage records. If the date seems unexpectedly far in the future, check for an extended warranty plan in ABM.
- Step 4 runs after Step 3 — check immediately after Step 3 completes may show old data
- Check Jamf Update Status in the Devices tab. If Failed, see the error note in device detail. If Pending, run sync again
Apple's API returned no record — common causes: device purchased from a reseller not registered with Apple, refurbished/replacement unit, or no AppleCare was ever purchased. Export the No Coverage Info Found preset from the Export tab to investigate.
- Requires v1.2 or later
- The fields come from ABM/ASM
orderNumberandorderDateTime— if Apple has no order data for the device, these will be empty - Mobile devices require ISO 8601 format dates (handled automatically)
The view is re-keyed on every environment switch — all data should update immediately. If you see stale data, switch away and back to force a refresh.
Symptom: the sidebar shows ABM but credentials are for ASM, or the Setup tab shows the wrong account type locked.
Resolution — automatic: close and reopen the app. v2.1 auto-corrects scope mismatches on launch using the Keychain scope key, clientId prefix (SCHOOLAPI/BUSINESSAPI), or the scope of synced data — whichever is available.
Resolution — manual: go to Setup for the affected environment, tap the correct account type button. The sidebar updates immediately.
The migration runs once on the first v2.0 launch. If it keeps appearing, the environments list may not be persisting — check that UserDefaults are writable (sandbox container intact).
Each environment has its own isolated Keychain namespace. After switching, re-enter credentials in Setup → Save to Keychain for the new environment.
The last remaining environment cannot be deleted — at least one must always exist.
-
Most likely: the current sync ran from device cache — MDM data only refreshes when orgDevices runs a live fetch. Check the Sync tab log for
Step 1b — Skipped. Run a sync with Force Refresh Devices enabled, or wait for Device Cache (days) to expire. - The Apple API key may not have access to
/v1/mdmServers— check the log for a Step 1b HTTP error. - The organisation has no MDM servers configured in ABM/ASM (expected for new orgs).
MDM assignment data refreshes with the device cache. Go to Setup and enable Force Refresh Devices, then run a sync, or wait for the Device Cache (days) setting to expire.
The filter appears only after the first sync that includes a live orgDevices fetch. If no sync has run yet or the cache is very fresh, run a sync with Force Refresh Devices to populate the data.
- The app only fires scheduled syncs while it's running — if it was force-quit (not just the window closed) at the scheduled time, that run is skipped rather than caught up later. Check that Launch at Login is enabled (Settings → General) so the app reopens automatically
- Confirm Automatically Sync is still on — Settings → Schedule
- Check the Next Sync badge in the header bar (or the menu bar dropdown) to see what the app currently believes the schedule is
This means Automatically Sync is off. Click the badge to open Settings → Schedule and turn it on.
Day(s) and Week(s) hour selections all share one minute value — you can't mix, say, 8:00 and 14:30 in the same schedule using the friendly controls. If you need mismatched minutes across times, use Advanced (Raw Cron Expression) and write the expression directly. See Scheduling for details.
- Confirm the app is actually running — check Activity Monitor
- If Show in Dock is off (Settings → General), the Dock icon is intentionally hidden, but the menu bar icon should still be present. If it isn't, the app has likely quit or crashed — check Console for a crash report and relaunch
- The menu bar icon shares the app's icon — if it looks wrong or missing entirely after an update, quit and relaunch the app once
Check System Settings → Notifications → AxM Jamf Sync and confirm notifications are allowed. macOS only asks once, the first time a notification is sent — if you denied it then, you'll need to re-enable it manually.
- Apple's coverage API has an undocumented rate limit. The app uses 3 concurrent requests — this is conservative but safe
- Enable Do Not Refetch to skip already-checked devices on repeat runs
- Use Coverage Fetch Limit (e.g. 500) to spread the load across multiple runs
Reduce Page Size to 500. Large pages on a busy Jamf server can exceed the 30-second timeout.
~/Library/Containers/com.karthikmac.axmjamfsync/Data/Library/Logs/AxMJamfSync/sync.log
~/Library/Containers/com.karthikmac.axmjamfsync/Data/Library/Logs/AxMJamfSync/environments/{uuid}.log
Open via Help → Open Sync Log in Console (active environment) or Help → Show Sync Log in Finder (⌘⇧L).
Logs rotate at 10 MB, keeping 5 archives. Permissions are 0600 (owner read/write only).
Every line is tagged [GUI] or [CLI] depending on which one wrote it — see Command-Line Mode for running syncs from launchd/the terminal.
As of v2.4, the fastest way to gather everything above at once: Help → Export Diagnostics…. It builds a zip with app/environment metadata, a per-environment settings summary, and every live and archived log file — attach that directly to your issue. It never includes credentials, API keys, or your Jamf/Apple server hostnames, so it's safe to share. As of v2.5, every device serial number in the bundled logs is also replaced with a consistent <device N> placeholder, so the zip doesn't reveal your org's device inventory either.
Otherwise, open an issue and include:
- macOS version and app version (About AxMJamfSync)
- Which step failed and what the Sync tab showed
- Relevant section of the sync log
- Whether reproducible or intermittent
Do not include your private key, Client Secret, or bearer tokens.