A few of my iOS devices never (agentlessly) check-in with MobiControl. How can I troubleshoot these devices?

A few of my iOS devices never (agentlessly) check-in with MobiControl. How can I troubleshoot these devices?

If a device is not able to check-in agentlessly with MobiControl, it essentially means it cannot be managed.  It would be nice to have a troubleshooting procedure for this kind of scenario.

3 Answers

Order By:   Standard | Newest | Votes
Dean P | posted this 13 December 2017

We have devices which randomly wont check in and they get this error on the device:

 

iPad mdmd(CFNetwork)[1503] <Error>: NSURLConnection finished with error - code -1001

Do we know what kind of tuning needs to be done for these kind of errors? Or is this only available by support.

This has been a very informative post on the background of whats going on and troubleshooting steps. Thank-you!

  • 0
  • 0
Adil Katchi | posted this 14 December 2017

SOTI Support is the best resource to contact to help you with this issue, because some of the tuning parameters can have detrimental effects if not implemented correctly.

  • 0
  • 0
Adil Katchi | posted this 26 February 2018

It is important to understand that a device will only check-in agentlessly with MobiControl after:

  • MobiControl sends a message to Apple Push Notification Service (APNS) to request for the device to check-in. This is triggered either by a Scheduled Update or an administrator using the MobiControl Web Console.
  • After receiving this message from MobiControl, APNS asks the device to check-in with MobiControl at the URL specified in the Management Profile installed on the device.

 

First, ensure that the device can communicate with MobiControl by browsing to the URL:

 

https://<DMA>/mobicontrol/enroll/

 

where <DMA> is the Device Management Address as specified in MobiControl Administration Utility, which must match the URL specified in the Management Profile installed on the device.  If the device cannot reach the enrollment endpoint, investigate WiFi, VPN, and restrictions settings that may be restricting the device from accessing MobiControl.

 

If the device can connect to MobiControl, attach the device to a macOS device and launch the Console application.  Request the device to check-in and capture the console logs of the device. There should be some logs for the process [mdmd].  Look for any errors which might indicate failed attempts by the device to check-in to MobiControl.  If the error indicates a timeout (eg. code: -1001), tuning of MobiControl is likely required. Please consult SOTI Support on how to do this.  If the device contains a large number of installed applications, please let SOTI Support know as it will be helpful to determine the most effective performance tuning parameter.

 

If there are no errors in the console logs, then it is likely that the device isn't checking in with MobiControl, because it hasn't been instructed by APNS to do so.  When a device receives a push notification, an entry for the [mdmd] process will exist in the console log stating, "Received push notification."  Once you have confirmed that such an entry does not exist, we need to determine whether MobiControl is able to send a message to APNS to request for a device to check-in using the following steps:

  • In MCDeplSrv.exe.config
    • set the General category logging mode to Verbose (ie. <add name="General" value="Verbose"/>)
    • set the APNS category logging mode to Verbose (ie. <add name="APNS" value="Verbose"/>)

 

  • Restart the Deployment Server service.
  • Request a device check-in.
  • As MobiControl prepares to send a message to APNS to ask the device to check in, in the DSE log files, under the General category, you'll find an entry for the device stating, "NNN Device {0} push notification status requested. PushMagic: {1} Token: [{2}]", where
    • 0 is the device ID
    • 1 is the device's push magic token
    • 2 is the device's token

 

  • If the message was sent successfully to APNS, in the DSE log files, under the APNS category, you'll find an entry for the device stating, "### APNS for device token {0} sent.", where 0 is the device's token that matches the one found in the previous step.
  • If the message was not successfully sent to APNS, in the DSE log files, under the APNS category, there will be an entry indicating why it couldn't send it.
  • If APNS could not deliver the message to the device, in the DSE log files, under the APNS category, you'll find an entry for the device, ""Cleared tokens for device {0} because the feedback service reported on {1} that the token for the device enrolled on {2} and last checked in on {3} is invalid.",
    • 0 is the device ID
    • 1 is the timestamp when this failure occurred on APNS
    • 2 is the date & time the device was enrolled
    • 3 is the date & time the device last checked in.

 

If the DSE log files indicate that APNS could not deliver the message to the device due to an invalid token, it suggests that the device updated its token but has not provided MobiControl with the updated token yet.  It should do so the next time it is able to connect to MobiControl.  If the device does not report the new token and/or does not check-in within 7 days, it will be automatically un-enrolled from MobiControl, and so the device will need to be re-enrolled.

 

If the DSE log files indicate that MobiControl is successfully able to send a message to APNS to request for a device to check-in and APNS does not report any errors in delivering the message to the device and the device console logs do not report any errors, unfortunately we have exhausted all our troubleshooting capabilities.  The customer is encouraged to open an issue with Apple to investigate this in more detail.  Sometimes a factory reset of the device will resolve the issue.

 

  • 0
  • 0
Feedback