Posted on 07-24-2023 08:49 AM
When migrating from jamf on-prem to cloud, devices are first unenrolled from on-prem. Which means they loose every Configuration Profile for system extensions, PPPC, 802.1X etc. Users get the notification prompt to enroll into jamf cloud and if they click through that it does migrate them successfully. But is anyone aware of a process to make this smoother so users don't see dozens of other notifications/prompts while they're in the "limbo" state?
I saw Rocketman Tech had a workflow using DEPNotify that made things a bit smoother. It did look like it was able to hide all of those notifications (at least during the demo https://youtu.be/ZTbv5ZvI3pI). But on current versions of macOS there isn't a way to stage profiles that remain after unenrollment as far as i know. So the only option i see to help with all the prompts would be to use AppleScript to close out the undesired notifications. I don't know how well that would work since that too needs PPPC permissions to run.
Slowly transitioning over as we buy new hardware isn't an option since we need to move faster then that. I also don't want to wipe and reimage every device. Does anyone know of a way to improve the user experience?
Solved! Go to Solution.
07-24-2023 10:28 AM - edited 07-24-2023 10:31 AM
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.
Posted on 07-24-2023 08:59 AM
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.
Posted on 07-24-2023 09:00 AM
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.
Posted on 07-24-2023 09:28 AM
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.
07-24-2023 10:28 AM - edited 07-24-2023 10:31 AM
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.
Posted on 07-25-2023 06:44 AM
Is there a reason you are not having JAMF take over your database and doing a DNS redirect to avoid needing to reeneroll?
Posted on 07-25-2023 08:01 AM
The DNS is internal only and cannot be exposed to external. So any emails to admin@/postmaster@/etc do not work.
Posted on 07-25-2023 08:30 AM
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.