Skip to main content
Jamf Nation, hosted by Jamf, is the largest Apple IT management community in the world. Dialog with your fellow IT professionals, gain insight about Apple device deployments, share best practices and bounce ideas off each other. Join the conversation.

Retry button for failed configuration profiles

As these fail to deploy quite often, a button to retry would be great.

The current process to retry applying a config profile is a bit drastic.

Comment
Order by:

Posted: by bentoms

YES!

Just been looking for this.

Like

Posted: by franton

Considering that the only way I know of to get the JSS to retry is MySQL commands direct to the database, I voted this up.

Like

Posted: by CasperSally

@franton - it's very tedious but to try if you hit cancel on the failed command, it should go over to pending (have to do it on each machine).

I wish there was some way to set something like 'retry 3 times if profile fails to install correctly' or something. If it fails 3x you know something is probably wrong but I bet it would succeed on one of those tries if it was just some timing issue or something.

Like

Posted: by davidacland

@CasperSally not sure if I'm doing something wrong, if I click cancel on a failed profile, it doesn't add it back into the remaining column.

I agree, I think the JSS gives up too easily and should try a few more times or for a time period.

Like

Posted: by CasperSally

@davidacland In my experience, it is not immediate but does eventually go over to pending. give it a few mins and check back. I've had a ton of experience (unfortunately) with failed profiles. We've relied many times on hitting cancel on failed profile install and having techs reboot to get the machine to check for profiles again.

Like

Posted: by gachowski

I have a question, don't we all just want the profile delivered? How about not having a failed option and just loop to pending? And the JSS keeps trying until it is successful?

Is there really anything we can do if it's failed?

C

PS I voted this up : )

Like

Posted: by davidacland

@gachowski I was thinking that too. Ideally a combination of the two so more persistent automatic retries, and a button! Not sure if I'd want the JSS to keep trying indefinitely, could cause a problem somewhere.

Like

Posted: by mm2270

I agree with @davidacland Anytime we talk about automatically retrying something - pushing a Profile, running a policy, installing a package, whatever - we need to also talk about having some kind of finite limit on retries. I would not want our JSS to just keep trying over and over again. One or two failed attempts can often be explained away, but after something fails 10 times, somethin' be busted.

Like

Posted: by bpavlov

I'm going to add my vote to this as well. Been running into this.

Ideally this is what I would like to see just to expand on the original idea.

If you click on the failed link, there should be a RETRY FAILED Profiles button. This should also ideally clear the computers from the FAILED list and add them to pending. It's very confusing to see the computer still listed under FAILED even after it has actually deployed successfully!

If you click on a computer and look at its Management history, there should also RETRY FAILED Profiles button.

If you click on Computer -> Configurations Profiles tab there should also be a RETRY ALL FAILED Profiles button to do a retry on all failed profiles for all config profiles.

I think this gives us some granular control and makes it A LOT easier to do multiple computers at once.

And I don't want to go to off topic (I'll make a separate feature request for this), but I would also like to add:
If a computer has been re-imaged via Casper Imaging, all pending/failed profiles should be canceled/wiped from the computer in the JSS.

Like

Posted: by CasperSally

@bpavlov did you make a separate feature request? this is something else that would ease the issue of failed profiles for us

And I don't want to go to off topic (I'll make a separate feature request for this), but I would also like to add: If a computer has been re-imaged via Casper Imaging, all pending/failed profiles should be canceled/wiped from the computer in the JSS.
Like

Posted: by bpavlov

How are organizations with large numbers of Mac devices even dealing with this? This seems illogical to manage. And having to go into the database should not be a frequent occurrence.

Neither this thread or the other relevant thread: https://jamfnation.jamfsoftware.com/featureRequest.html?id=3619 have gotten even a "Under Review" status despite the high votes. Hopefully some more visibility will go a long way to changing that.

Like

Posted: by CasperSally

@bpavlov I'm still manually cancelling failures one at a time. It's a terrible waste of time.

Like

Posted: by gachowski

Bump for votes : )

C

Like

Posted: by erin.miska

@CasperSally @davidacland @gachowski @mm2270 The idea of automatically retrying failed deployments/commands is an interesting one. Hypothetically, how would you want that to work? It sounds like everyone agrees that it shouldn't just retry indefinitely, which makes a ton of sense. So how long/how many times should it keep retrying? Is that something you'd want to customize? Would the amount of time/number of retries differ between different deployments/commands? For example, would there be reason to set configuration profile X to retry 10 times but configuration profile Z to only retry 3 times? Or would it be easier/better to say "Hey JSS, just retry any and all failures 5 times"?

Like

Posted: by gachowski

Can o'worms now Erin : ) Custom is a great idea !!!!

I would think custom is the way to go that way you could different retries for different profiles ... I my case right now all my profiles are security settings so they would all have the same retries. And I always vote for easiest.

However I could see some places not caring about the non security settings .... 3 tries for the sidebar setting and 1,000 tries for the firewall : )

C

Like

Posted: by bpavlov

@erin.miskaWhy does a failure stop other profiles from being installed properly on the device? Also what are all the possible failures that can occur?

I'm guessing there is an exhaustive list somewhere because each failure has a COMMAND and STATUS to it. Perhaps if we got a list it might be easier to look at what failures are possible and in which situations would we want the JSS to continually retry.

I'm not sure if other types of failures exist, but the ones I get are commands "remove configuration profile X" with the status "profile with identifier XXXXXXXXX not found." If it can't find that profile then it's because it no longer exists on the system. So why is a failure even showing up? The profile is no longer on the system which is the same as it being removed. I'm not sure if this is what others are seeing typically. I'm guessing other type of failures exist though.

EDIT: I misspoke after closer observation. Failures do not stop other profiles, but rather only the specific profile that failed from getting deployed. I don't think that should be the case obviously hence the need for this feature request.

Like

Posted: by CasperSally

@erin.miska I'm not sure the complexity of custom setting per profile is worth the effort. If a profile fails to install after 5 or 10 tries, it's probably a sign something else is wrong?

For us, at least what support has told me about our failed profile errors, it's some timing issue and generally if I hit cancel and tech reboots, profile comes down next time every time. I'd think a retry of 5-10 times would solve it if support is right and the errors I've seen really are a timing issue with APN/JSS, etc.

Like

Posted: by mm2270

Just chiming in here since I was mentioned in the post above. I'm siding with @CasperSally here. While configurable options are always a nice thing, in the interest of getting this into the product in a reasonable amount of time, I would opt for having a standard number of retries, or at most, a globally configurable number of retries that would apply to policies, Configuration Profile pushes and whatever else. It seems like engineering per item configurable options would take more work and testing, so I'd rather just see something make it into the product that is solid and works. JAMF will never be able to meet everyone's needs with this, so target the majority of use cases.
I think we can agree that most of us purchased the Casper Suite to help automate as much as possible. JAMF markets things like policies as basically something you set up with Smart Group scoping and then turn it on and not worry about it, but this only works in a perfect world. In reality we still need to keep checking on policies or config profile pushes because of the fact that Casper works on the model of "Try, and if it fails, just STOP and mark it as Failed". It needs to work like "Try, and if it fails, try again x 5 tries (or whatever), THEN stop and mark it as Failed"

I would also say that the counter should only increment if failures occur concurrently, meaning try, and if it fails, increment some counter and try again at the next interval assigned. That counter should get reset of course if there is a successful attempt in there somewhere. I'm thinking here about items set up with an Ongoing frequency.
Maybe also there would need to be some additional status in the JSS for this. Right now there is "Complete" and "Failed" Maybe a third one like "Retrying" or something to that affect, so we know we can ignore those items for the moment, and only register as "Failed" if it hits that retry limit. This would greatly reduce the number of items we need to troubleshoot since we could just filter to the ones that are actually "Failed"

Like

Posted: by erin.miska

Thanks to @CasperSally @mm2270 @gachowski and @bpavlov for the feedback. Lots of good ideas for improving the way we handle MDM failures and just failures in general. Much appreciated!

Like

Posted: by CasperSally

@erin.miska - One thing I'm finding out (on 9.81, it happened previously too), is I have failed commands (" The operation couldn’t be completed. (CPProfileManager error 134030.)" and cancelling them does nothing.

My workflow is have a configuration profile with security settings scoped to smart group. If something comes up and I need to change the config profile, I edit, save and distribute to all.

I get a relatively small percentage of errors. I go in and manually cancel them one at a time, and they no longer show under computer record failed commands, but they never move back over to pending or completed.

I've been working with support on this. I'm wondering if it's because the computers already have an older version of the same config profile, but I need a way to repush edited config profiles. Cloning existing profiles and pushing them, if there's always going to be failures, doesn't make sense because I'll be in an endless loop trying to catch failed computers via cloned profiles.

Changing scope and risking student computers lose the profile isn't an option either.

I just wanted to mention this here because given what I've been seeing, I wonder if what JAMF is looking to do on the back end will actually resend the failed command.

Like

Posted: by erin.miska

@CasperSally thanks for the additional context. Will take all that into consideration.

Like

Posted: by ftiff

Just bumping this.

Personally, I try to use as much as possible Configuration Profiles over Profiles. They're simply faster and more reliable (until we hit an Apple bug).

I have an easy example on why you should make a retry button, or automatically retry:

I have a Certificate+SCEP+Wi-Fi profile. The SCEP server is not (yet) available on internet. So I need to make sure the device is within the corporate network before sending the profile. The tricky part is our network is 10.0.0.0/24 so even if we make a limitation, a user will connect to another 10/24 and the policy will fail (not being able to reach the internal SCEP server)

So +1

Like

Posted: by ftiff

Oh yes one other thing. You can retry SCEP enrolments, but only X times every X minutes. So this doesn't apply to me.

Like

Posted: by aporlebeke

+1 x 1000

Like

Posted: by bpavlov

Just had to clear out a bunch of failures. Talk about a time suck. How does any company fully trust profiles when they can't even be reliably configured on clients? It's hit or miss! I sometimes wish that JAMF would just implement local config profile support where it would rely on the profiles utility rather than relying on Apple for MDM.

Like

Posted: by mtk

+1 x !!

Please implement this. We are finding configuration profiles to be flakey and unreliable. Not being able to easily re-push to failed machines is a big problem.

Like

Posted: by mario

Upvoted, hoping we'll see retry functionality soon (something similar to a log flush for failed policies would be nice). Not looking forward to manually cancelling all these failed profile push attempts...

Like

Posted: by dan.berman

Any response from JAMF about when this will be included? It's impossible to manage failed/cancelled configuration profiles at scale without the ability to have them retry on failure or be repushed on demand.

Like

Posted: by CasperSally

@dan.berman - see JAMFs response to me during their reddit AMA. unlikely to come to the product, at least as requested :(

AMA permalink

Like

Posted: by ClassicII

HUGE bummer.........

Like

Posted: by JustDeWon

OMG... this sucks.. very HUGE bummer

Like

Posted: by aporlebeke

Yeah, this is definitely a bummer.

One of the things I've done to somewhat get around this problem is to simply clone the Configuration Profile but make it available via Self Service instead of installing automatically. You have the ability to choose whether or not Config Profiles installed this way can also be removed via Self Service, so in those few cases of failures I can manually apply the profile.

Sadly, this method does not give you the ability like with Self Service policies to limit the access of Config Profile installs by LDAP user or LDAP user group. Adding this functionality would definitely help us get around these few auto install failures while also preventing our users from having access to install these Self Service config profiles.

Like

Posted: by CasperSally

I'm just running the SQL commands to delete failed (not acknowledged) mgmt and failed app installs over and over to get through this iOS deployment.

JAMF - please help - this needs to be something I can delegate out - nor should I be mucking with the db.

paging @erin.miska to see if there's any hope

Like

Posted: by chris.kemp

@CasperSally - Is there somewhere where details of what you're doing is posted? We've been seeing some failures piling up as well...

I agree that this should be implemented, at least in some usable fashion. I would also like to see some sort of visible notification of a failure, so it can be addressed ASAP rather than having to plod through trying to find them - something that is just not practical in an environment with thousands of workstations.

Like

Posted: by CasperSally

@chris.kemp I'm no longer doing this since 9.96 has a button to cancel all failed commands under management, management commands, cancel all. I think techs still need to click into each iPad to do it, but at least they don't have to cancel every command.

Like

Posted: by chris.kemp

@CasperSally Thank you, that's good to know! We had to stay back at 9.91, but we're testing 9.96 and will probably deploy it in about a month.

Like

Posted: by kmabe

I know its not ideal, but until this is implemented, excluding the failed computers from the profile then removing the exclusion sends them back into the pending section. Usually after doing this, I see my config profiles successfully apply.

Just to note, I upvoted in hopes they'll change their mind.

Like

Posted: by vao

bump

Like

Posted: by larsc

Just want to second this. Would be a good thing. Thanks. :)

Like

Posted: by cs1eh

Yes please, this would be useful.

Like

Posted: by mconners

Bump up...

Still running into issues with profiles failing here and there randomly. We have to exclude a computer and add it back in again for it to work properly.

PLEASE, add a flush or retry button of some sort for profiles.

Like

Posted: by Chuey

Is there any word on this being included in future releases yet?

Like

Posted: by MengKuan

any manual way to re-push the profiles so the devices in remaining decrease?

is been a months and i saw the is so many devices remaining.

Like

Posted: by Sonic84

If you want to retry all failed pushes for a specific Configuration Profile, just edit/save the profile and select "Distribute to Newly Assigned Devices Only". That will flush all failures and queue the clients in scope to get it but do not have it to try and get it again.

Casper will retry failures on it's own, but I do not know what the cadence is...

Like

Posted: by cvsmith122

Any word on when the retry option will be added ?

Like

Posted: by cubandave

As a workaround for now I created a script that uses the API call to flush failed MDM commands.

#!/bin/bash

jss_user="$4"
jss_pass="$5"

jss_url="jss_url"
jss_user="jss_user"
jss_pass="jss_pass"

CURL_OPTIONS="--location --silent --show-error --connect-timeout 30"
computersUDID=$(system_profiler SPHardwareDataType | awk '/UUID/ { print $3; }')
nameLookup=`curl ${CURL_OPTIONS} --header "Accept:application/xml" --request "GET" -u "${jss_user}:${jss_pass}" $jss_url/JSSResource/computers/udid/$computersUDID`
computerID=`echo $nameLookup | xpath "/computer[1]/general/id/text()"`

# echo curl ${CURL_OPTIONS} -H \"Content-Type: text/xml\" -u "${jss_user}:${jss_pass}" "$jss_url"/JSSResource/commandflush/computers/id/$computerID/status/Failed -X DELETE
curl ${CURL_OPTIONS} -H "Content-Type: text/xml" -u "${jss_user}:${jss_pass}" "$jss_url"/JSSResource/commandflush/computers/id/$computerID/status/Failed -X DELETE
Like

Posted: by AVmcclint

To comment on the question of "how many times should the JSS retry and at what interval? In some cases, neither variable will help. Let's say I'm imaging a Mac in our IT room using network ports that are excluded from requiring 802.1x. 802.1x in our offices is handled by a config profile and that profile needs to be installed ASAP so we can then deploy the Mac to the user out in the wild. We don't have time to sit around waiting for an interval to tick by until it tries again.

Another scenario where time is of the essence is that we use a config profile to block users from writing to USB drives. On occasion, VIPs will submit a legit request to be able to copy some files to a USB stick for a presentation. Pulling that config profile, letting the user copy the files, and then pushing the profile back to the machine is the process we use. If either the pull or the push fail for any reason, we look silly because we can't just flip a switch to make it happen.

I think we're all in agreement that we just want the profile push/pull to JUST WORK. Since they don't always JUST WORK, then what we need is a button to click on to clear the failure and try it again at will. Some error reporting to explain WHY it failed would also be nice.

Currently, when I encounter profiles that just flat out refuse to push or pull, I'll do a RemoveMdmProfile then mdm then manage, but even that isn't a 100% solution.

Like

Posted: by Chris.Tavenner

Any update on this?

Like

Posted: by PeterG

Update Please?

Like

Posted: by acaveny

Was just looking for this today. Upvoted. Any updates????

Like

Posted: by ebonweaver

Not just an update button, a retry cycle, just like Policies. The whole point of this expensive software is to automate things, and it fails miserably in some very basic ways. This issue comes right after not being able to reliably manage computer names. Granted, if JAMF could actually set computer names, my need for a retry on the config that binds to AD wouldn't be needed, because then binding to AD would actually be possible on enrollment.

Like

Posted: by denmoff

one more vote up for 1,000!!

Like

Posted: by davidacland

Just noticed this has passed it's 3 year anniversary!

I hoped that config profiles would have become more reliable by now :(

Like

Posted: by CasperSally

Every existing machine that goes through DEP workflow generates many failed removal commands (PI-005972). Worse even, we're hitting a race condition with config profiles scoped to smart groups based on names, if computer name changes old profiles scoped to old computer name stay on the device. For now I'm running db command to cancel failed commands every day, which is not practical to keep up with forever.

Even better than a GUI way to cancel failed profiles, I'd really like jamf to move in a direction where failed commands are retried 1-3x or something more reliable.

Like

Posted: by rhill

Im encountering a intermittent timing issue causing a config profile to fail on newly enrolled macs due to a rename of the device and subsequent update in JSS.

voting up also !

Like

Posted: by kquan

upvoted. this feature would be very nice to have....

Like

Posted: by TheJazzDisciple

Joining in the Upvotes here. This would be game changing to have.

Like

Posted: by leeskade

This is a must with APNS deployed profiles, would be so helpful!

Like

Posted: by MarcosMunoz

Any updates to this request?

Like

Posted: by jconte

This has become a necessity.

Like

Posted: by robert.petitto

Upvote...in addition to this feature, would love the ability to have a setting where the configuration profile can auto distribute on a schedule. Eg...I have a web filter plugin config profile that needs to be redistributed every time I change the email associated to a device in order for the webfilter to sync to that user. It would be nice to have that config profile set to distribute every x minutes regardless of status (I'd want it to distribute it to all users even if all devices already have the profile / there are no failures).

Like

Posted: by ndeangelis

@CasperSally I see this every single day and it is driving me crazy. 10th largest School District in the US....

Like

Posted: by CasperSally

All,

If you're getting failed commands on enrollment, please reference this thread, AND put a ticket in referencing PI-005972. I don't believe jamf has gotten many reports of same issue, unless they do, they're not likely to fix.

Also, regarding this original request, I linked to it above but it's buried, jamf said in reddit AMA it's not likely to be implemented as requested, but they are working on config profile/APNS queue management improvements. This AMA was 2 years ago though.

Like

Posted: by bvondeylen

Pretty please with chocolate on top…

Like