Skip to main content

Hello all,

I currently have an active ticket with Jamf pertaining to this infamous issue. Currently I have around 78 devices that have not checked into Jamf, and we suspect that are are more devices than what I listed that are impacted. I have tried several commands, such as sudo jamf reenroll -prompt, and removing the profiles, but they either error out or return with the same error. I have created an EA that monitors this issue, but, only four computers return with the MDM is broken error and the rest of the impacted machines do not return anything at all. It is a little frustrating, because I am worried that this issue might just keep reoccurring over and over.

 

I was told that the best way to fix this solution is to wipe the machines whose MDM profiles cannot be removed, and I just really can't wrap my head around that, neither do I think that is the most professional solution in our case (since it impacts an educational environment).

 

Does anyone have any more information on this issue? Is it to do with Monterey? Is it to do with Casper or certificate trust settings? Can this issue be prevented?

I have also used the self-heal binary script, and on 37 machines (that just so happen to be checking in), it errors out with a 404 code, and on the rest of the machines it succeeds, but as you can see, we still have the issue.

I'm a bit ashamed to say that I only noticed this in our environment. Had a bunch of devices stop talking back around 8/15/2022, and upon researching the nature of the issue, found many more devices likely in the same state based on device age, and time between enrollment/last check-in.

I had trouble with the self-healing script working (not sure why), but I instead had great success using the Jamf API's web tool.

Browse to https://YOURINSTANCE.jamfcloud.com/api/doc and authenticate with an admin account at the top of the page to get a token. Scroll down to jamf_management_framework, click it and expand the redeploy command it shows, then click "Try it out". Enter the device's ID number, then hit "Execute".

 

I'm a bit ashamed to say that I only noticed this in our environment. Had a bunch of devices stop talking back around 8/15/2022, and upon researching the nature of the issue, found many more devices likely in the same state based on device age, and time between enrollment/last check-in.

I had trouble with the self-healing script working (not sure why), but I instead had great success using the Jamf API's web tool.

Browse to https://YOURINSTANCE.jamfcloud.com/api/doc and authenticate with an admin account at the top of the page to get a token. Scroll down to jamf_management_framework, click it and expand the redeploy command it shows, then click "Try it out". Enter the device's ID number, then hit "Execute".

 


I have used Jamf API's web tool before as well, for a couple devices I suspected of having the device signature issue, and unfortunately, it hasn't worked for me. I've tried it on both devices that have errored out and ones I suspect to have a device signature error (based on the fact they haven't checked in).

Terms & ConditionsCookie settingsAccessibility statement