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.
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.
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).
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.
