If the MDM server returns 503 or 429 HTTP response code, along with the Retry-After header specifying seconds or date to contact later, does the MDM client on iOS or macOS respect that? We’ve tried it locally but the retry does not happen/ seem to be respected. MDM client automatically retries when connection is disrupted. But sometimes it may be suitable to send a retry-after header when the MDM server is experiencing unusual loads.
Do any of you guys have a clue?
I have tested that as well, but I cannot confirm that it works. It would have been an interesting use case. I think you can only trigger an MDM client request via a push notification. This is also stated in the MDM protocol reference:
The device polls only in response to a push notification; it does not poll the server immediately after installation.
The server must send a push notification to the device to begin a transaction.
1 Like
Hi,
Also to add some information that we had from Apple Guys when they came on our site:
- The Device do his checking at least once a day
- After a restart, the device will always try to contact the MDM in order to know if the device has a command to do
- After changing a network, the device will always try to contact the MDM
As @petar said, the device need a push notification to start a transaction. This notification is available for 21 days maximum if no explicite value of days has been set to in the notification.
2 Likes
Hello @Dara
The 3 statements you mentioned, these MDM check-ins happen without an MDM push notification also?
Hi @zmahesh
for those 3 statements, normaly Yes. I say normaly because sometime informations that we have from Apple Support guys change 
…i don’t know if there are other cases
Something usefull, if you are an Airwatch administrator, you can see on the database the information while the device has made his last check-in to the MDM by using the Apple MDM Protocol (.
The SQL request is that one and it will give the “LastMDMReceived”:
select *
from dbo.AppleDEviceEx
1 Like