Devices showing ' Pending compliance check' after enrollment

[EricPlent]

I have noticed recently that a small number of devices enrolling in our AirWatch environment (Dedicated SaaS, 9.1.4.0, devices are all iOS) are showing a compliance status of ' Pending compliance check' . I have asked the users to open the Agent (which would normally clear this issue), but in some instances the user is being prompted to begin the enrollment process over again even though the device shows fully enrolled. Additionally, there is a single item listed in Commands which remains stuck at ' Queued'  regardless of how often the device checks in to the console. I have seen this happen on iOS 10.x and 11.x devices so it does not appear to be related to the recent iOS 11 release. Any suggestions on what I can do through the console to clear this and force the compliance check to execute on the devices? The vast majority of enrollments are not seeing this issue, so it does not seem to be a systemic issue (e.g., problem with profiles, etc).

[PATRICKBREZNAK]

I just went through this and the resolution in my case was that we needed to update the APN certificate with apple. Go to Settings ? Device & Users ? APNs for MDM and see if the APN cert is outdated. If so follow the process to renew. Hope this helps.

[EricPlent]

It's not the APNs for MDM cert - it's valid. The issue I described is only impacting a subset of our devices, with the majority working without issue. It seems so far that the only method of resolving this is to have the user open the Agent, tap the Compliance tab and select ' Sync device' . They will usually be prompted for enrollment as of it did not complete originally even though the device is calling in to the console on a regular basis. Once they go through the steps again the compliance status problem is resolved. Cumbersome, but it does work.

[RedenBonita]

Are the iOS devices DEP? I've seen this happen on DEP devices where the agent app doesn't recognize the device as enrolled and will go through enrollment process again and will fail as the device is already enrolled. We found out that the agent app installed is ' not managed'  app why it is not fetching the enrollment status of the device. Turns out that users did a restore from backup and all apps got reinstalled making the agent app as ' not managed' . So I assume that since the Agent app is not managed then it will not send device sample to the console. Issue was resolved when user uninstalled Agent app and downloaded the app from app catalog making it ' managed' . When user opens the Agent app it detects the device as enrolled and sending device sample to the console. Another way is to push Agent app and make sure ' Make app MDM managed if user installed'  is enabled.

[MUHAMMADLUTFIMO]

Same here. Happens to a small group of ours newly enrolling users as well. Our current solution is basically the same :-

1) Delete the MDM profile (if any)
2) Uninstall Agent
3) Reboot device
4) Ensure device is on 3G/4G instead of WIFI
5) Go through enrollment process again

But there is no answers why these devices still keep getting stuck at Pending Compliance Check. When I try to Run Compliance on these devices, says Samples Not Received to Run Compliance and all other commands get stuck pending when pushed to the device (ie Query, Lock command).

[JacquesPerrolle]

This problem has been plaguing us for quite some time and I FINALLY have a device exhibiting this behavior, newly enrolled, and it's in our Test Environment so we can throw all sorts of horrible ideas at the environment and iPhone. More to come.

EDIT1: On the device there are 2 pending compliance checks, one for blacklisted apps (while we have that compliance policy, there are no apps that are blacklisted) and one to check and see if the device has Agent installed.  Obviously it does.  Both of them say ' Samples Not Received To Run Compliance'  in the Console and ' Compliance Status is currently being evaluated. Please check back later.'  on the device (in Agent > Status > Compliant > policies with blue question marks)

The console also shows that the device is missing 3 MDM profiles.  It definitely has the initial MDM profile, but I verified that it is indeed missing the other 2 profiles that it should have.  Of course, you cannot push those because there's compliance check problemsInstall Profile failed, Profile is blocked by a compliance violation.' ... which are likely because it doesn't have those policies.  Chicken & Egg.  So dumb.

[JacquesPerrolle]

TEST - Enterprise Wipe from the Console and have the user re-enroll.  In this case, the user swore that he had enrolled again yesterday but had not. So he thinks that it's possible that he started the process but never finished and then finished it today. 

DID NOT WORK.  User re-enrolled and the exact same problem is there.  Pending compliance checks for blacklisted apps and whether the AW Agent is there or not.  And the installed MDM profile is still missing 2 pieces.

[JacquesPerrolle]

TEST - I followed MUHAMMAD LUTFI M.'s suggestion above.  The user re-enrolled.  EXACT same problem. DID NOT WORK.

[JacquesPerrolle]

TEST - Simply delete the device from the Console.  This will forcibly unenroll the device.  The user re-enrolled and now it works.  @*^&*#% = I thought that I had deleted the device from the Console and I sent a device wipe instead.  THEN I deleted the device from the Console.  So while the device now checks in, I don't know what the path of least resistance was.  I think we all already knew that a factory reset and console delete would work, but the chances of us telling a user to completely wipe their phone and them being OK with it is pretty darned low. 

Sorry folks!

[JochenBoekenhei]

Go and check the TLS Settings of your IIS Installation.
I used IISCrypto (https://www.nartac.com/Products/IISCrypto) to improve the rating. I use the best practice setting without trible DES 168.

A reboot and the profiles and apps are rolled out.

[SandroSchefer]

We are facing the same issue since yesterday. APN is not expired, best practice setting with IISCrypto applied. Still not working. New devices cannot perform the compliance check for the IOS version. We alkso checked what MUHAMMAD suggested.
Any ideas what else to check ?

[SandroSchefer]

Update: We disabled all the compliance checks (which were ' pending'  all the time) but no changes. We noticed that various security information cannot be checked properly by the console. I think thats the reason why profiles are not getting installed and not the failing/pending compliance checks itself.
Maybe the newest App version is causing this issue during enrollment and while communicating with console etc.

[LukeDC]

Also good to check you have SSL pinning configured properly.

[SandroSchefer]

I have checked the SSL Pinning. Getting the follwing message when trying to sync ' An error has occurred. This error has automatically been saved for further analysis. Please contact technical support.'  to note status is ' not synchronized' . Even after disabling SSL pinning we still got problems with some security informations (Passcode status unknown, Data protection status unknown...).
We see some exception logs in the event viewer of the device server. (/System.Web.HttpException: The controller for path '/DeviceManagement/Scripts/underscore-min.js' was not found or does not implement IController.).
I checked the mentioned file but it seems to be ok. I compared it with some saved copies from earlier.
Any other ideas what to check Mr. Sharkey?

[Stansfield]

One complication for SSL pinning it is fundamental to the design of SSL pinning that turning it off cannot disable it for devices that already have a pinned connection unless on some implementations they make a pinned connection and are told to disable it but you cannot just turn off pinning and resume connecting to devices with a bad pinned connection.  AirWatch did their implementation a little weirdly so they have a more graceful failure path.  You may try enrolling a device with it now off and see if it works, also does the agent sync?

Also check under global>admin or install and cloud settings that you have the account signed into with a proper account (check test works they broke some account types a while back) and have the server pinned

[Slanteyes]

Anyone have any updates on this issue,  we are experiencing the same as above.  I did discover that after our staging team makes a device and ships it out we see one command is queued ' install profile Target'  com.air-watch.agent' ' . If we see this command queued we cannot seem to control the device and if the users open the agent in the field it un-enrolls the device, But if we get our staging team to open the agent at our staging location ' open network'  then that command installs and we keep control of the device when it hits the field.
This all started just recently and we cannot find any commonality other then that command is queued.  Agent version 5.7.1 iOS devices 10.2.6 - 11.4. ssl pinning is off AW version 9.2.2.5. All services are running and server has been rebooted, this only affects a handful of devices

[MikeFreestone]

We have seen these issues with IOS for many years.  Enrolling on 4g rather than WiFi does seem to help.
Multiple Enterprise wipes and manual removal of the MDM policy if also often required.

[RicardoPachecoR]

Over time I have seen that an iOS device with a recently applied iOS version, is sometimes flagged as non-compliant. Not all users have 'Auto-Updates' enabled. When I ask them to update the app version, that seems to correct the compliance flag.

Starting with iOS version 9, AirWatch started to contact all customer to make sure that the 'Compromised Protection' was not enabled.
(Message Tip for this setting: Enable to automatically perform an Enterprise Wipe on compromised devices.)

If I had not disabled this setting, iOS users can potentially have their phones un-enrolled after they apply an iOS Update. I know that the compromised status doesn't get flagged all of the time, but it still does from time to time. (I was told that AW had fixed that problem.)

[JacquesPerrolle]

What I started doing was using Tags to identify users who were in this particular predicament.  In most cases, the users simply had to open the Hub app and answer the VMware EULA questions... in some cases they had to do a manual sync. But this has (so far) taken care of the issue for me.  At least, with those who bother to do it. I've reduced the number of 'pending' devices by about 45% so far. The majority of our devices are iOS, this has been less effective on the 2 Android devices that have had this issue so far.

I use a tag, and then an assignment group for that tag, and then a Compliance Policy for OS version greater than X (something ridiculously low), and then use Actions to mark them non-compliant and start sending emails with more info about 'Enrollment Issues' asking them to simply open the Hub app, manual sync, or install the Hub app (in some cases). After a day, I start push & sms & email blasting them to try and encourage them to comply. Once they are compliant, I have to remove the tag manually. To find the complaint ones I use an Advanced Filter to search for the tag, and then the Security filter for Not-Compromised.  Anything (iOS) that shows up there is someone who has opens Hub and made this go away.  I remove the tag and they're compliant and good to go.

Hope this helps.