MDM push doesn't response without any error. How can we avoid it?

Our MDM customers often claim MDM push is not delivered to device and cannot manage devices via MDM.

  • TokenUpdate is not notified from the device on our MDM checkin server.
  • APNs server response is 200 OK (successful) with the device token.
  • MDM push is actually not delivered on device.

We are really struggling to handle the claim because it is probably caused by iOS behavior, and AppleCare OS support doesn't help investigation about the issue.

  • How can we investigate the reason why the push is not delivered?
  • How can we know the current token value of the managed device?
    • Reinstalling the MDM configuration profile is a way to know current MDM push token (it triggers TokenUpdate checkin command)
    • Any other way to trigger TokenUpdate request on the device side?

Diagnosing failed pushes

There are many possible causes for a iPhone, iPad or Apple TV to not contact the MDM server after an attempted push returns 200 OK:

  • The device is unable to contact Apple's APNS servers or the MDM server over the network.
  • The device unenrolled, and the one-time attempt of the device to send the CheckOut message failed
  • The device was wiped. Depending on how the wipe was performed, it does not allow for a CheckOut. It's also possible that a CheckOut was attempted but failed.
  • The MDM server is using the wrong push topic. The push topic is part of the push cert the MDM server uses. If the push cert was replaced without renewing, that generates a new push topic in the certificate, which cannot be used to send pushes to devices that were using the old push topic.
  • The MDM server is using the wrong push token. The push token only changes due to a backup and restore to the same device, or in the event of a bug in the OS (and I am not currently aware of any such bugs). Whenever the topic changes, the device automatically schedules a TokenUpdate and will repeat it until it succeeds.
  • The MDM server is using the wrong push magic. The push magic changes each time the device unenrolls and re-enrolls. This has caused issues in the past with some MDM servers: if the unenrollment had an unsuccessful CheckOut, the MDM server ended up with records of two different enrollments for the same device, and then attempted to send pushes using the old, obsolete push magic. In this case there will be a console log event from the mdmd process, "Rejecting MDM push dictionary because it does not have the right magic string." When the device receives a push with the wrong push magic it can trigger a self-healing mechanism I'll describe below.
  • The device just enrolled and the MDM server attempts a push extremely quickly after enrollment without retrying after a sufficient delay. This is because there is a brief race condition between the device telling Apple's APNS servers that it is listening for pushes and the MDM server attempting to send a push. This race is very brief. In nearly all cases it is not possible for the MDM server to send the push first. I've seen this race condition last as long as 0.7 seconds. MDM servers should retry a push if the device does not contact the MDM server within several seconds.

Push magic self-healing

When a device receives a push with everything correct but the push magic, it records the time it arrived, but does not contact the MDM server. If over the next 25 hours it receives any pushes with the correct push magic, it resets the recorded time. When at least 25 hours after the recorded time the device receives another push with everything correct but the push magic, it attempts a token update and contacts the MDM server for commands. So all together this self-healing mechanism can help an MDM server recover if it has the incorrect push magic. However it doesn't help with an incorrect push topic or push token, since those never arrive at the device. There's no supported way for a user to trigger a token update, other than unenrolling and re-enrolling, or backup, wipe, and restore to the same device. Neither of these are recommended for diagnosing or repairing an MDM push issue because they are lengthy and may lead to data loss.

Determining correct values

If you take a sysdiagnose from an affected device, you can gather your own diagnostic information from it. A sysdiagnose is a compressed archive of files. Decompress it on a Mac, open Terminal, navigate to the root directory within the compressed archive, and use the following commands:

Push Topic

for a in `find . -name \*.stub`; do plutil -p $a | grep Topic; done

The push topic is also visible in Settings > General > VPN & Device Management > (MDM profile) > More Details > (MDM payload) > Topic

Push Magic

plutil -p logs/MCState/Shared/MDM.plist | grep PushMagic

Push Token This value is not provided directly, but you can get the SHA256 hash of the push token:

/usr/libexec/PlistBuddy -c "Print LastPushTokenHash" logs/MCState/Shared/MDM.plist | xxd -l 32 -ps -c 32 

Doing your own diagnosis of log events on devices is difficult because much of the useful information is absent or redacted unless you have the appropriate logging profiles installed (see below).

Submitting feedback

Of course, there's always the possibility of a bug in Apple's APNS servers or in the device OSes. If you can rule out the above causes, please submit feedback to Apple. Please provide the push topic, push token and push magic used, the time of failed pushes, and the response from the APNS server. It's particularly helpful to provide the time when pushes started failing, not just a recent failed push. Please also install the Managed Configuration and APNS logging profiles on the device, reproduce the issue, and take a sysdiagnose and submit that. It's important to collect this information within a day or two of the issue starting to occur.

@Systems Engineer Thank you for you quick reply. I understand how to investigate the issue at first.

However no way to print raw MDM push token value? Even after we got the SHA256 value of the MDM push token different from the one the MDM server stores, it is not so useful for us. If we could know the latest raw token value from sysdiagnose or somewhere, we can recover the push error by updating the token value on MDM server DB, and customers' claim can be reduced.

Thank you.

I have the same problem, how to get the MDM raw push token ? T hank you

MDM push doesn't response without any error. How can we avoid it?
 
 
Q