Reapply Configuration Profile

New Contributor II

Apologies for the newbie question:

How do you reapply a configuration profile:

For example: configuration profile to apply WiFi networks to managed Macs.

One users goes through System Preferences > Network and deletes the WiFi networks applied in the profile. The profile still exists on the devices but its payload has been removed.

How do you either flush that configuration profile has been applied to this Mac or reapply the configuration profile?

I see you can Edit the configuration profile in JSS and then reapply to all in scope but is there a way to do this to specific devices?



Contributor II

I know one way to complete this if you have a single station you to need to re-apply a configuration profile to. You can add the station to the exclusion list under the scope. When the station next checks in Casper should pull that configuration profile from the station. To re-apply, you remove the exclusion and have the station check-in again.

New Contributor III

I've run in to this same problem. I wish they handled the profiles more like other policies where you could just delete it from the log and it would re-run it. Or even if you could go in to a specific computer's management tab and re-push a profile.

Valued Contributor II

this is an old post but it just worked for me, thanks @strider.knh

Valued Contributor II

I'm running into this too. See my last post in this thread over here.

Adding user to exclusion and then removing them isn't good option for us as we're talking about security settings in the profiles going out to students. Excluding them from these security settings, even temporarily, isn't an option. I've taken to editing profile again, distributing it to all, and there are still failures (5%?) but not the same machines so inevitably, I guess, the machines all get it.

Honored Contributor II
Honored Contributor II

If you're talking about failed deployment of config profiles, there's an open feature request to add a bit more functionality around that:

If users just remove profiles themselves, I would block the profiles system preference via a restriction profile.

Valued Contributor II

sudo jamf removemdmprofile and sudo jamf mdm from the device (or as a policy, run command, omit the sudo) will remove any/all config profiles, then re-apply them to the device.

Of course if any of them are 802.1X (wired or wireless) profiles, you might lose network connectivity, so YMMV. Test this on a computer in your environment before doing this.

Valued Contributor II

@RobertHammen unfortunately when dealing with student security settings, removing profiles and hoping they come back down isn't an option. I miss MCX.

Valued Contributor II

I strongly agree with CapserSally, "when when dealing with security settings" removing profiles is not really a good idea... the old version of "jamf mdm" would just sync the missing profiles : )

I am guessing that we will see the ability to re-push missing or failed profiles soon : )

Vote it up !!! : )


Valued Contributor II

@gachowski the problem when re-pushing an existing profile (in my case) is it isn't 'missing' as far as JAMF is concerned, so re-pushing never happens. Fingers crossed on that other feature request (I mentioned my use case in there, too).

New Contributor II

Hi I know this isnt a complete answer but if you are pushing out profiles with say "Energy settings" and your first push fails on some macs for some reason etc just edit the Energy start up time by a minute or edit another simple innocuous change in a payload and you can push all the settings out again and see if they all deploy.


I've run into this issue on student computers as well. Excluding the profile and then including it again is not an option.

A simple solution I've found is just to add a space at the end of the profiles description and then you will have the option to push the profile to all of the stations again.

Contributor II

I have encountered issues where a Configuration Profile says it has been applied but not 100% on the client. Example is a Screensaver Config Profile ({askForPassword=1, idleTime=1200, askForPasswordDelay=0}) that does not apply the askForPassword setting. Taking the computer out of the Scope of the Profile and then putting it back in does not apply the setting, so aside from removing the profile I have no options. Worst part is that the log says it was Completed and unless I manually verify I would never know the profile was not working 100%.
Now this could be an specific issue related to OS X Sierra as Apple has made some major changes which could have affected the ability for JAMF to work properly or at all. I have along list of things that do not work via the JSS with my Macs and have had to do a patchwork of JSS, User Templates and scripts to get the Macs consistently working just so I can put them out in the field with relative confidence in them.

New Contributor III

This may not be an issue with how JAMF works, but rather an issue on how you are using Configuration Profiles.

If you need to ensure specific settings are in place and can not be modified by the user, then why not create an extension attribute that runs a script determining if all those settings are correct and scope the configuration profile to the result of that extension attribute?

For example, if the need to ensure Screensaver settings are set like @Cornoir mentions, then have a script that determines the values for each setting are true and push the config profile down if not.