removeMDMprofile vs removeFramework for automated migration to Jamf Cloud using ADE

davidi4
Contributor

So, as I've expanded the testing of our Jamf on-prem to Jamf Cloud migration out to our "friends and family" in IT, I ran across an issue where the jamf removeMDMprofile command removed the profiles, but the device still would not perform ADE at reboot. (device loaded in ABM, assigned to our Jamf Cloud, and assigned a PreStage Enrollment)

Creating a throw-away account in order to get through Setup Assistant and perform additional troubleshooting, we found the device still reported it was configured to look for our on-prem, per the output of the jamf checkJSSConnection command. manually running jamf deleteSetupDone and jamf removeFramework, followed by a reboot allowed the ADE process to perform properly on this device.

Should I modify my script to check the output of this command for this potential state (and perform a removeFramework), or just change to use the jamf removeFramework command instead of (or after removeMdmProfile) for all users instead? Obviously I lose the ability to use the jamf binary in any form while unmanaged, but are there any other potential issues I should be concerned about?

 

Thanks in advance!

1 REPLY 1

daniel_behan
Contributor II

There are two parts to JAMF Management; the jamf binary which performs inventory updates and policies, and MDM which installs Configuration Profiles and performs management commands via APNS.

 

Running "jamf removeMdmProfile" does just what the command says, it removes MDM, but not the binary, so the machine is still managed and checking into the server specified in the com.jamfsoftware.jamf.plist. If you want to completely un-manage the machine, running "jamf removeFramework" deletes the MDM Profiles and the jamf binary.

 

If you're testing something against a different server, you can change the server that the jamf binary reports to by running "jamf createConf <options>".  You can look at the options by running 

"jamf help createConf"