Why Sending an MDM Command Does Not Mean It Has Been Executed

Operations such as Assign Policy and Lock Device in an MDM console may look instantaneous, yet they initiate an asynchronous chain that includes the MDM backend, message queues, Apple or Google infrastructure, the on-device agent, and a return reporting channel.

Any component in this chain can become temporarily unavailable, and the device itself may lack network connectivity. Aitera MDM treats controlled delivery of the desired state with verifiable results as a core component of device management rather than focusing solely on policy creation or restriction sets.

One Operation — Multiple Independent States

The phrase “command sent” can represent at least four separate events: the administrator request accepted by the API, the command stored and queued, the external Apple or Google infrastructure accepting the request, and the device executing the command with a reported result. A 200 OK response only confirms HTTP request processing; writing to a persistent queue guarantees survival across restarts but does not confirm delivery.

Therefore MDM systems should maintain three distinct state types: desired state (what the administrator wants), delivery state (where the command currently resides), and observed state (what the device has actually reported). Attempting to store all information in a single boolean field almost always produces false statuses.

Android: Policy Travels Through Google

In Android Enterprise the MDM server does not open direct connections to each device. It posts a Policy object to the Android Management API and relies on the Android Device Policy agent for synchronization. A successful Policies.patch call indicates only that Google accepted the new desired state; it does not confirm application on any specific phone. One-time commands such as lock or lost-mode requests follow a separate device command API path that likewise reports acceptance rather than final execution.

iOS: APNs Only Wakes the Device

Apple MDM uses a pull model. The server places commands in a per-device queue and sends a silent APNs push solely to wake the device. The device then connects and requests the next command; the server returns a plist in the HTTP response. The device later reports Acknowledged, Error, or NotNow. The NotNow status demonstrates why a simple success/failure pair is insufficient: the command remains valid and must stay queued.

Practical Requirements for Reliable Delivery

Aitera MDM applies the Outbox pattern so that policy changes and delivery events are recorded in a single transaction. Retries follow exponential backoff with jitter, respect circuit breakers, and never repeat irreversible actions such as wipe until idempotency is assured. On-premises deployments still require outbound access to APNs and Google endpoints; network isolation therefore demands explicit planning of allowed routes, proxy settings, and timeout behavior.

Useful operational metrics include the percentage of devices confirming current policy, median and 95th-percentile policy application time, queue depth and oldest command age, and divergence between desired and observed states.