Supervised iPads VS. Backup Restoration

@SHCK_Scott What happens if you restored iPad A's backup to iPad B?

We've had to do what @bentoms describes. Restore A to B, and if we want to keep people with the exact same device assigned, restore B-with-A's-backup back to A.

Works like a charm—a complicated charm.

I think the idea behind this is to make it difficult for someone to take a personal device and supervise it. If that weren't the case, someone could easily (whether it's an employer or someone with more nefarious intent) take your phone, supervise it, hand it back to you and when you restore it suddenly they have way more control over your personal device than they should. I wish things like DEP would override it, but that's the basic concept.

We are finding if the original iPad can be updated to iOS 10.1.1, and then a backup taken it usually works to restore that to a new iPad, but not always. @SHCK_Scott We've tested your theory and it hasn't worked in our environment. I believe it's a change in the way iOS 10 is handling certificates.

Here is my last post from this thread on the subject:
I have a case open with jamf for this issue and sent them log files from AC2 and iOS Console. If you can capture logs and submit them to your TAM it may help them figure out what's going on. We are working around the issue by updating the original iPad to 10.1.1, getting a backup, and then using that backup for the iCloud Restore. That is assuming the original iPad is not so broken that it can be updated to 10.1.1 - If you can't update the original iPad you can also restore from an old backup to an iPad that is not in a pre-stage or jamf and then AirDrop stuff to the new iPad which has been setup as a new iPad in jamf.

We turned over 5400 ipads this fall and we ran into this with our Staff ipads every time they did a backup. Apple did acknowledge it as a bug when i filed a ticket with them. They said they fixed it with 10.1 I think.

Our workaround was to backup to iTunes on a PC (Mac or Windows) and then restore with iTunes. Had no issues with that.

@SHCK_Scott I had a similar situation and I hope this helps you:

We have a BYOD program with the students which all iOS devices are being managed by JSS. The school has a couple of DEP iPad loaners. When a student loses or breaks their iPad and requires an iPad loaner in the meantime, I would assign the student a loaner. When the student is prompt to restore from an iCloud backup, the process would hang at "Installing configuration for blah school..." and would not go further. This same issue happens for Faculty owned DEP iPads as well.

After some troubleshooting, I was able to resolve this issue. Apparently, the MDM profile installed on the iPad would conflict with the restoring process. So I would delete/remove the MDM profile from the iPad then perform the backup, either by iCloud or iTunes. I would have no issues restoring the user's data to a DEP iPad. And perform the same process vice versa when transferring the iPad loaner to the student's personally owned device and have them enroll into JSS.

I wish there was some way or an option in JSS to not allow MDM profiles to be backed up.

I've run into the same scenario, and I've found some success with the workflow you've laid out, with a minor tweak. If you hit home button while the iPad is stuck on "Installing Configuration" it will bypass the configuration, and finish the restore without supervising or enrolling the device(the device will claim to be restored in Settings, but I believe this to be a bug because everything else sees the device as not supervised). After skipping this step, you will need to delete the CA and MDM profiles in Settings>General>Profiles(you will be able to delete them even if your normal MDM profiles are non-removable). Creating a new backup on this non-supervised device will allow it to be restored to a DEP iPad without issue.

There is one caveat to this workflow, however. We are using device assignment for all of our 1 to 1 iPads, and when you restore a backup, iCloud will often fail to download some of the backed up apps because the licenses for those apps haven't been assigned yet. When this happens, the documents and data associated with that app are kept on the device, and can be access like normal once the app is reinstalled from Self Service. The issue is, doing the second backup on the non-supervised device will not backup this data, as backups don't backup appdata unless the app is present at the time of backup.

My theory is that iCloud backups in iOS 10 are also backing up profiles, including the MDM profile, as evidenced by the weird removable MDM profile being present on the failed restore, and the presence of this faulty MDM profile is what is disrupting the enrollment and supervision of the device post-restore.