changing configuration profiles policy (via script)

[Anonymous]

Hello community 🙂
is there a way to use a policy or a shellscript to delete a bunch of no more needed configuration profiles and replace them with other ones 
We have deployed some configuration profiles for our antivirus software and now, we have to delete them and replace them with others, that are needed for our new antivirus software. Both antivirus programs do have own firewalls and for that firewalls, we need to activate firewall configuration profiles and at the same way, we have  to delete and replace some system extensions.
This must be done on MacOS BigSur and MacOS Monterey.
Does anyone have a hint for me, how I could manage this?
I can deploy the software and the configuration profiles on my own, but deleting and replacing the configuration profiles, or replace them with new ones, via script or policy, I need some help.

The only way I know, is to use the JamfPro GUI, but this would not be the best way to reconfigure all of our Mac clients.

[straffin]

Are these Configuration Profiles actually changing anything (Network, DNS, Time Machine settings, etc.) or are they just allowing actions (approve a System Extension, allow Full Disk access, etc.). If the latter, what harm is there in leaving a Config Profile that, for example, allows a System Extension to operate if the System Extension is no longer present? It's not as pretty, but it's not harming anything.

Were these Config Profiles distributed by Jamf Pro? From what I understand, by removing the computers from the Scope of the Config Profile, Jamf Pro should delete the Config Profile from the computer. (From other posts, however, I see that the "should" in my statement is accurate... it doesn't always work. Another, somewhat heavy-handed approach is described here.)

[Anonymous]

@straffin Hi straffin, thank you for your reply. Yes, the policies are changing some network settings and system extension, because the policies are the ones for the settings for the antivirus software. All the profiles and system extensions were distributed by Jamf Pro. We have to change from ApexOne to ESET and this includes, that we have to exchange the network- and configuration profiles and some system extensions behind. I know about the way to change client settings by using the JamfPro GUI, but I don't want to do this manually for each client, so I am looking for a solution to do this with a job.
Meanwhile,  I was able to test around some scenes, to exchange the profiles and system extensions by using the Jamf GUI (the way, you described about) and it seems, that I found a way to prevent the client from loosing the network connection. At the first step, I roll out the new extensions and configuration profiles to the client and at the second step, I delete the no longer needed configuration profiles and system extensions from the client. After that, I run a deinstallation job for the old antivirus software and then a job to install the new one. This works great, but the goal, I hope to reach is, to find a way to build a job with that I can do the exchange automated. I don't want to do this manually for each client. (ok, 65 Macs are not a lot, but it would be nice, if I could automate this procedure.)

[Anonymous]

Addendum:
The "heavy-handed" approach article is no way for me. If I remove the MDM profile from the client, the client is loosing all the settings that enable working inside our infrastructure. The certificate for the LAN and WLan is loosed, too, and because of this a reconnection to our JamfPro server is unavailable. The certificate to the JamfPro Server is no longer trusted by the client, too and because of this, the client denies the connection to the JamfPro server.

[straffin]

You might have missed the part of the "heavy-handed" solution where, after running "sudo jamf removemdmprofile", they then run "sudo jamf mdm" to put the MDM profile back (along with only the Config Profiles that are currently scoped to the computer). This may be the only way to get what you want if the "un-scoping" doesn't work. This is also why we like to use many small solution-specific Configuration Profiles rather than large, multi-purpose CPs.

Enjoy!

[Anonymous]

hello @straffin I have tested that way, but it does not work, because the certificate of the jamf server is no longer trusted, if I remove the MDM profile. It can be, that there is a failure in my way of rolling out the certificate, because it seems to be, that the trust settings are gone, too, when I delete the MDM profile. I have to check this out and find a solution.

[straffin]

Hmm... it may be that a full re-enrollment is necessary, which would be disappointing. 

Let us know if you find a solution? Thanks!