Error: Existing Device Enrollment configuration was found.

Non-removable MDM is a feature of Apple’s Device Enrollment Program (DEP) that locks in the MDM profile to the device, controlled by the is_mdm_removable key in the enrollment profile. This is a great feature, especially if any users in your environment have admin permissions for their machines and you want to make expressly sure that they can’t remove the MDM profile - in an enterprise environment, the ability to restrict as much as possible is key to keeping your devices compliant and working. With this key set to false, a user is unable to remove the MDM profile from the Profiles pane in System Preferences or with any terminal command and, with System Integrity Protection (SIP) in High Sierra protecting the /var/db/ConfigurationProfiles folder, it now can’t be touched at all. This is great!

This is also not great, because computers are not perfect, MDM is not perfect, DEP is not perfect, and user migrations are a thing.

This MDM profile cannot be touched at all. It cannot be removed or altered, but it also cannot be replaced or overwritten. This means that all mechanisms for re-enrollment or re-application of the MDM profile will fail. Everything from sudo jamf mdm in Jamf shops to sudo profiles renew -type enrollment (sudo profiles -N on regular Sierra) will return with a message like the one in the image above informing you that your current MDM profile exists and can’t be replaced. So how do you re-apply MDM? If you need to change the MDM enabled user (ie. after using Migration Assistant or Time Machine to restore a user to the machine) or something has just timed out and your user just isn’t downloading that configuration profile or VPP app? If you can’t send any commands from your MDM server (including the one to remove the profile in the first place) since your MDM is broken?

Well, in macOS Sierra, you remove that ConfigurationProfiles folder. Good old rm -rf /var/db/ConfigurationProfiles. Reboot for safety, re-enroll with your DEP nag command of choice or whatever other mechanism you use to enroll devices. But in High Sierra, this folder is protected by SIP.

“I know how to disable SIP, though, why can’t I just do that?” You can. You should definitely not remove the whole folder (removing the whole folder breaks the ability to have configuration profiles on the machine forever), but if you disable SIP, you can rm -rf /var/db/ConfigurationProfiles/Store/ and re-enroll with your profiles command while SIP is still disabled, and then turn SIP back on. This comes with a whole bucket of risks, though, some of which I’m not sure we’re willing to take. The machine needs to be able to connect to the internet in order to re-enroll, and I’ve seen and heard stories of things going wrong with SIP disabled even for a few minutes with minimal action taken - corrupt System keychains and entire System Preferences functions breaking are just two examples I’ve encountered while trying to execute this fix post-Migration Assistant that have led to wiping the entire machine and setting it up fresh for the user anyway.

Disabling SIP is also a function that can only be performed by the user on the machine physically touching it. You can’t remote in and boot to recovery and you can’t send it as a command or a script. If you aren’t physically with the machine, this is definitely a more complicated procedure than just two terminal commands in a live environment (that can even be scripted and cached!), and maybe you don’t want to teach your users how to disable SIP or risk that they won’t turn it back on. So how do we solve this in a live environment, running 10.13+, that can’t receive MDM commands on the correct user (or at all)?

There’s no way to deal with this, outside of disabling SIP, except with prevention. You can keep your High Sierra adoption rate low. You can choose to not use VPP-only apps (or distribute repackaged versions instead using a mechanism like Munki). You can choose to not make changes to your configuration profile setup after the initial deployment. But even with avoiding as many MDM features as possible, your enrollment may just stop working at some point and you may need to re-enroll, and if the only solution is disabling SIP and re-enrolling…to me, that’s a hack, not a solution.

There are a couple real solutions to this problem that I can think of off the top of my head. The one that seems most likely to work is for MDM services to figure out how to do everything without an MDM enabled user, so there’s never a need to re-enroll so long as there’s that system level MDM profile there somewhere. The other is for Apple to reconfigure the way non-removable MDM works to allow it to be replaceable using the profiles renew command but not removable or replaceable under any other circumstances. But those are just two ideas. The people at Apple (and at Jamf) are making best-in-class products, so I firmly believe they are smarter and more innovative than me in regards to coming up with ways to fix this issue.

It doesn’t matter how it gets fixed really, so long as I don’t have to live in fear of imperfect systems failing and there being no good way to fix them for another year after 10.14 hits. Someday, Apple will stop supporting El Capitan and Sierra. Someday, you won’t be able to downgrade new machines from High Sierra to Sierra. That day, unless this is solved, either we will all have to make our DEP MDM profiles removable and hope the users leave them alone, or resign ourselves to wiping machines or taking a chance on disabling SIP every time MDM breaks. I’ve got my fingers crossed.

Radar #40520642 from me specifically focuses on the fact that there is no recourse to enable MDM for a newly migrated-with-Migration-Assistant user with DEP non-removable MDM on the receiving machine. In addition to Twitter, I’m also @crystallized on the MacAdmins Slack, so feel free to pop by with questions!