Iru Endpoint uses different check-in mechanisms depending on the device platform. Each platform has specific check-in types that serve different purposes and occur at various frequencies. Understanding these check-ins helps you track device state, enforce policies, and ensure applications are deployed reliably.
Frequency: Every 15 minutes Mechanism: Kandji AgentThis check-in ensures that the Kandji Agent is up-to-date, executes and enforces Blueprint parameters, and installs any pending library items such as custom scripts, printers, apps, and auto apps. Each item has a specific timeout period for installation.
Library Items are processed in a specific sequence. Each type of Library Item is handled in an alphanumeric order, with uppercase letters taking precedence over lowercase ones. The timeout values define the maximum time allowed for each Library Item to complete its installation or execution before it is stopped. Additionally, each run is governed by a global timeout limit of 12 hours, which also applies to installations of Custom Apps and Apps and Books initiated through Self-Service.
Frequency: Every 24 hours Mechanism: Kandji AgentThis check-in includes all recurring check-in items and additional daily items like custom scripts, compliance scripts, and Blueprint parameters. It also involves securing home folders, checking application and system folders for appropriate permissions, and collecting daily computer information for submission to the Iru Endpoint tenant. The daily check-in follows the same sequence as the recurring one, starting after executing Blueprint Parameters. Once all Library Items are completed, the application inventory is sent back to Iru Endpoint.
Frequency: Every 24 hours Mechanism: Apple Push Notification Service (APNs) / MDM FrameworkThis check-in involves executing the following MDM commands to update device information:
Frequency: Instant Mechanism: APNs / MDM FrameworkThis check-in allows for instant execution of any MDM command, such as wiping a device, setting a device name, or installing applications. It also includes any profile deployed via a Library Item.
MDM servers send a unique notification to the Apple Push Notification service, prompting managed devices to check in with their MDM server. Apple devices regularly poll APNs for these notifications, enabling almost immediate management of devices that are online. Consequently, there isn’t a set check-in time for MDM commands, nor is there a way to enforce a check-in.
Frequency: Every 15 minutes Mechanism: Kandji AgentThis check-in ensures that the Kandji Agent is current, executes assigned policies, and processes app deployments. It also collects and submits application inventory on the same interval.During a recurring check-in, the Kandji Agent:
Retrieves and enforces specific policies assigned to Blueprints that are not deployed through the MDM channel
Frequency: Instant Mechanism: Windows Push Notification Service (WNS) / MDM FrameworkWhen you deploy a policy via the Iru Endpoint web app, the request is sent immediately via WNS. Managed devices that are online typically respond within minutes.Examples of instant commands include:
Wipe or retire a device
Deploy a configuration profile
There’s no fixed check-in interval for event-driven commands. They depend on device connectivity and WNS availability.
Frequency: Every 24 hours Mechanism: MDMA daily check-in evaluates all targeted policies and remediates anything that has drifted from admin intent. These tasks include:
Validating system configuration against admin intent and remediating if necessary
Collecting daily device information (system info, hardware inventory, policy status)
MDM servers send a particular type of notification to request managed devices to “Check in” with their MDM server. As part of Apple Push Notification service (APNs), Apple devices constantly poll Apple Push Notification service for Notifications. This results in near-instant management of online devices; as such, there is no defined “Check-in” time for MDM commands.
Frequency: Every 24 hours Mechanism: Apple Push Notification service/MDM framework Description: A combination of the following MDM commands automatically initiated by Iru Endpoint:
Frequency: Near real-time (within seconds) Mechanism: Google Pub/Sub notifications via Android Management APIAndroid devices use an event-driven check-in system that’s completely reliant on device status reports. When changes occur on the device, the device automatically reports these state changes to Google, who then relays the information to Iru Endpoint via Pub/Sub notifications. This mechanism works similarly to Apple’s Declarative Device Management status reports, providing near real-time updates as changes happen.
The Android Management API uses Google Cloud Pub/Sub to deliver device notifications to Iru Endpoint. When something changes on an Android device, Google receives that information and immediately sends it to Iru Endpoint through Pub/Sub.This approach works well because Pub/Sub is designed to handle large volumes of messages reliably. If there’s a temporary network issue, Pub/Sub will keep trying to deliver the notification until it reaches Iru Endpoint. Google also batches multiple device events together when they happen close together, which makes the system more efficient.The result is that you get near real-time updates about what’s happening on your Android devices - app installations, policy changes, security updates, and other important events all show up in Iru Endpoint within seconds of occurring on the device.
The Android event-driven approach offers several advantages:
Immediate Response: Device changes are reported as they happen, providing near real-time visibility
Efficient Resource Usage: Only reports actual changes rather than periodic status queries
Reliable Delivery: Pub/Sub ensures notifications reach Iru Endpoint even during network interruptions
Comprehensive Monitoring: Captures all significant device state changes automatically
Android check-ins are event-driven and provide near real-time updates through Google’s Pub/Sub notification system. This approach ensures immediate visibility into device changes without requiring manual check-in commands.
