Reapply Configuration Profile

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.

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.

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

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.

If you're talking about failed deployment of config profiles, there's an open feature request to add a bit more functionality around that: https://jamfnation.jamfsoftware.com/featureRequest.html?id=3610.

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

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.

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

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 !!! : )

https://jamfnation.jamfsoftware.com/featureRequest.html?id=3610

C

@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).

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.

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.

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.

This actually gave us a great idea which to reclassify the ipad so as the configuration profile would no longer apply. In our case, we have staff and student devices. So we reclassified the problematic staff device as a student device. The configuration profile for student devices flipped the problematic profile out of there. Then after the problem profile is removed, immediately reconfigure as a staff device. The correct config profile gets reloaded and all is well.

Doing an exclusion on this config profile was not possible, as i didnt want to edit the policy and have the chance it would re apply to all devices. So focusing purely on a reconfiguration of the device i was able to get it done.

jamf web interface should have a command for idevices the same as it has for laptops to reapply all policies, jamf flushPolicyHistory is the one i use on laptops.