I never unenrolled my devices when I moved to Jamf Cloud. I know it depends on your setup, so you should raise a ticket with Jamf.
Migrating to cloud should basically be transparent to the user. You would give Jamf Pro Services a copy of the DB shortly before cutover and then you would update the appropriate DNS settings to point your URL to the cloud endpoint. Users shouldn't need to re-enroll.
Migrating to cloud should basically be transparent to the user. You would give Jamf Pro Services a copy of the DB shortly before cutover and then you would update the appropriate DNS settings to point your URL to the cloud endpoint. Users shouldn't need to re-enroll.
There are technical requirements that need to be met to do the custom DNS migration that couldn't be met at the time this was started. As it is today there is a full on-prem instance (in use) and a full cloud instance (in use). So there isn't a path to get the existing devices off cloud and back to on-prem, and then stand up a new cloud instance, then copy the database, then migrate with the DNS change.
So thats why i'm looking for options to make the re-enrollment easier for users.
I don't know that there's a good way to avoid getting those pop ups. As soon as you remove the main MDM profile, all the other profiles are going to go away, which is going to cause all those previously suppressed System Extension warnings and the like to come up. In some cases, you might have more serious problems, such as required tools (like a VPN client) not running unless the user authorizes them to run.
It's too bad you couldn't get the DNS redirect in place for your migration. We just did our on-prem to cloud migration in late June and it was super smooth for us with the DNS redirect in place. All the Macs just continued to check into the new server seamlessly.
I wish I could say I had a good idea about how to do this, but I don't. We do have a small group of Macs that were not part of our on-prem DB that will need to be moved over to cloud from another on-prem Jamf Pro instance, and I'm seeing similar issues. We have to use an API script to remove the MDM profile, all the other profiles go away, warnings pop up, then a package re-enrolls the Mac (legacy) into the cloud and finally, we issue a profiles renew -type enrollment command to prompt the user to install the MDM profile from the new server, which brings down all the other profiles again. It's a fair amount of steps that require user interaction and/or interruption, but even talking with a Jamf professional services engineer, he said there wasn't any easier way in the end.
Is there a reason you are not having JAMF take over your database and doing a DNS redirect to avoid needing to reeneroll?
Is there a reason you are not having JAMF take over your database and doing a DNS redirect to avoid needing to reeneroll?
The DNS is internal only and cannot be exposed to external. So any emails to admin@/postmaster@/etc do not work.
The DNS is internal only and cannot be exposed to external. So any emails to admin@/postmaster@/etc do not work.
Those are generally admin tools and would need to be "reconfigured". As far as user popups for configuration profiles (802.1x, etc) should not happen if you use a DNS redirect as you should not need to reenroll devices. Granted as you noted DNS redirects only work internally, but id imagine your devices either have a DMZ situation so external devices can access the the onprem server or can only access your JAMF Server when on a VPN or in office.
