How to troubleshoot device check-in issues

How to troubleshoot device check-in issues

Once a device is enrolled in AirWatch, the AirWatch Scheduler will ensure that the device checks into the Admin Console periodically to ensure that all information is up-to-date.  During this check in process, each device will supply up-to-date information to AirWatch, including data such as a list of all applications, certificates, or profiles installed on a device, the latest security information on a device (such as password complexity or if it is encrypted), or information such as GPS data points or telecom data usage for certain device types.  For iOS devices, the check-in rate varies for each data type. For on-premise environments, this setting is configurable with the MDM Sample Schedule.  For other device types, this is configurable in the AirWatch Admin Console under Settings -> Devices & Users -> {Platform} -> Agent Settings for the various device types.  Note that some of these settings are non-configurable on SaaS environments.

However, an environment may experience issues where devices are not checking in according to the configured schedule.  In these cases, the AirWatch Admin Console may not have the most up-to-date information on these devices, and certain configured compliance checks may ultimately fail.  This article discusses some common reasons for devices to not check-in properly, and how to resolve these issues if they occur.

An APNs certificate has become invalid

iOS devices require that a valid APNs certificate is configured in the AirWatch Admin Console for any remote commands to be accepted by the device.  This includes the automated check-in commands that are initiated through the AirWatch Scheduler.  APNs certificates must be renewed yearly in order to stay active, and if a certificate configured in the AirWatch Admin Console expires, then communication with any enrolled device will cease until it is properly renewed.  For more information, see the Generating and Renewing an APNs Certificate article.

A network restriction is blocking device communication

Depending on the device type and specific communication protocol used, a device may stop communicating with the AirWatch Admin Console if network restrictions prevent it from reaching the appropriate endpoints.  In many cases, this requires that a device is able to communicate both with the AirWatch Device Services Server, as well as an appropriate Push Notification server.  For example, iOS devices must be able to communicate with an APNs server on port 5223, and also with the AirWatch Device Services Server on port 443 (by default).  If either of these communication steps fail, then devices will not automatically check into the console.  For more information on the APNs communication flow, see the article here.  Additionally, commands initiated from the AirWatch Admin Console (such as a device query), require that the AirWatch Console Server is able to communicate to the APNs server as well. However, this communication is required over ports 2195 and 2196.

For more information of the requirements for AirWatch to properly communicate with different device types, view the Pre-Installation Requirement Worksheet here.  Depending on the specific deployment model and use cases utilized, the specific requirements may vary from deployment to deployment.

AirWatch Services are not properly running

The AirWatch Admin Console includes a number of Windows Services to handle background tasks, including processing the data samples a device sends when checking in.  If devices do not appear to be checking-in from the Device Management Dashboard in the AirWatch Admin Console, it is possible that the devices are actually reaching the server correctly but the AirWatch Services are not properly processing the data samples.  Windows Services can be access from the server by navigating to Computer Management -> Services and Applications -> Services.  All AirWatch services will begin with the word "AirWatch."

Additionally, the AirWatch Services will interface with the certain Microsoft Message Queues (MSMQs) in order to process all data samples from devices.  These MSMQs are located under Computer Management -> Services and Applications -> Message Queues -> Private Queues.  By navigating to this menu on any AirWatch server, you can validate the amount of messages currently in any of the queues.  In a perfectly functioning system, the amount of current messages in all queues should be zero, which indicates that messages are being processed as quickly as they are being created.  If you do identify that any message queue has more than zero messages, then it indicates that there is a backlog of messages to process through, and can indicate poor performance.

If a backlog exists, validate whether any AirWatch Services are currently not running.  In particular, the AirWatch Messaging Service is critical for all messages being sent to devices.  Even if services are currently running, it can be a good idea to restart the AirWatch Services if a backlog is experienced just in case an error has occurred when attempting to parse a particular data sample.  After restarting, the services may then continue to properly handle all incoming samples.

Database performance issues

The final stage to handle data samples from devices is to store the information in the AirWatch database.  Thus, if devices are not checking in properly but everything else looks to be working properly, a database performance issue may be causing the bottleneck.  First, investigate whether the database server itself is experiencing any performance issues.  Check the server CPU and memory utilization to ensure that the server has been sized appropriately. Additionally, ensure that the database has been indexed properly and that no scheduled maintenance jobs have failed.


Have more questions? Submit a request


Article is closed for comments.