MDM Capable Showing "No"

GabeShack
Valued Contributor III

Hey all,
We just noticed an issue where clients who have an MDM profile and are running 10.7.5 or later are showing up in the JSS as MDM Capable No.
It does't seem to affect the machine as profile management will continue to queue up any changes to be made but then I also can't send blank push notifications to help the process along since it thinks its not MDM capable any longer. Not sure the cause yet and I have an open ticket, but wanted to ask if anyone else has seen this?
Thanks!

Gabe Shackney
Princeton Public Schools

Gabe Shackney
Princeton Public Schools
14 REPLIES 14

NickKoval
Contributor
Contributor

MDM enrollment is part of the management framework. If you type sudo jamf manage -verbose, do you see the computer attempt to enroll in MDM? If you do, check System Preferences for the MDM Profile. If the profile is there try sudo jamf recon and submit a new inventory report. If the profile isn't there, check console to see what failed in the enrollment process.

If you don't see the computer attempt enrollment, remove the MDM profile in system preferences and re-run the jamf manage command.

GabeShack
Valued Contributor III

The funny part is we do always see it enroll properly and do the management command correctly. Sometime later it seems to drop this portion of management and we can't seem to figure out why.
Gabe Shackney
Princeton Public Schools

Gabe Shackney
Princeton Public Schools

jalatman
New Contributor

Is port 2195 available from JSS to the outside world (Apple)? The other port you would need available on your network is 5223 for clients to speak with Apple.

GabeShack
Valued Contributor III

Yes these are both available. The issue isn't it connecting to the apn, but when looking on the computer details page in the jss reporting "MDM Capable: No" I can rerun the JAMF manage command and then it shows Yes again but seems to lose it again later. Most annoying.

Gabe Shackney
Princeton Public Schools

Gabe Shackney
Princeton Public Schools

jalatman
New Contributor

Sorry for the late reply Gabe. Are any of your clients using a proxy of some sort? Just checking all the bases to see where the communication hangup might be. Other thing to maybe check is your certificates. Are you using a self signed certificate or a third party certificate ( JSS >> Settings >> General Settings >> Server Configuration >> Web Certificate ). Is your Push Certificate valid or recently renewed?

jserapio
New Contributor

Hi Gabe,

Did you get this resolved? I seem to be running into this issue now. Do you happen to have a proxy?

GabeShack
Valued Contributor III

No proxy, but ended up renewing our built in SSL certificate and then issuing either a sudo jamf mdm or sudo jamf manage command to our clients and this seemed to fix it. Still unsure of the cause.

Gabe Shackney
Princeton Public Schools

Gabe Shackney
Princeton Public Schools

Hobbs155
Contributor

We had the same problem, this was due to our proxy doing SSL inspection, we turned it off for apple.com sites and it appears to now show up as "yes" still having major issues with config profiles on ML though.

Yam
New Contributor

I solved my problem by removing the old MDM Profile in system preferences, and re-enrolled the JSS again.

seabash
Contributor

We started seeing this on a small number of Macs at remote locations, but never on our corporate campus.

In our case, the afflicted Macs were on VLANs that blocked access to APNs over 5223. All these Macs had the MDM enrollment profile from our JSS (v9.65).

Since we also can't use MDM Capability as scope criteria, we decided to create an extension attribute. Basically, we're checking access to gateway.sandbox.push.apple.com 5223 and returning status.

#!/bin/bash
# Test whether Apple Push Notification (APN) service is accessible to Mac client
# A blocked status will prevent Macs getting or updating our MDM settings.

function MDMstatus ()
{
/usr/bin/expect <<EOD
set timeout 2
spawn nc -z gateway.sandbox.push.apple.com 5223
expect *"succeeded!"
EOD
}

reportMDMstatus=`/bin/echo "$(MDMstatus)"`
if [[ "$reportMDMstatus" == *"succeeded"* ]]; then
    /bin/echo "<result>Accessible</result>"
    exit 0
else
    /bin/echo "<result>Blocked</result>"
fi
exit 0

All disclaimers apply, but this may help others needing to test actual access to APNs.

michelm
New Contributor

Hey Guys,
I found the only solution that works:
1- delete the computer from jss.
2- reboot and open disk utility and erase the hard disk.
3- reinstall pure, clean OSX either from the web or from an OSX installer from Apple on a USB stick.
4- after installation is complete, run recon or quick add package or any way to enrol the machine into jss and now it should show up in jss MDM Capable= yes.

bmarks
Contributor II

Being MDM-capable requires a recovery partition. The above process may resolve some of these kinds of issues if the previous volume had no Recovery HD.

CasperSally
Valued Contributor II

@bmarks - not sure this is true. our student workstations don't have a recovery partition and are all mdm capable.

bmarks
Contributor II

Maybe I'm thinking of FileVault, but I'm about 90% sure I'm correct. The reason being that certain MDM features like remote lock, remote wipe, etc. utilize the other partition to do these things and without it, these MDM features wouldn't work.