Skip to main content

Hi everyone, 

I'm having a somewhat urgent issue with 46 instructor desktop machines at our college. Somehow a configuration profile that was scoped to these machines created another random profile called 'General' that keeps replicating over and over, reaching 3900 unique ID installations of the same profile name on each of the desktops. 

I've never seen this before, and other than removing the scope I haven't been able to stop it trying to create more and more General profiles. It's causing users not to be able to log in, and reboots are taking 15-20 minutes even on new M2 Mac desktops. It's happening on Monterey and Ventura OS, Intel and Silicon. 

Anyone seen this before? Hoping I won't have to rebuild each of these machines. 

Hello, we are encountering the same problem. Happened on 8th and 9th of December on more than 1000 devices in our organization. Hundreds of profiles named ‘General’ was pushed to computers. 

Hello, we are encountering the same problem. Happened on 8th and 9th of December on more than 1000 devices in our organization. Hundreds of profiles named ‘General’ was pushed to computers. 


Hi there,

Did you find a solution to the issue? It's causing really slow logins for our AD users, sometimes up to 40 minutes to log into the machine. 

Hi there,

Did you find a solution to the issue? It's causing really slow logins for our AD users, sometimes up to 40 minutes to log into the machine. 


Hi,

No solution so far but I have opened a case with Jamf. It is not happening right now but yes our entire macOS environment was badly impacted with performance issues. I am not sure if there is a way to get rid of those thousands of profiles without any re-enrollment.

Regards,
Syed Hyder

@syed_hyder do you have a jamf ticket number that you've been working with them on? Keen to add our experience to the same ticket when we raise our own.

A solution we've found is to run the following in recovery:

rm -rf /Volumes/Macintosh\\ HD/var/db/ConfigurationProfiles/*

mkdir /Volumes/Macintosh\\ HD/var/db/ConfigurationProfiles/Settings

touch /Volumes/Macintosh\\ HD/var/db/ConfigurationProfiles/Settings/.profilesAreInstalled

@syed_hyder do you have a jamf ticket number that you've been working with them on? Keen to add our experience to the same ticket when we raise our own.

A solution we've found is to run the following in recovery:

rm -rf /Volumes/Macintosh\\ HD/var/db/ConfigurationProfiles/*

mkdir /Volumes/Macintosh\\ HD/var/db/ConfigurationProfiles/Settings

touch /Volumes/Macintosh\\ HD/var/db/ConfigurationProfiles/Settings/.profilesAreInstalled

Confirming this one - Max found a solution to this for one of our customers this week after a couple of days of our team troubleshooting the issue.

Piggy-backing off Max's comment, after you apply the above fix in recovery you will need to re-enroll devices into Jamf Pro as the MDM profile was deleted after running the rm -rf command of the Configuration Profiles directory.

@maxhewett @And @James_NZ Thank you for your response, much appreciated. We use this solution to re-enroll devices in our environment but we have more than 1000 affected computers spread across a very large area and it is impossible to manually delete profile directory from recovery on each device. 

@syed_hyder do you have a jamf ticket number that you've been working with them on? Keen to add our experience to the same ticket when we raise our own.

A solution we've found is to run the following in recovery:

rm -rf /Volumes/Macintosh\\ HD/var/db/ConfigurationProfiles/*

mkdir /Volumes/Macintosh\\ HD/var/db/ConfigurationProfiles/Settings

touch /Volumes/Macintosh\\ HD/var/db/ConfigurationProfiles/Settings/.profilesAreInstalled

Thanks @maxhewett - funny you mentioned this because I found this as a solution as well and have started applying it to our machines as of yesterday. I didn't know if someone had a different method but this seems to be working on Intel Macs. Silicon are slightly different with this script and I'll try to make some changes and publish it for everyone on that processor type. 

Thanks everyone for the comments. This script method is working for us, just a little time consuming so I might try to automate some more of it, but that may not be possible due to the recovery mode process.

Also, Jamf evidently is coming up with a hot fix for this. It's a known issue :

PI115634Computer configuration profiles with a Security and Privacy payload may unexpectedly lose the configured settings, causing blank or null values in the os_x_configuration_profiles database table. As a result, Jamf Pro endlessly sends new configuration profiles with unique identifiers to the computers in scope. Workaround: Remove target computers from the scope. Contact Jamf Support and reference PI115634.

Found that here: account.jamf.com/products/jamf-pro/known-issues 

So if they can do something about it on the backend so I don't have to go to all 50 of my affected machines that would be nice. The commands mentioned above are working otherwise. 

Also, Jamf evidently is coming up with a hot fix for this. It's a known issue :

PI115634Computer configuration profiles with a Security and Privacy payload may unexpectedly lose the configured settings, causing blank or null values in the os_x_configuration_profiles database table. As a result, Jamf Pro endlessly sends new configuration profiles with unique identifiers to the computers in scope. Workaround: Remove target computers from the scope. Contact Jamf Support and reference PI115634.

Found that here: account.jamf.com/products/jamf-pro/known-issues 

So if they can do something about it on the backend so I don't have to go to all 50 of my affected machines that would be nice. The commands mentioned above are working otherwise. 


I agree, unscoping computers have stopped the bombarding of profiles but installed profiles aren't getting deleted from computers. I hope Jamf comes up with a hot fix that can be scripted and pushed.

Reply


Terms & ConditionsCookie settings