JAMF MDM Profile

[rkeleghan]

Looking for input and help :)
We have identified a number of systems that were enrolled with a dodgy push cert which is causing config profiles to be extremely slow when being deployed.. 
Is there a way to fix the identified systems without having to unenroll and re-enrol? but .. if we need un-enroll and re-enrol - is there a way to do it smoothly? and what the best way to approach it

Thanks

Rob

[AJPinto]

I am not sure a "dodgy push cert" would cause the issues you are seeing. The push cert more or less works or it does not work. Dodgy means it would be marked as invalid and refused. You could renew your push certificate simply enough and see if that helps, however your problems are probably deeper than the push cert. You could try to renew the MDM Profile, and renew management on a device to see if that helps.

As far as reenroll. No, its a sloppy process per Apples design. User Initiated Enrollment requires user interaction as the name implies. I would also stay away from User Initiated Enrollment at all costs. The only other enrollment method would be Automated Device Enrollment, which requires macOS to be reinstalled. 

[rkeleghan]

Hey @AJPinto ,

Thanks for coming back, so here is how we came to this conclusion... 
Back in Oct 2022 we renews the Push cert which looks it was renewed by a users Apple ID account and not or standard developer account ...

Cert was updated and all seemed to be working .. then over some time, we notice that config profiles were taking ages to deploy and in fact, we need to reboot the systems before the profile was installed on the systems.

The other day we need to send out management tasks to systems and noticed that it was stuck in a pending state... After investigation, we notice that the "Topic" inside the MDM profiles where different on systems - 
Systems that went through enrollment after push cert renew- CP taking ages - sometimes a reboot is needed.

Systems that went through enrollment before Push cert renew - CP deploy straight away

Im trying hard to find a solution without needing to un-enroll and re-enroll devices ... lol

[AJPinto]

If you guys did not use the correct AppleID to renew the push certificate, a reenroll is the only way to go with how long its been. The Push Cert is also hosted in JAMF, not the device (Mac, iOS). The Macs trust Apple natively, the cert is so Apple trusts JAMF. The Macs use the MDM Profile to trust JAMF.

However, keep in mind. If there is a certificate problem, it wont work. Ever. There is no hit or miss, or its just slow, or a device needs to reboot. The device will flat out reject the communication. I could see a framework or JAMF Binary initiated being hit or miss, not a certificate problem. 

What management tasks are you sending that you are seeing hang? (Configuration Profiles, MDM Commands, JAMF Binary related function, etc). 

[rkeleghan]

Hmm ok .. so a re-enrol is the only way - is there a way to automate it? 

We are sending both management commands and configuration profiles..

[AJPinto]

No you cant automate MDM Enrollment. Either you send the MDM Command to remove the MDM Profile (assuming that works at all) and the users manually enroll. Or you reinstall macOS and the device will enroll with Activation.

What are the logs on the device saying? Are they getting the MDM Commands at all? Anything in the JAMF Logs?

[mojo21221]

We have had some success with having the user run sudo profiles renew -type enrollment from terminal to re-deploy the mdm profile to devices that have become non-responsive. (thinking it was due to restoring from a TimeMachine backup before we disabled that). If you do have luck in that command working. you may want to disable your @Enrollment policies to speed up the workflow for 5ish minutes that device needs to get back into compliance and inventory.

[piotrr]

I agree with AJ Pinto and add my five cents that the problem is with your  MDM enrollment profile on those machines, not with the certificate. At some point, I believe your profile was updated to fix this problem, but when Jamf Pro asked if they wanted to update all machines or just newly assigned machines, they chickened out and chose only new. :) 

If I'm right, which is a big if, you could make some insignificant change to the MDM profile again, and distribute that change to _all_ devices. 

Keep in mind that it's possible that your machine fleet can have several different versions of that MDM profile, because someone clicked "only new" several times.