Flawless MDM communication

Learn how to ensure your devices are enrolled and up to date with Jamf Pro in this enlightening talk from Patrick Weber and Isaac Ordonez from Mann Consulting.

October 3 2024 by

Hannah Hamilton

Flawless MDM Communication title slide

Enrolling your devices in a mobile device management (MDM) solution is necessary to keep them secure. But how do you know your device effectively communicates with your MDM to get its required settings?

Patrick Weber and Isaac Ordonez from Mann Consulting answer this very question in their JNUC presentation! In particular, they focus on four common communication failures — walking us through their symptoms, causes, detections and remediations.

Apple Push Notification service (APNs) communication failure

APNs is Apple’s standard service for push notifications, responsible for configuration profiles, device wipe and lock, and VPP installation. When a device cannot communicate with APNs, admins may observe:

  • Config profiles installation failure
  • VPP apps installation failure
  • Remote commands failing
  • App Installers not working

This can be hard to detect, and there are multiple possible causes. Weber and Ordonez created an extension attribute (EA) that checks the last date of a successful command, as well as time-based error codes that indicate the error type. Errors are indicated when their device returns a date of 2000-01-01; more specifically if the time is:

  • 00:00:02, the MDM profile isn’t found
  • 00:00:03, the client identity certificate or private key is missing
  • 00:00:04, the client identity certificate is expired

After creating a Smart Group that identifies devices with these errors, IT can intervene and reenroll the device.

Jamf check-in failure

Devices check in to Jamf Pro at a regular interval, after which they can receive policies, install packages or run scripts. This may fail if the Jamf LaunchDaemon is removed, a policy is hung or there is an issue with the Jamf client certificate.

Failure can look like:

  • A device receiving an MDM profile but not checking in recently
  • Policies not running and inventory not updating
  • Issues with the Jamf binary

To fix this, Ordonez and Weber created a Smart Group containing devices with last check in beyond 14 days. These devices then received a config profile with a null payload; devices with this payload were then put in their own Smart Group. Then, Jamf management is redeployed over APNs via the Jamf API.

Incomplete or partial check in

Jamf policies run sequentially and in alphabetical order, and do not have a TTL. This can stall the check-in process for a variety of reasons — enumerated in the presentation.

To combat this, the speakers:

  • Create a policy beginning with “zzzz” (which is therefore the last policy to run) that writes the current date and time to a file
  • Use an EA to grab this date and time and report it to the database
  • Create a Smart Group where the date/time of the last check-in starting does not sync with the date/time of the last check-in finishing
  • Use the Mann Communications Doctor to set a TTL for processes, preventing the policy installation from hanging

Incomplete inventory

The API or admin actions can change the date/time an inventory record was last updated — without actually updating the inventory record with the latest information. Devices may have inventory records that are out of date while also having a recent check in.

Ordonez and Weber identify affected devices with an EA that writes the current date/time in the inventory, then a Smart Group with computers with out-of-sync “last inventory” and “last date written” data.

To remediate this, they provide a few options:

  • Run recon in verbose mode
  • Reenroll via the API
  • File ticket with Jamf Support

Check out Mann Consulting’s website for scripts and more info!

Visit the Jamf blog for JNUC updates, session recaps and more!