Skip to main content

I guess all admins face this issue where machines just stop connecting to the Jamf Cloud service.
Could be that something just broke or the user broke it just because he/she can.

This blog post seems to offer a solution
https://www.jamf.com/blog/how-to-reinstall-the-jamf-framework-through-the-api-with-webhooks-and-microsoft-powerautomate/

How can a machine that is not contacting Jamf anymore be instructed to re-deploy the framework?
The blog starts promising: "This blog shows how to automatically re-deploy the Jamf Framework to macOS clients who did not check in for the last X amount of days"

When reading through the blog post it is unlclear to me how the re-deploy action is pushed to the machine.
In the video that is attached to the blog post, an email is send to the potential end-user.

Anyone reads if different then me or actually got this implemented?

Think of the Jamf agent being in two parts, the binary (Jamf) and MDM profile (Apple)
Its possible for any admin enabled user and bit of tech knowledge to look up the terminal command to remove the all JAMF Framework.
The above blog assumes you have wisely ensured all your mac's were enrolled via ADE (DEP) and you have marked the MDM profile to be non-removable.
Even if a user manually removes jamf or runs the command to remove all framework; because the MDM profile is non-removable,  it will still receive MDM commands by APNs, so by using the information in the blog you can send a MDM command to reinstall the Jamf framework and restore the Jamf binary functionality (it uses the same MDM command that adds the Jamf binary on enrolment)

The blog tells you how to automate this, so you will need to set up a web hook server of some description (something like JAWA or in the above example PowerAutomate) to handle the trigger mechanism its needs (normally done by the Jamf binary) for the Jamf Pro API to send a "InstallEnterpriseApplication" MDM command via APNs asking the client to get the QuickAdd package installed again to restore the Jamf binary framework to the device.

Think of the Jamf agent being in two parts, the binary (Jamf) and MDM profile (Apple)
Its possible for any admin enabled user and bit of tech knowledge to look up the terminal command to remove the all JAMF Framework.
The above blog assumes you have wisely ensured all your mac's were enrolled via ADE (DEP) and you have marked the MDM profile to be non-removable.
Even if a user manually removes jamf or runs the command to remove all framework; because the MDM profile is non-removable,  it will still receive MDM commands by APNs, so by using the information in the blog you can send a MDM command to reinstall the Jamf framework and restore the Jamf binary functionality (it uses the same MDM command that adds the Jamf binary on enrolment)

The blog tells you how to automate this, so you will need to set up a web hook server of some description (something like JAWA or in the above example PowerAutomate) to handle the trigger mechanism its needs (normally done by the Jamf binary) for the Jamf Pro API to send a "InstallEnterpriseApplication" MDM command via APNs asking the client to get the QuickAdd package installed again to restore the Jamf binary framework to the device.


Thanks for the reply.
The MDM profile in indeed non-removable.

Haven't tried anything from that blog post yet, but i thought, broken is really broken.

Thanks for some clarification.

This is really for the scenario where the management framework has been broken or removed, but the device still has internet access so that APNs can still be used (as long as the device can reach Apple and your Jamf/Jamf Cloud instance it can give you access back to your device).

If they don't have any internet, then it cant fix that scenario 

Question how in Jamf can you tell if the frame work has been broken/removed?  Just by the last check in date?

Question how in Jamf can you tell if the frame work has been broken/removed?  Just by the last check in date?


@qeldrom 

There are two ways I check. 

First is to look at the last check-in date. The second is to see if the last inventory update hasn't occured within about a week of the last check-in.  The later is pretty common in our environment.

Terms & ConditionsCookie settingsAccessibility statement