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.
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.
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 ?
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.)
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.