NEW PROFILE DOES NOT MEET CRITERIA TO REPLACE EXISTING PROFILE

Thanks petestanley. I actually ran in to this this morning, followed the procedure and upon authenticating to Re-enroll the device via DEP, I received "Error: Existing Device Enrollment configuration was found." And this was after blowing out the ConfigurationProfiles.

What is causing the error? Why wouldn't a newer or profile that has not changed not be able to be used?

We are following the steps and sometimes it works when we log in to our TechDesk account and remove the store folder.

I'm seeing the error popping up more and more with DEP enrolled machines to the point of it being a problem. It's happening because we're first getting invalid device signatures when going in via DEP and then try to do sudo jamf enroll -prompt and the results are this error type.

Any one have solutions for the invalid device signatures that doesn't also result in this error lol? >.<

All,

I Often get this issue:

First double check your Mac date & time , if its correct then check out below link it should resolve the issue.
https://create.ps/index.php/2018/12/24/fix-new-profile-does-not-meet-criteria-to-replace-existing-profile/

I got the message, “NEW PROFILE DOES NOT MEET CRITERIA TO REPLACE EXISTING PROFILE” issue today. Tried the instructions on this thread, and checked date/time. None of that worked, so I ended up imaging the laptop.

getting this issue as well... the configuration profile is still on the machine, but I have no way of tracking it via JSS as on JSS - the machine is simply missing under that same configuration profile... this DEP crap is becoming more and more a pain in the ass

Thanks petestanley for the writeup, we just faced this for the first time since we fully moved to DEP and this was very helpful. Just wanted to add a slight correction though.

In step 3 of the "Remove all old profiles..." section, I think the path should reference the actual boot volume, rather than the Recovery volume we're currently booted from...

So the following command:

rm -rf /var/db/ConfigurationProfiles/Store/

I'm pretty sure should instead be (with MacintoshHD changed to your actual boot volume):

rm -rf /Volumes/MacintoshHD/var/db/ConfigurationProfiles/Store/

So there's no way around this that doesn't involve disabling SIP??? I've got 1500 computers to migrate to new server and cannot have it this way.

I've run into this once or twice so if anyone has a way to scale this workaround please post.

First I manually reinstall the QuickAdd.pkg - This flips the MDM profile from Pre-Stage to User thereby allowing you to uninstall from the Profiles Pane in SysPrefs

Then I run "sudo profiles renew -type enrollment" to get trigger the DEP nag and re-enroll through there

I don't disable SIP at any point in the process.

@r... ,

How do you reinstall the QuickAdd.pkg? Are you creating it with JAMF Recon app on the actual mac - then run it?

As when you re-enroll via user-initiated URL - it attempts to install the MDM configuration profile... and all the issues start

@shurkin18

I've been generating one offs through the /enroll URL.

What enrollment state is the device in when you try to re-install? Do you currently have a non-removable MDM Profile installed and you're not able to reinstall the QA.pkg over it? Also, what error are you getting when you run sudo jamf manage?

@r... Well I just wiped and re-imaged the device.. it was communicating with JSS (checking in), the MDM profile was not fully Approved - the Approved button was missing... complete mess. I was trying to re-enroll it via Terminal (sudo jamf enroll -prompt) and was getting the cannot replace configuration profile, sudo jamf manage I believe gave me similar errors

Having same issue. Opened a ticket with Jamf.

we have had this issue, delete the machine from the JSS web ui if its a re-enroll/wiped machine. From terminal -

sudo profiles renew -type enrollment

It should go, but sometimes does not depending on the dep sync timer and if the machine has been assigned etc, at least this is what we have found works for us.

@gcarmichael So theoretically we could run the

sudo profiles renew -type enrollment

command, and then a quickadd package should work?

@r... You just saved me so much time with this. In the current state of things, we have nearly our entire workforce at home, and having to walk users through booting to recovery mode etc would have been a nightmare. We did do it once already, but the user was a software developer so it was an easy task for him. General office workers would not have such an easy time.

I'm getting this error trying to do a User Enrollment via download profile, over top of an existing DEP enrollment. Used to work fine in Catalina, not working in Big Sur. I can run sudo profiles renew command instead and it works okay.

@MrRoboto That wasn't supposed to work. The "bug" was "fixed" in Big Sur, so that trick no longer works. Now non-removable MDM really is non-removable.

@patgmac Thanks. In cases where we want to re-enroll to refresh management (expired profile, certs, etc), is it acceptable to run 'sudo profiles renew -type enrollement'?

@MrRoboto That won't do anything if it's already enrolled. You have to un-manage and remove MDM before that command will work again.

I ran into this issue, my work flow for getting Macs Supervised is:

jamf removeMdmprofile

jamf removeFramework

open safari myorg.jamfcloud.com/enroll - install profile etc...

profiles renew -type enrollment

jamf recon

Confirm it shows as Supervised and DEP enrolled.

Its working as far back as Catalina

A Monterey Mac caught me out as I removed framework