+3We have a client who is using a .local Jamf Pro instance, they have recently decided that they would like to migrate to a JAMF Cloud instance. They have roughly 300 mobile devices and 80 MacOS devices.
Migrating the MacOS devices is simple enough with a policy to install a new QuickAdd with some pre/post flight scripts.
Anyone got any ideas on the best solution for migrating the current mobile devices?
+26Thats just about as painful as changing the URL period...basically devices would have to be un-enrolled and re-enrolled from my understanding though I gladly defer to anyone who has done this. Changing the URL (either from .local to something else OR from two different addresses cause pain to iOS devices).
Assuming no one gives you a much better answer, how hard is it to have everyone backup, send a wipe command and re-enroll with 300 devices? Again, I wish I had a better answer...anything that causes a re-enroll here is usually met with ugliness given 4000 devices.
+3Possible solution has been suggested.
The client has DEP currently setup with their existing Jamf Pro instance. If we move the DEP over to the new Jamf Pro instance, then send a remote wipe command from the existing Jamf Pro, when the devices come back up and attempt to activate they will enrol into the new JSS.
Need to confirm whether or not they will be able to use iCloud backups to restore user data, restoring from iCloud backup may break enrolment to new Jamf Pro instance.
+12Unless this has changed in 10.3, you wont be able to use iCloud/iTunes backups when restoring to the same device. When you do that, for whatever reason, the device restores EVERYTHING— even the supervision state and MDM enrollment.
You'll either need reassign devices, or use an intermediary device (back up A, restore to B. back up B, restore to A) to get around that issue.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.