MDM Migration Workflow

Today, we're going to cover the challenges of MDM migrations, the confusion that this creates for users, and then present a workflow that we've created that addresses all of this.

The Good Ol' Days...

First off, how did MDM migrations work in the past? Dare I say that it was easy back in the day.

It used to be that step one was to deploy the Jamf Quick Add package through the previous MDM. That would install the Jamf agent on the computer. Then we would send a command through Jamf to remove the previous MDM profile and then install the Jamf MDM profile. And then, in typical Apple fashion, there was no step three. But those days are now over unless all your computers are on High Sierra or below, which hopefully is not the case.

Today's Challenges in MDM Migration

What are the challenges that we have today with some of the changes that Apple's made in automating this process? Well, first of all, we can only install one MDM profile at a time. There are also non-removable MDM profiles that cannot be removed by either a bash script or the user. On top of this, when we do remove that profile, all the configuration profiles are removed along with the MDM profile. Once we do get it migrated over, those FileVault Recovery Keys break, so we need to reissue those. And then, since High Sierra, Apple introduced user-approved MDM profiles, which require user interaction. And then, since Big Sur, they took away the ability to programmatically install MDM profiles altogether. Along with all of this, the web enrollment process since High Sierra has gotten a lot more complicated when enrolling in Jamf Pro.

Let's look at each of these individually.

First of all, the MDM profile must be user-approved. So even if we just install it programmatically with High Sierra through Catalina, the user needs to go into the System Preferences profile pane in order to approve that MDM profile. Until that time, they have limited functionality. And then, since Big Sur, they took away the ability to install programmatically altogether. Only one MDM profile can be installed at a time. This actually creates a big issue when we're trying to do these migrations because oftentimes the user will go through the process of installing the profile, and then they'll get this error: "Profile installation failed. You are already enrolled in an MDM server." It's actually kind of confusing for the user to remove that MDM profile via the GUI. They need to find the actual MDM profile, and if you have a big list of configuration profiles, that's going to be hard to do. Also, if the previous profile is in DEP, it can't be removed for the user. Those non-removable MDM profiles can't be removed by a user, can't be removed by any bash commands, or any other type of commands. It can only be removed via the previous MDM. Now let's say that the previous MDM is no longer active or not able to communicate with the device. What do we need to do then? Well, the user needs to boot into recovery mode, remove SIP, which is a couple terminal commands, boot back into the boot disk, remove the MDM profile, and then we need to boot back into recovery mode, enable SIP because that is an important security feature, and then boot back into the boot disk. Not a process we want to go through.

Along with this, once that MDM profile is removed, there's often a gap between removing the old one and installing the new one, which will install the new configuration profiles. All those old profiles are going to be removed, which means the user might be disconnected from Wi-Fi. Additionally, important configurations may be removed, applications may not be able to run, and then the user will get all these pop-ups for system extensions and PPPC profiles. All these issues will drive the end user to call the help desk and say, "Hey, I don't know what's happening, but someone seems like they're trying to hack into my computer because all the stuff is popping up out of nowhere."

On top of all of this, there are also the difficulties of web enrollment since 10.13.4. At that point, we went from enrolling through a Quick Add package, which is pretty simple, to now installing a CA certificate and an MDM profile, which is a little more confusing because it is two different steps. Also, since Big Sur, once you download that profile and launch it, which happens automatically in Safari, the user needs to manually open up System Preferences and navigate to the profiles pane. These might sound like small things, but as I've gone through a lot of these different migrations and implementations, users, it doesn't matter what you give them for instructions, they're confused about this process. In order to enroll in Jamf Pro, you need to be an admin on your computer. So the standard user either needs to use a backdoor admin password, or you need to do it for the user.

MDM Migration Workflow

Now let's look at the MDM migration workflow that we've created. This workflow addresses all of the challenges we talked about earlier and makes the migration process easy for users.

In the back end, we're installing all those things that I said, and then we're deploying this script which has a lot of if statements to go through different scenarios that we're going to encounter. Then, we'll go through the three different workflows that we've created.

Non-DEP Workflow

For this workflow, we're going to start off with the DEPNotify popup window, that asks the user to continue. Whenever they're ready, they click continue, and then it's going to launch some user instructions which tell them what they need to do.

It's the only two things they need to do, as we're going to be doing everything else in between. Once these steps are complete, it launches the web browser for them, which goes straight to the MDM profile. They don't even need to log in. Once it downloads, it's going to search the home folder for the file, launch that file, and then launch System Preferences. So all they need to do is click install. They don't need to go through that process of opening System Preferences to the profiles area.

Now it's waiting for them to actually install that profile so the script's not moving forward yet.

Once it sees that it's installed, it closes the profiles window, eliminating that as a distraction. Then the script is going to run the reissue FileVault recovery key workflow. Once it's done with that workflow, then it's going to move on to the next step.

It checks to see if Jamf Connect is installed. If it is, then we're done with the workflow. But if it's not, we're going to install Jamf Connect, launch the application, and then they're going to log in with their identity provider credentials. Once they've logged in, then it will move on to the next step.

DEP Workflow

The DEP workflow is a little bit different. Same thing as before, it asks them to continue, then it goes on to show them the instructions of what they need to do. In the upper right corner is a pop up for the Device Enrollment window. Once they click on that, they have to click allow, and then they enter their password to enroll. It's still waiting in the back end to see if they've installed it, and then once they have installed that MDM profile, it closes System Preferences for them. Now they can go back to the migration window. It's also waiting to make sure. Then it'll move on to the next step.

Then, the script checks to see if Jamf Connect is installed. If it is, then we're done with the workflow. But if it's not, it is going to install Jamf Connect, launch the application, and they will need to log in with their Identity Provider credentials. Once they've logged in, then it will move on to the next step.

Already Enrolled in Jamf Workflow

The last one is the manual Jamf enrollment. Let's say someone just goes to a web browser and enrolls their computer. We want to make sure that it goes through the later steps but not the earlier steps where it does the MDM migration.

So, it skips all those MDM migration steps and goes straight to reissuing the FileVault recovery key. In this scenario, it wasn't even FileVault encrypted, so it didn't have to do that. It just went straight to logging into Jamf Connect to make sure their passwords were synced.

Jamf Toolkit

That's what the workflow looks like in the front end. There's a lot of different things that could happen during this process, but this workflow ensures that no matter what macOS version they're on, no matter how things are set up in the back end, whether they're enrolled in the old MDM or not, everything's going to work, and it's going to be a very easy process for the users.

We presented this MDM migration workflow and many others at JNUC '22, we've taken this tool and others and combined them into them into the Jamf Toolkit. The Jamf Toolkit's going to be a repository of a lot of amazing workflows that our engineers have put together. Along with the MDM migration workflow listed here, there will be lot of different scripts and tools that you can download and implement with great user instructions and updated to the latest macOS versions.

Conclusion

In conclusion, MDM migrations can be a complex process, but with the right workflow in place, it can be made easy. We hope that this blog post has given you an insight into the challenges of MDM migrations and the workflow that we've created to address all of this. Thank you for reading. - Chris