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!

[jarodyak]

We are having this same issue right now.  I will report back the solution once we get a response from AW support.

[RonaldMckerral]

Have you received your answer Jarod? We are seeing something like this and in our environment, we need the agent app hidden or students would be deleting it

[AkihiroSuzuki]

Same Issue . Any news ?

[RuddhiBiswal]

Hey jarod we are also facing the same issue for iPad Air2 .Did you get any response for this

[ChristineDratva]

Someone got an update on the issue ?
I think the Agent 5.7 has problems with the iOS11.2 and below. Once 11.4.x is installed it seems to work fine.
Anyone noticed the same ??

[Sean_Kane]

Curious, has anyone found a fix for this?

[ChristineDratva]

Hi,
I've seen the same thing. Just couldn't tell which Agent version is causing the problem, since I'm automatically pushing the updates. Then console then only shows that the new version is being pushed, but doesn't show the version of the agent.
I'm update the devices (iOS12) now, and the check back in.
Sometimes it helps to reinstall the agent on the device or just start the Agent.

[GeraldHubbard]

Hi.  If you're on premise, this may help.  I was able to resolve this by restarting the Device Scheduler service on my console server.

Good luck!

[ChristineDratva]

We're not on premises ... 😕

[JacquesPerrolle]

Fully on-prem.
I just had 47% of my iOS devices get triggered as non-compliant by a 'not seen in 15 days' compliance policy.  And that makes them all get kicked off the network.  Joy.  So, is this because of the ' Hub'  app update?  Had the APNS for Apps script run yesterday.  Had many server vulnerabilities mitigated yesterday where there were no issues found in Test environment when I did this.  Patched server OS too.
So for the moment I've had to turn off the compliance policy.

Update: my own device got the Hub (Agent) app update last night and I verified that it was connected.  I've been using my device since 3:30AM PST, and yet AirWatch says my device hasn't been seen for 13 hours.  Just checked, Hub app is literally open on my device right now.

[ms93]

Facing this issue here too. We are on prem v1810.
Going to restart the device scheduler in the next maintenance window, as Gerald mentioned.

[Sean_Kane]

Hi Everyone, just a followup, I did open a ticket with AirWatch support on this topic. They told me that the AirWatch/Hub agent or any VMware AirWatch app needs to be running in the background in order to check in with the console. Their suggestion to fix this issue is to create a compliance policy that notifies the end users to open the agent app if they haven't checked into AW in a specific amount of time.
The only issue I see with this design is the device needs to check in with AirWatch to receive the policy. So, until that happens the ones that are not checking in will not know to receive the reminder to check in. Kind of a chicken-egg situation.
See this document for more details, specifically the information in the third paragraph: https://support.workspaceone.com/solutions/SOL-1472
I will be implementing the Compliance Policy soon!

Sean

[ChrisGeorgeChri]

Sean, I had the same reply from AW and I struggled with that 'solution' as I never have my agent as a running app. My solution was to work with my Firewall team and make sure my device server could get to all of the pertinent URLs/Addresses and that the Device and DB server were also fully able to communicate.. In fact, I just verified that my app is not running on my iPhone and my last check in was 38 minutes ago. Of course YMMV, but my answer was getting my firewall right.

[Sean_Kane]

Chris, can you elaborate? I literally just ran the install of 9.3.0.25 yesterday and before I did that I ran the Workspace One Validation tool. It confirmed that all required ports and URLS were accessible. Which ports and URL's were inaccessible that you made available?

Thanks in advance for your help,
Sean

[jafullersr]

We're seeing a subset of iOS devices not receiving APNS.  We're on-premises running v.9.5.x.  I don't think I've ever had support tell us that we need to run the agent/hub app on the devices for them to receive APNS.  That's new to me.  In fact, the Apple MDM Protocol doesn't require that for APNS to work, so in my mind I'm questioning your support agent.  As long as the management binding is in place, the silent APNS messages should still function.
From the MDM Protocol Reference: ' When the MDM payload is installed, the device initiates communication with the check-in server. The device
validates the TLS certificate of the server, then uses the identity specified in its MDM payload as the client
authentication certificate for the connection.'

[JacquesPerrolle]

Update on my issue:

Wasn't hub.  Wasn't AirWatch.  Wasn't Apple.  Wasn't the devices.  Was us!

Turned out, we'd disabled some encryption protocols that didn't meet NIST recommendation on our on-prem servers. That is what totally broke APNS for us. The cipher suites that Apple supports and the version of Windows server we're running supports that are both NIST recommended didn't jive. Once we figured that out, which was difficult since no logs were ever really indicative of that being a problem (kind of... from our end, APNS request sent... silence and darkness from Apple.), we restored the protocols and everything started working again.

Apple supports:

TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A

Hope this helps someone!

[JesperSimonsen]

Same issue.
On prem. installation.
4000 iOS devices not checking in in the past 15 days.
Restarting the AirWatch Device Scheduler service helped immediately

[SeanMuldowney]

We are seeing the same thing with on prem. installation only fix appears to be stopping and starting  the AW Device Scheduler service.  But we  need to do this once or twice a week. This is only with iPhone's our Androids keep checking in. AW support has had us make some changes to our DB server that are best practices but this has not helped Check of DB comes back good. Devices do check in if you do a query to specific device or click send data from hub app on device. Has anyone come across this issue started since we updated from version 9.3 to 1811.

[KarolFryga]

Hello, somone have the same problem with ' Last seen'  in version 1903?

[maziboss]

John A.
Yes, we are struggling with this issue in version 1903 (on premises).
I created a ticket and VMware support told me that is normal and end user need to open intelligent hub... No comment. They should be ashamed.

At this moment we restarted ' Airwatch device scheduler'  services and looks that devices are slowly communicating with the console. I will update my post soon.