Device Check In iOS (not checking in)

[ChrisGeorgeChri]

I seem to be having an issue with my iOS devices not checking in, as now 98% of the devices have fallen into the16-30 Day 'last seen' category. It seems to only be for iOS, as all of my Android devices are up to date in the console. I opened a ticket with support and the official answer I got was that the Agent application needs to always be running in the background for the console and the device to sync. My past experience has been that this is not the case as I never had my AW app running on my device and my device would check in so it never fell out of that 0-3 'last seen breakdown' in the console.

I have a feeling this is related to the Agent version (5.3) and my console version 8.1.5.0. It seems like the devices stopped checking in right around the time Agent 5.3 came to the app store.

Is anybody else seeing this issue with iOS devices only?

Thanks!

[valenciaj]

Hello Jacques P.
This is useful information, the encryption protocols. It wasn't my issue, however, we are in the process of disabling protocols (IIS crypto). Where did you find those protocols that Apple Supports? I would need to provide that documentation in order to keep some of the protocols.

[DimitrijPrudkij]

we have on-prem 2011 same issue, have somebody solution ?

after update from 2008 to 2011

[WesleyVanHouten]

There are a few causes of this error

As mentioned one is the encryption protocols if you ran iiscrypto and set best practice it breaks airwatch.

Apple has their own version of best practice protocols  which doesn't match up with the industry. 

Second is if you renewed your APN and the thumbprint changes, all devices with the old thumbprint will be locked out. 2 options try to renew the APN to get the old thumbprint back, or re-enroll. Getting the old thumbprint back may not fix the issue.  

The real fun one is if you forget to renew your VPP and your APN expires around the same time devices will just stop responding all together and you'll just need to e-enroll them, 

[DimitrijPrudkij]

Hi.

I install this two KB´s 

KB4601051

KB4601318

and after that we have no communication with all iOS devices.

And here is solution from VMware:

https://kb.vmware.com/s/article/82294

My environment was 2011.05. this is a reason why all devices are not communicated with device server. After that I patch it to version 16. All devices sync fine but at the moment we can't delete our device anymore from console. We can do it only over API.

[elanaalex]

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 and 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. Also, check below settings 

1. An APNs certificate has become invalid
2. A network restriction is blocking device communication
3. AirWatch Services are not properly running
4. Database performance issues

Additionally, please ensure there is no network issue blocking the devices from communicating with AirWatch.  

• TCP port 5223: For communicating with Apple Push Notification services (APNs)

• TCP port 2195: For sending notifications to APNs

• TCP port 2196: For the APNs feedback service

• TCP port 443: For a fallback on Wi-Fi only, when devices can't reach APNs on port 5223

• The APNs servers use load balancing, so your devices won't always connect to the same public IP address for notifications. It's best to allow access to these ports on the entire 17.0.0.0/8 address block