So this is part 2 of my mini series on using ReEnroller. Part 1 can be found here and covers the initial setup. This part will look to cover the process and some basic troubleshooting, as well as some post migration tasks.
So if you followed my guide from last time, you should hopefully have a working migration process. With the configuration I’ve talked through, the process that the ReEnroller will carry out is:
- User triggers the ReEnroller package installation workflow
- The policy will install the ReEnroller package and “Completes”
- Due to this, I’d suggest added a ‘policy completion’ message to the policy to let users know the rest will run in the background
- ReEnroller will now launch and start doing its thing:
- ReEnroller will now move the current Jamf enrolment pieces to one side
- If MDM enrolled, it will now try a local removal of the MDM Profile.
- If this fails, it’ll try and call the MDM API removal policy on the source server. This runs an unmanage command – the only way to remove a DEP un-removable MDM Profile
- If this fails too, ReEnroller will revert the enrolment back to the source server
- ReEnroller will now create a new enrolment invitation on the destination server and enrol to it
- If this fails, ReEnroller will revert the enrolment back to the source server. If the MDM Profile was removed, ReEnroller will use the Jamf binary to enrol the MDM side without UAMDM.
- ReEnroller will now use the Jamf binary to enrol the MDM side, but without UAMDM
- Once reenrolled, the “migration complete” policy will be called to confirm all was successful
- Once again, if this fails, ReEnroller will revert the enrolment back to the source server. If the MDM Profile was removed, ReEnroller will use the Jamf binary to enrol the MDM side without UAMDM.
- Migration should now be complete, but will not be UAMDM’d
- If at any point ReEnroller failed the migration, it’ll repeatedly try again every 30 minutes (unless you change this setting in the ReEnroller application)
If you’re seeing issues with the migration, there are a few things you can check:
- The ReEnroller process actually logs its work in the jamf.log at /var/log/jamf.log. This should be the first place to check for errors
- You should also check the logs for the policies to check if they did run, and if they had any errors! This should be the “migration complete” policy and (if used) the API MDM removal policy.
What about UAMDM?
As mentioned above, these MDM Profile enrolments are via the Jamf binary and so will result in a non-UAMDM enrolment. I’d suggest documenting the process to accept the MDM profile and sharing this out with your end users. For this same reason, you shouldn’t block the Profiles System Preference Pane on migrated devices.
Jamf has an option to nag users to accept this, but they’ll need the user to launch Self Service, or to allow Self Service notifications (something you can’t force-on until the device is UAMDM’d)!
I heard a rumour…
What about the next macOS, Big Sur? I heard a rumour that it may add further obstacles to command line profile installation, and these would break the ReEnroller workflow above. At this stage, I can only suggest testing with Big Sur and filing feedback with Apple / Jamf / the ReEnroller project.
That should complete the ReEnroller mini-series! Hopefully it’ll help guide you through the process to a working solution, or a base to make your own tweaks and changes.
As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.