Published 2026-09-20 · LuckyMDM Blog
Short answer: a batch click in a management console is not an execution figure. Every command you issue is broken into one command per device, each carrying its own CommandUUID and each returning its own acknowledgement. The number that tells you what actually happened is the acknowledgement count, and the gap between the devices you targeted and the devices that acknowledged is the part of the fleet you cannot see. On a 1,000-unit lock batch that returned 943 acknowledgements, the uncontrolled surface is 57 units, or 5.7 per cent.
Most fleet consoles collapse a multi-step pipeline into a single status word. The operator selects a group, presses lock, watches a progress bar and reads a confirmation. What that confirmation can legitimately mean is that commands have entered the outbound queue. What it is usually read to mean is that the devices locked. Between those two statements sit four dependencies, and any one of them can fail silently.
The underlying reason the gap exists is architectural: in Apple's management model the server does not push the command to the device. It pushes a wake-up and waits for the device to come and collect the work.
When an MDM server wants a managed device to do something, it sends a notification through the Apple Push Notification service using a management topic of the form com.apple.mgmt.External.<topic>. The notification carries the mdm key with a PushMagic value, which is an opaque token the device presents when it checks in. The command itself is not in that notification.
Two consequences follow. First, a push is not evidence of delivery, let alone execution. Second, APNs applies a store-and-forward quality-of-service policy in which only the most recent notification per app per device is retained, so ten pushes sent to an offline device collapse into one when it finally reconnects. Retrying harder does not make an offline device come back faster.
The push also carries parameters an operator can and should set deliberately: apns-priority, where 10 means send immediately and 5 means send at a time that considers power, and apns-expiration, where a value of zero tells APNs not to store the notification at all. A command batch sent with an expiration of zero to devices that happen to be offline is a batch that will never be woken.
After being woken, the device opens its own connection to the management server and pulls the queued command. This step depends entirely on conditions on the device side: whether it has cellular data or a usable Wi-Fi network, whether it is in a low-power state, and whether the operating system is willing to run the background work at that moment.
Execution authority therefore sits with the device, not the server. The server can queue, push and wait. That is precisely why queued and executed must never be presented to an operator as one state.
A device in a console usually shows at least two timestamps, and they are produced by different events.
| Clock | Produced by | Question it answers | Time basis |
|---|---|---|---|
| Check-in time | Device contacting the server on its polling cadence | Was this device alive recently? | Lags by up to one polling interval |
| Acknowledgement time | Device reporting the result of one command | Did this command actually run? | Depends on when the device reconnected |
| Ingest time | Server writing the result into its database | When did the console find out? | Seconds, but a different source from execution time |
These three are not derived from one another. A unit that checked in two hours ago looks healthy while its last command acknowledgement may be three days old, which means that for three days there is no evidence that any command reached it.
The cadence at which a device checks in is governed by a poll interval the server can return during check-in, expressed in seconds; if the server does not return one, the client follows its own schedule. Operators should confirm current behaviour against Apple's MDM Protocol Reference before writing service levels around it.
The important property is that the interval is also the floor on how late an anomaly can be detected. An interval of 24 hours means the worst case is that you learn about a problem a full day after it began, plus whatever time the command spent queued. Compressing the interval is not free: frequent check-ins cost battery and generate subscriber complaints, and long intervals cost detection speed. The usual resolution is tiering rather than a single fleet-wide value.
In Apple's MDM protocol a device returns a status for each command. The four states operators meet constantly are these.
| Status | Meaning | Counts as executed? | Correct follow-up |
|---|---|---|---|
| Acknowledged | Device performed the command | Yes | Archive as the record of action |
| CommandFormatError | Command or parameters malformed | No | Fix the payload; do not retry the device |
| Idle | Device is idle and has not run the command | No | Re-queue and wait for the next wake-up |
| NotNow | Current device state does not permit execution | No | Investigate the precondition, not the network |
The last two are where consoles lose information. Idle and NotNow are not failures, so retrying them endlessly produces noise; they are also not successes, so counting them as delivered produces a false green light. A console that only distinguishes success from failure makes two entire populations invisible.
Uncontrolled surface = units targeted minus acknowledgements received. The arithmetic is trivial; the discipline of running it every day is not.
Take an operator running a 5,000-unit subscription fleet that issues a lock batch against 1,000 delinquent units.
If those 57 units are never listed, the console shows a field of green. Weeks later, when a handful of them turn up on a resale marketplace, the post-incident review reaches for the one column that would have proved the lock happened, and finds it empty.
The instinctive remedy for a quiet batch is to run it again. Whether that is safe depends on idempotency.
With idempotency, each command carries its CommandUUID and the task carries an idempotency key, so a re-run skips units that already acknowledged and only re-issues to those that did not. Without it, a second press creates 1,000 brand new commands, units that already locked receive a second lock, and the log fills with duplicate rows that corrupt every statistic you later compute from it.
The test is simple. After a batch, pull three numbers: units targeted, acknowledgements received, and retry count. If those three cannot be reconciled with each other, retrying is manufacturing noise rather than closing the gap.
Check one, reconcile a batch. Open the batch task history, pick any completed job, and write down the target count, the acknowledgement count and the count with no acknowledgement. If the console does not display the acknowledgement count at all, it has been designed on the assumption that you do not need to know how much actually executed.
Check two, left join two lists. Export the last 24 hours of last check-in times and last acknowledgement times, keyed by serial number, and left join them. Units with a null acknowledgement and a check-in older than your threshold are your real uncontrolled surface at that moment. Express it as a percentage; above roughly 2 per cent you have a standing control gap rather than an isolated event.
Check three, prove a middle state. Choose a device you know is online and issue a command its current state does not permit. See which bucket the console files the result under. If there are only two buckets, Idle and NotNow are invisible in your reporting.
The console says online, so the device is controllable. Online reads the check-in clock, which lags by up to one polling interval, and execution additionally requires the device to reconnect and pull the command. A unit that checked in ninety minutes ago may now be out of coverage, powered down or in low-power mode. Acknowledgement is what demonstrates control; online is only a hint.
No acknowledgement means the command did not run. This fails in the opposite direction. A missing acknowledgement has two possible causes: the device did not execute, or it executed and the result was lost on the way back or during ingest. Reconciling by CommandUUID against the original command, and storing execution time and ingest time as separate columns, is what separates the two.
A batch click sends everything. One click becomes one command per device, and each of those has to clear all four dependencies independently. Click count is an operations-audit number. Acknowledgement count is an execution-audit number. They are not interchangeable.
Unsupervised devices and user enrolment. A device that is not supervised, or that enrolled through user enrolment rather than automated enrolment, does not have the same command surface. Its acknowledgements will keep returning states that mean unsupported or not permitted. The right response is to confirm enrolment mode and supervision state before doing anything about the execution ratio; retrying will not change what the device is permitted to do.
Offline fallback has a window, not an infinite horizon. Queued commands expire, and a device that has been switched off and resold is not going to acknowledge anything no matter how long it waits. Once a unit crosses your offline threshold, it stops being a management problem and becomes a recovery problem: location, evidence and next steps, not more queueing.
Treat 95 per cent as the working line and route the unacknowledged list to a human below it rather than relying on automatic retry. Tiered fleets should set a higher line for the high-exposure tier.
There is no universal value. Start with a tiered model such as 6, 24 and 72 hours, run it for a month, then tune against two metrics: the share of units with no acknowledgement, and the subscriber complaint rate. Do not pick one number for the whole fleet.
Long enough to cover the contract term plus the period in which a dispute can be raised, and long enough that a review a year later can still find what happened. Retention is only useful if the records are searchable both by serial number and by CommandUUID.
Yes, but avoid the hours when devices are least likely to be reachable. Overnight low-battery shutdowns and Wi-Fi drops concentrate acknowledgements into the following morning, which makes execution ratios look worse than they are and delays every downstream decision.
They are business records. Their usefulness as evidence depends on whether they can show who did what to which device, when, with what result, and that the record has not been altered since. That reduces to three properties: a CommandUUID that ties the result to the original command, an execution time that can be recovered, and a log that is append-only. Missing any one of them, the row is just a log line.
LuckyMDM is a device asset management platform from Sichuan Starlight Network LLC, built for handset rental, instalment and subscription operators, covering device control, pre-contract risk screening and post-contract performance.
For operators running a subscription fleet, the difference between a management layer and an accounting layer shows up in exactly this place: whether a batch of commands can be reconciled line by line, or only described in aggregate.
LuckyMDM registers every command against its CommandUUID and the status the device returned, reports an execution ratio of acknowledgements to targeted units when a batch closes, and generates a worklist for serials that returned nothing. Click count is never used as the measure of what happened.