Jamf Pro Inventory Not Updating: Why Macs Stop Reporting After Enrollment and How to Force Recon

A hung script blocks recon from completing. Recon runs extension attribute scripts as part of its collection pass. A script that hangs (commonly one that shells out to a command like softwareupdate that can itself stall waiting on a network resource, or a script with no timeout handling around a slow or unresponsive external call) can prevent the recon process from ever finishing and reporting back, even though the jamf binary process technically started. This is one of the most commonly reported causes of otherwise-unexplained stale inventory in Jamf admin discussions.

The jamf binary or management framework has become corrupted. The jamf binary, its supporting LaunchDaemons, and local configuration files can be damaged by a failed macOS update, an interrupted framework upgrade, disk corruption, or third-party endpoint security software interfering with the binary's execution. When this happens, MDM check-in can continue to function (it is handled by macOS's own MDM client talking to APNs, independent of the jamf binary) while jamf binary operations, including recon, silently fail or stop being triggered at all.

A required LaunchDaemon is disabled, missing, or fails to load. Scheduled recon relies on a LaunchDaemon to fire on the configured interval. If that LaunchDaemon has been removed, disabled by a configuration profile conflict, or fails to load due to a permissions issue, scheduled recon simply never runs again, while manually triggered check-ins from Jamf Pro can still succeed.

The device cannot reach the Jamf Pro server URL over HTTPS even though APNs works. MDM check-in traffic and jamf binary HTTPS traffic to the Jamf Pro server do not necessarily take the same path or depend on the same conditions. A proxy change, a certificate trust issue specific to the Jamf Pro server URL, a DNS change, or a firewall rule that blocks the JSS URL while leaving Apple's push infrastructure reachable can leave check-in working while recon submissions fail outright or time out.

Local disk space is exhausted. A full startup disk can prevent the jamf binary from writing its local logs or temporary files during recon, causing the process to fail partway through without necessarily producing an obvious error the admin will see remotely.

Third-party security or management software interferes with the jamf process. Community reports describe correlation, though not a confirmed universal cause, between recon failures and the presence of other endpoint agents on the same Mac. Treat this as a hypothesis to check on affected machines, not a confirmed root cause, until you have evidence from your own environment.

Work through these in order, starting locally on one affected device before assuming a fleet-wide problem:

1. Confirm the split between check-in and inventory in Jamf Pro itself. On the device record, compare the "Last Check-in" timestamp against the "Last Inventory Update" timestamp. If check-in is recent and inventory update is stale, you have confirmed this is a recon-specific failure, not a connectivity or enrollment problem.
2. Read the local jamf log. On the affected Mac, review /var/log/jamf.log for the most recent recon attempt. This log records nearly every recon failure with a specific error, whether that is a failed HTTPS submission, a script error, or a process that never completed. Start here before anything else.
3. Run recon manually and watch it in real time. From an administrator terminal session on the device (or via remote access if available), run sudo jamf recon -verbose and watch whether it completes, hangs on a specific extension attribute, or fails with a network or authentication error. A hang at a specific point identifies the exact script or step at fault.
4. Check MDM enrollment and management framework health. Run profiles status -type enrollment to confirm the device's MDM enrollment profile is still valid and not pending user approval, and check jamf binary version reporting to confirm the management framework itself is intact and not partially removed.
5. Confirm the Jamf Pro server URL is reachable over HTTPS from the device, separately from confirming APNs connectivity, since the two use different paths. A simple reachability test to the JSS URL from the affected Mac's network will surface a proxy, DNS, or certificate trust issue that would not show up in check-in status.
6. Check available disk space on the affected device, since a full disk can silently break local logging and recon file writes.
7. Look for a pattern across devices, not just one. Build a smart group filtered on "Last Inventory Update" older than a threshold (for example, 10 days) while check-in remains current, and check whether affected devices share an OS version, a specific installed application or agent, a network segment, or an imaging batch. A shared pattern points toward a systemic cause (a bad extension attribute script pushed fleet-wide, a network change, a framework version issue) rather than isolated hardware or user behavior.

Fix 1: Force a manual recon and read the result. Run sudo jamf recon -verbose directly on the device (locally, via remote screen sharing, or via a Self Service policy scoped to the affected device) and confirm it completes and returns to the prompt without error. This alone resolves the immediate staleness for that device and gives you diagnostic output if it fails again.

Fix 2: Trigger inventory update remotely via an MDM command. If you cannot get physical or remote-session access to the device but it is still MDM-reachable, send an UpdateInventory MDM command from Jamf Pro (via the device record's management commands, or the Classic or Pro API) to trigger recon without requiring local access. This depends on the device still being reachable over APNs, which is why confirming check-in status separately in the diagnostics step matters.

Fix 3: Fix or remove the specific extension attribute script causing the hang. If manual recon output identifies a script that hangs or errors, correct the underlying script logic (add a timeout around any external command call, handle a non-zero exit code explicitly) or temporarily remove that extension attribute from scope while you fix it, rather than leaving every device it is scoped to unable to complete recon.

Fix 4: Redeploy the management framework. If the jamf binary or its LaunchDaemons are corrupted, redeploy the management framework rather than attempting to patch individual files. This is typically done by re-running the enrollment process (re-enrolling the device through your existing enrollment method) or using Jamf Pro's built-in "manage" command path to reinstall the framework without a full wipe. Confirm LaunchDaemons for the jamf binary's scheduled tasks exist and are loaded after the redeploy.

Fix 5: Resolve network or certificate access to the Jamf Pro server URL. If diagnostics show the device cannot reach the JSS URL over HTTPS, work with network or identity teams to correct the proxy configuration, DNS entry, firewall rule, or certificate trust issue specific to that URL, since this is independent of whatever is allowing APNs check-in to keep working.

Fix 6: Free up disk space and retry. If disk space was exhausted, clear space (removing unnecessary local caches or large files under IT policy) and re-run recon to confirm the fix, rather than assuming freeing space alone silently resolved the earlier failure.

Fix 7: For mobile devices in a mixed fleet, review BYOD-specific enrollment and profile constraints. If the affected devices are personally owned under a BYOD program rather than fully managed corporate hardware, confirm the enrollment type and profile scope match what your MDM and BYOD guide specifies, since a User Enrollment or BYOD-scoped device may have different inventory collection limits than a fully supervised device by design, not by failure.

1. Confirm the Last Inventory Update timestamp advances in Jamf Pro after the fix, not just that a manual recon command exited without a visible error.
2. Confirm specific data points you rely on are actually populated correctly, not just that the timestamp updated. Check that the extension attribute values, application inventory, and any compliance-relevant fields your smart groups depend on reflect the device's real current state.
3. Wait for the next unattended, scheduled recon cycle and confirm it also succeeds, rather than validating only the manually forced run. A device that updates correctly when manually triggered but fails again on its own schedule still has an unresolved underlying cause, most often the LaunchDaemon or scheduling issue rather than the data collection itself.
4. Re-run the smart group you used in diagnostics (devices with stale inventory despite recent check-in) and confirm the fixed device has dropped off the list.
5. If the fix was a framework redeploy or re-enrollment, confirm no other managed functionality regressed, such as configuration profiles, Self Service policy visibility, or FileVault key escrow, since a redeploy touches more than just inventory collection.
6. For a fleet-wide fix (a corrected extension attribute script, a network rule change), re-run the same smart group across the full fleet, not just the device you originally investigated, to confirm the fix generalized rather than only working on the one device you tested.

Forcing recon does not fix a recurring cause. Running sudo jamf recon manually resolves the immediate staleness for that device but does nothing to prevent the same script hang, framework corruption, or network issue from recurring at the next scheduled interval. Treat a manual fix as validation of the diagnosis, not as the actual remediation, until the underlying cause is corrected.

The UpdateInventory MDM command only works if the device is genuinely MDM-reachable. If the real cause is that the device cannot reach the Jamf Pro server URL at all (a network, DNS, or certificate issue), the MDM command channel over APNs may still succeed in queuing the command, but the device itself will still fail to submit the resulting inventory data back to the server, producing the same stale result with no clearer error message.

Self Service-triggered recon requires the device to be in front of an active user and on the network. This does not help unattended machines, kiosks, or offline devices, and is not a substitute for fixing the scheduled recon path.

Re-enrollment or framework redeployment carries its own operational risk. Reinstalling the management framework can briefly disrupt other managed functionality and, depending on method, may require the device to briefly leave and rejoin MDM management. Do not use this as a first-line fix for a single device with a known, narrower cause such as a hung script.

Community reports describe this as a recurring, not fully root-caused issue across the Jamf admin community. Multiple independent threads describe similar symptoms (random endpoints silently stopping inventory updates for extended periods) without a single confirmed universal root cause, meaning the causes listed above are the documented and reported ones, not an exhaustive list. If none of them match what you find in your own logs, do not assume you have exhausted the possibilities before escalating.

Handle this internally using the diagnostics and fixes above when you can identify a specific, reproducible cause on the affected device or devices: a hung extension attribute script, a corrupted framework you can redeploy, or a network path issue you can correct.

Escalate to Jamf support when any of the following apply:

• The issue affects a significant portion of the fleet with no shared pattern across OS version, hardware model, network segment, or installed software, after you have already checked for one.
• jamf.log on affected devices shows no error at all for the failed recon attempt, meaning local diagnostics have been exhausted without an actionable finding.
• Jamf Pro server-side logs show inventory submissions arriving and failing to process correctly, which points at the server side rather than the endpoint and is outside what an admin can fix locally.
• The same devices repeatedly regress after a fix that has already been validated as working at the time it was applied, suggesting a deeper framework or server-side issue rather than a one-off local failure.
• You need to confirm whether a specific symptom matches a known issue in a particular Jamf Pro or jamf binary release, which requires Jamf's own release and defect tracking rather than public community reports.

When you open a case, provide the jamf.log excerpt from an affected device covering a failed recon attempt, the Jamf Pro version and jamf binary version in use, and the smart group results showing how widespread the pattern is. That scope and log detail is what will get the case triaged correctly on the first pass.