Configuration Profiles not applying

[Tse]

We're experiencing an issue with Configuration Profiles not applying consistently. I'm testing one configuration profile, which are contained in a Smart Group to two OS X Clients. According to inventory, they are set to apply, and one client receives and applies them without issues, the other one, remains static with only the MDM Profile installed.

I've tried removing them offending client from inventory, performing an erase and install of OS X, and re-enrolling them through the QuickAdd package, but unfortunately to the same result.

Examining /var/log/jamf.log on the client was uneventful.

JAMFSoftwareServer.log was a bit more forthcoming, but brings me no closer to a solution. 2014-06-06 15:10:32,491 [WARN ] [Tomcat-518 ] [MdmApnsConnectionHelper ] - Unable to send check-in notification to COMPUTER ID: 14 with token: ""
2014-06-06 15:17:04,234 [ERROR] [Tomcat-505 ] [MDMRequestAction ] - Device cert doesn't match
2014-06-06 15:17:04,234 [ERROR] [Tomcat-505 ] [MDMController ] - Error processing request action:StatusUpdate, CmdUUID:null, SigVerified: false. Returning 500.
2014-06-06 15:50:49,403 [ERROR] [Tomcat-526 ] [MDMRequestAction ] - Device cert doesn't match
2014-06-06 15:50:49,403 [ERROR] [Tomcat-526 ] [MDMController ] - Error processing request action:StatusUpdate, CmdUUID:null, SigVerified: false. Returning 500.

it seems push notifications and device certificates aren't working properly, so the client doesn't pull them down.

I would've thought removing the device from inventory, and enrolling it clean would have resolved the issue, unfortunately has not been the case.

[matt_jamison]

I've seen this same issue on my end. What version of MySQL are you running?

[bentoms]

The OSX client has not received it's token from Apple.

TCP Port 443 to 17.0.0.0/8 need to be open along with 2195, 2196 & 5223

[were_wulff]

@Tse

In addition to @bentoms ' suggestion, "[MDMRequestAction ] - Device cert doesn't match" is pretty cut and dry.
Somewhere, a cert on a device doesn't match the cert in the JSS.

Usually it's the SSL cert as, if foggy memory on a Monday morning serves, an APN cert mismatch gives a slightly different error.

Still, it's worth double checking the APN cert on the client and compare the Topic on that to the Topic of the APN cert in the JSS.

I'd be surprised if there was a mismatch there as you said you've re-enrolled the device already, which should take care of APN cert mismatches.

Have you gone through yet and regenerated the Tomcat certificate?

If you're using the built in certificate authority (the Issuer will say "JSS Built-in Certificate Authority" somewhere if it is), we can just go to System Settings >> Apache Tomcat Settings >> Click Next until Next turns into Done, and then restart Tomcat.
Any QuickAdd packages in use will need to be re-made after doing this.
If you've done the above in the past, but didn't re-make the QuickAdd packages, it could be part of why you're getting "Device cert doesn't match" errors.

In cases like this, we usually recommend renewing your APN cert along with regenerating the Tomcat cert just to cover both bases.

CmdUUID:null, SigVerified: false. Returning 500 is usually an unmanaged OS X device that has certificates that the JSS isn't able to read or parse correctly, but to verify that, your Technical Account Manager would need a full debug log so they could grab the computer ID/UUID associated with that error and find the record in your JSS.
It's something we'd want to verify as it can, very occasionally, be a computer that's supposed to be managed that just has a bad cert on it.

If you haven't already, you may want to reach out to your Technical Account Manager to get a case going.

Thanks!

Amanda Wulff
JAMF Software Support